Continue guest-update rollback after individual restore failures

docs/terminal-usage.md

@@ -44,8 +44,10 @@ hydra download 'https://example.org/distribution.iso'
 ```
 
 Add `--sha256` followed by the publisher's 64 hexadecimal digits to check the
-download. Format validation alone checks that the file looks like an ISO,
-not who published it. Validated files are cached under
+download. Supported images are ISO9660 and ISO9660/UDF hybrids; pure UDF
+images are currently refused because their completeness cannot be validated.
+Format validation checks the declared ISO9660 volume fits the file; it does not
+verify the publisher or optional trailing hybrid data. Validated files are cached under
 `~/.cache/hydra/iso` (or `$XDG_CACHE_HOME/hydra/iso`). Ctrl+C cancels an active
 download without publishing its partial file. HTTP is available for a local
 test transfer; prefer the publisher's HTTPS endpoint for Internet downloads.
@@ -113,10 +115,51 @@ python3 hydra-os-update.pyz
 sudo python3 hydra-os-update.pyz --apply
 ```
 
-The first command only prints the file inventory. After applying, log out of
-Hydra's graphical session and log in again so the long-running session process
-loads the new code. Reopening a terminal alone cannot reload that process.
-Running VMs remain independent of the graphical session.
+The first command only prints the file inventory. After applying, open the
+current Hydra recovery terminal with Ctrl+Alt+Shift+Escape, enter `:shell`, then
+run this command **inside that installed Hydra graphical session**:
+
+```sh
+labwc --exit
+```
+
+At the login screen, log in again as the same Hydra user. This restarts the
+long-running session process with the updated code. Use this from the recovery
+shell, not an SSH login or the outer host terminal. Reopening a terminal alone
+cannot reload that process. Running VMs remain independent of the graphical
+session.
+
+To reverse a successful update, or finish recovery after a reported partial
+rollback, use the exact retained backup path printed by the updater. Correct
+the reported filesystem problem first. Inspect its records inside Hydra:
+
+```sh
+backup='/var/lib/hydra/updates/REPLACE_WITH_THE_REPORTED_BACKUP'
+sudo python3 -m json.tool "$backup/backup.json"
+```
+
+Process every listed path relative to `/`. For an entry with `"existed": true`,
+restore that path from the same relative location in the backup. For example,
+after confirming the CLI entry originally existed:
+
+```sh
+relative='usr/lib/hydra/hydra/cli.py'
+sudo cp --no-dereference --remove-destination --preserve=mode,timestamps -- "$backup/$relative" "/$relative"
+```
+
+Use the same operation for other originally existing files. When `"symlink"`
+is recorded, restore the symlink itself with this command; do not copy its
+referent. In particular, restoring `etc/os-release` must recreate its recorded
+vendor symlink while leaving `/usr/lib/os-release` intact. Check the restored
+link with `readlink /etc/os-release` and compare it to `backup.json`.
+
+For each entry with `"existed": false`, remove only that exact installed file
+using `sudo rm -f -- /THE_RECORDED_RELATIVE_PATH`; no backup copy exists for it.
+This includes newly added modules, logos or the runtime-update receipt when
+listed as originally absent. Copying the backup directory over `/` alone will
+leave these additions behind. Confirm restored regular-file modes and SHA-256
+values against their records, retain the backup, then exit the Hydra graphical
+session and log in again as described above.
 
 This bundle contains the Fastfetch configuration and logo, but no executable
 packages. If the old installation lacks Fastfetch, install it inside Hydra: