Ripresa dell'ibernazione non riuscita sul kernel linux 4.9.0, Debian 9

Di recente ho aggiornato il mio kernel da 3.16.4 (Debian jessie) a 4.9.0 (Debian stretch). Tutto è andato bene, fino a quando ho provato a "ibernare" (sospensione su disco).

Quando uso l'opzione Ibernazione in LXDE, sembra in letargo. Sento il mandrino del disco che ticchetta e scrive i dati. Ma i problemi si presentano quando si riprende dal letargo. Il kernel ripristina correttamente l'immagine dallo scambio, ma si blocca e si riavvia, con tutto quel lavoro perso. Non sono riuscito a trovare risposta da nessuna parte su Internet. Le persone stanno solo risolvendo alcuni errori nel non impostare /etc/initramfs-tools/conf.d/resume o hanno impostato i parametri del kernel o hanno una voce errata in / etc / fstab. Ho questi corretti. UUID corretto in /etc/initramfs-tools/conf.d/resume, correggere fstab e non impostare resume parametro del kernel.

• Ho spostato la partizione di swap al di fuori della partizione estesa in primaria. L'UUID è stato salvato e applicato al nuovo swap.

• Il sistema raggiunge "Ripristino immagine al 100%" e quindi "Sospensione delle console", quindi si spegne e si avvia normalmente, con tutto il lavoro perso.

• Ho provato un'installazione pulita, ma senza fortuna.

• Succede solo su i386 (x86 a 32 bit), amd64 (x86 a 64 bit) non ne risente.

Layout della tabella delle partizioni del disco:

NAME   FSTYPE LABEL    UUID                                 MOUNTPOINT
sda                                                         
├─sda1 ext4   HDD      <ROOT-UUID> /
└─sda2 swap   HDD-SWAP <SW-UUID> [SWAP]
sr0

Sda2 era logico (risiede-dentro-esteso) prima dell'aggiornamento.

fstab:

UUID=<ROOT-UUID> / ext4 errors=remount-ro 0 1
UUID=<SW-UUID> none swap sw 0 0

/etc/initramfs-tools/conf.d/resume

RESUME=UUID=<SW-UUID>

Cmdline del kernel

BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-686-pae root=UUID=<ROOT-UUID> ro quiet

Informazioni di sistema:

Computer: Compaq CQ60-120ec
Swap Size: 3.5GiB
Processor: AMD Athlon X2 64 QL-66
GPU: Nvidia Geforce 8200M G
Memory: 2G DDR2 667MHz
Desktop Environment: LXDE
Debian Version: 9 (stretch)
Kernel version: 4.9.0-3
Graphics Driver: nvidia legacy 304xxx

(So ​​che il processore è a 64 bit ma originariamente era dotato di sistema operativo a 32 bit, quindi ho pensato che fosse a 32 bit fino a quando ho esaminato / proc / cpuinfo)

Il problema è dovuto a un conflitto tra ibernazione e kASLR su x86-32 . Questo può essere risolto disabilitando kASLR con l' opzione di avvio del kernel nokaslr . x86-64 non è interessato.

Per Grub questo può essere fatto modificando / etc / default / grub e aggiungendo nokaslr alle opzioni di avvio, ad esempio: GRUB_CMDLINE_LINUX_DEFAULT = "quiet nokaslr "

Quindi eseguire update-grub per aggiornare la configurazione e riavviare per provare.

Ho avuto esattamente lo stesso problema e sembra che solo il kernel PAE sia interessato da quel problema. Lo stesso kernel senza PAE funziona senza problemi.

La soluzione alternativa per me era installare linux-image-686 e disinstallare linux-image-686-pae e linux-image-4.9.0-4-686-pae. La versione esatta del kernel può cambiare nel tempo a causa degli aggiornamenti, ma sostanzialmente il kernel PAE attualmente in esecuzione deve essere sostituito con un kernel senza PAE.

In realtà non ha nulla a che fare con il supporto PAE della CPU, poiché la mia CPU supporta PAE secondo / proc / cpuinfo. Ma PAE non è comunque molto utile sui vecchi notebook.

Inoltre non ha nulla a che fare con il kernel 4.9 PAE poiché lo stesso problema si verifica con il kernel 4.13 PAE dai backport di Debian.

Probabilmente /etc/uswsusp.confvuole una voce modificata per il 'resume device', se questo non viene usato, myabe prova semplicemente a grep il tuo vecchio UUID in tutti i file /etcper trovare un posto dove è necessario un cambiamento. Inoltre update-initramfssarebbe necessario, direi.

Stavo ottenendo lo stesso errore. La reinstallazione con l'ultimo iso netinst, ovvero debian-9.1.0-amd64-netinst.iso, ha risolto il problema. Il bug sembra essere stato corretto (almeno per questa architettura).

Ho rimosso uswsusp e l'ibernazione funziona di nuovo come un incantesimo. A proposito, penso che fosse già il caso di Jessie quando stavo usando il driver nvidia, ho provato usando uswsusp e ho dovuto rimuoverlo per far funzionare l'ibernazione.

Se hai una partizione di swap (con le dimensioni corrette) e se modifichi "/etc/initramfs-tools/conf.d/resume" con il risultato "#blkid" e i386 non andrà in letargo corretto di un bug su Debians i386 4.9 kernel! Aggiorna il kernel a una versione successiva alla 4.9 o ripristina il kernel 3.16.

Scusa la natura generica di questa risposta. Ho visto domande simili in tutto il Web e ho deciso di scrivere una risposta per tutte. Ho riscontrato lo stesso problema durante l'aggiornamento di Debian-Jessie su un Hp2510. Sono passato a Ubuntu-desktop e l'ho trovato anche lì. Successivamente ho eseguito i miei test su Ubuntu e Hp2510, quindi potrebbe non essere completamente applicabile alla tua situazione.

Alcuni computer meno recenti aggiornati con nuovi sistemi Linux presentano problemi di avvio. Potrebbero non avviarsi affatto o potrebbero richiedere fino a tre minuti per l'avvio. Per coincidenza, o non riescono a letargo o impiegano così tanto tempo a letargo e deibernare che la capacità è inutile. Spesso ciò non è dovuto al fatto che i vecchi computer sono semplicemente lenti ma a causa di una modifica introdotta nel kernel Linux 4.8, che causa un problema con un chipset Intel molto comune, che include l'output di svideo. A partire da questo kernel, qualsiasi computer con questo chipset presenterà problemi di avvio a meno che l'argomento della riga di comando di Linux"video=SVIDEO-1:d"è incluso in GRUB_CMDLINE_LINUX. Ciò ridurrà significativamente i tempi di avvio a 64 e 32 bit, ma risolve i problemi di ibernazione solo per 64 bit. Nessun sistema a 32 bit supporta l'ibernazione dopo questo punto. Inoltre, i tempi di avvio per tutte le versioni del kernel 4.8 e 4.9 sono cattivi (tranne 4.8.rc1-7). Questo è finalmente risolto in 4.10. I kernel 4.8 e 4.9 dovrebbero essere semplicemente evitati (sono comunque obsoleti).

Se vuoi i tempi di avvio più veloci, usa un kernel pre-4.8. Userei Ubuntu-desktop 15.04 con il kernel aggiornato alla 4.7.10. Questo è l'unico modo per ottenere l'ibernazione in un sistema a 32. Il sistema a 64 bit si avvia 7% più lentamente rispetto ai 32 bit, ma è ancora più veloce di qualsiasi versione successiva. Se si desidera un sistema a 32 bit attualmente supportato e si è disposti a rinunciare al letargo, utilizzare quelli rilasciati o aggiornati a un kernel 4.10 o successivo. Qualsiasi versione a 64 bit funziona dopo 4.8 con la correzione video ma per prestazioni ottimali evitare 4.8 e 4.9.

Per aggiungere la correzione video fare sudo nano /etc/default/grub. Dopo aver chiuso nano do sudo update-grub. A meno che GRUB_CMDLINE_LINUX_DEFAULT, che viene inserito dopo GRUB_CMDLINE_LINUX, sia vuoto, "video=SVIDEO-1:d"non sarà l'ultimo argomento della riga di comando di Linux, che alcune persone ritengono necessario. In realtà può essere ovunque.

Puoi sempre invocare l'ibernazione con il comando pm-hibernate in un terminale (o tty) ma per avere un'opzione GUI disponibile devi creare o aggiungere al file delle politiche /etc/polkit-1/localauthority/50-local.d/ com.ubuntu.enable-hibernate.pkla(ovviamente specifico della distro) il seguente testo:

[Re-enable hibernate by default for login1]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate
    ResultActive=yes
[Re-enable hibernate for multiple users by default in logind]
    Identity=unix-user:*
    Action=org.freedesktop.login1.hibernate-multiple-sessions
    ResultActive=yes

A volte il problema non è nel grub o nell'UUID. Questo succede anche quando sei a corto di spazio di archiviazione. Non ci sarà più spazio di scrittura, quindi riprendendo dal letargo si bloccherà.

Quando si arriva a quell'errore, è possibile fare clic su alt+ f2/f3/f7o ctrl+alt+ f2/f3/f7per aprire il terminale. Accedi al tuo account o root utilizzando il terminale.

Quindi eseguire il comando sudo df -hper verificare lo spazio di archiviazione. Nel mio caso non avevo spazio sul mio, /dev/sda1quindi controlla lo spazio libero sulle unità nell'elenco.

Se sei a corto di spazio, prova a eliminare alcuni file per ottenere una notevole quantità di spazio.

Dopodiché puoi fare clic su alt+f1o ctrl+alt+f1e attendere che venga visualizzata o digitata la GUI di accessoreboot in the terminal to reboot