docs(hibernate-swap-dualboot): clarify row 6 mitigation for systemctl hibernate hang
expand explanation of why timeout/watchdog approaches fail for S4 hangs since the process is frozen. document the actual viable mitigations: strict preflight validation, auto-recovery via reset, and BootOrder fallback. add note about testing and post-hang recovery documentation.
This commit is contained in:
@@ -198,7 +198,7 @@ mkfs.ntfs -Q -L WINDOWS /dev/nvme1n1p2
|
||||
| 3 | Majeur | Swap = RAM ignore la VRAM recopiée (jusqu'à 32 Go) → image 75‑90 GiO > swap 64 → échec. | **Swap = RAM + VRAM + marge = 96 GiO.** Preflight : estimer VRAM en usage (`nvidia-smi`), refuser/basculer reboot si image projetée > swap. Tester pire cas (jeu déjà lancé côté Linux). |
|
||||
| 4 | Majeur | Brick FWS par révocation **dbx/SBAT** poussée par Windows Update (précédents BootHole/SBAT réels). Windows booté **fréquemment** ici → risque élevé. | shim/grub à jour et re‑signés ; **différer/figer Windows Update** sur ce Windows gaming minimal ; tester bascule après chaque MAJ Windows/Vanguard ; **fournir un média de récupération FWS** (ré‑enrôlement/re‑signature). |
|
||||
| 5 | Majeur | **BitLocker auto‑activé** par TPM+SB (Win11 24H2 Device Encryption) : le flip SB OFF→ON change PCR7 → écran de récupération, clé dans le compte MS. | **Activer Secure Boot AVANT d'installer Windows** (PCR7 stable dès l'install, pas de flip). Documenter : suspendre/désactiver BitLocker, **sauvegarder la clé**, `powercfg /h off`. Vérifier device‑encryption au postinstall et alerter. Nuance : les bascules `BootNext` récurrentes ne touchent PAS PCR7 (bootmgfw chargé à l'identique). |
|
||||
| 6 | Majeur | `systemctl hibernate` qui **hang** (driver refuse S4) : machine allumée, session ni sauvée ni basculée, `BootNext=Windows` resté armé → départ surprise. | **`timeout`/watchdog** autour de `hibernate` ; **trap** nettoyant `BootNext` (`efibootmgr -N`) même en blocage ; rester sur FWS. Tester robustesse S4 sur la carte. |
|
||||
| 6 | Majeur | `systemctl hibernate` qui **hang** (driver refuse S4) : machine allumée, session ni sauvée ni basculée, `BootNext=Windows` resté armé → départ surprise. | ⚠️ **NON mitigeable en userspace** : pendant un hang S4 le process (et tout watchdog) est gelé — un `timeout` est impossible (il tuerait aussi les hibernations *réussies*, qui ne rendent la main qu'au resume). Parades réelles : **préflight strict** (élimine les causes courantes) + **auto-guérison** au reset (BootNext=Windows → Windows → tâche ONSTART arme FWS → retour) + **filet BootOrder[0]=FWS**. Tester la robustesse S4 sur la carte ; documenter la récupération post-hang. |
|
||||
| 7 | Majeur | Resume **silencieux** en échec (offset dérivé/image corrompue) → cold boot, session perdue **sans notification**. Incohérence swapfile+offset (fragile) vs partition dédiée (robuste). | **Unifier sur partition swap dédiée** dès que possible (chemin installeur) ; `chattr +i` sur tout swapfile résiduel ; revalider l'offset au preflight ET au retour ; **notifier explicitement** « session non restaurée » au cold boot post‑hibernation. |
|
||||
| 8 | Majeur | Politique de fallback **contradictoire** entre docs (`hibernate || die` reste sur FWS vs `|| reboot` part sur Windows sans session). | **Trancher UNE politique** (reco : échec hibernation → confirmation utilisateur puis reboot Windows sans session ; sinon annuler proprement `efibootmgr -N`) et l'implémenter à l'identique. Interdire la divergence en CI. |
|
||||
| 9 | Majeur | Sémantiques `BootNext`/`BootOrder` **non validées** (Windows pas installé) : firmware peut ignorer BootNext, réordonner, purger l'entrée FWS. Mapping `bcdedit {fwbootmgr}` → BootNext non documenté MS. | Valider empiriquement dès la 1re install (écrire BootNext côté Windows, relire via `efibootmgr` côté Linux). Entrée de secours `\EFI\BOOT\BOOTX64.EFI` (`grub-install --removable`). Ne pas dépendre que de BootNext. |
|
||||
|
||||
Reference in New Issue
Block a user