Ibernazione che usa systemctle fa funzionare in casi difficili
Per me, pm-hibernatefallisce sempre. Dopo alcune modifiche, sono stato in grado di ibernare usando l'interfaccia di systemd (init system in 16.04 e versioni successive). Sono anche riuscito a farlo funzionare su 17.04 con un file di scambio. Questo caso di studio può essere utile per gli altri con problemi.
Primo tentativo:
sudo systemctl hibernate
Se il problema persiste, iniziare la risoluzione dei problemi: nello stato di ibernazione (HTD o ACPI S4) lo stato della macchina viene scritto sul disco in modo che non sia necessaria alimentazione per conservarlo. Lo stato viene scritto in una partizione di swap o in un file di swap. Nota: se si utilizza Btrfs NON tentare di utilizzare un file di scambio in quanto ciò potrebbe causare la corruzione del file system
La partizione di swap o il file di swap potrebbe essere necessario avere le stesse dimensioni della RAM per consentire l'ibernazione, ma ci sono buone probabilità che tu sia in grado di ibernare se è almeno 2/5 della dimensione della RAM, secondo la pagina wiki di Arch , quindi prova altri passaggi prima di aumentare le dimensioni dello swap.
Se il problema è che si ottiene un avvio pulito anziché il curriculum previsto, almeno è molto probabile che sia necessario impostare un parametro di avvio per trovare l'immagine del disco
Trova la tua partizione di swap:
grep swap /etc/fstab
per me questo ritorna (output parziale)
# swap was on /dev/mmcblk0p3 during installation
dov'è /dev/mmcblk0p3la partizione da specificare
Aggiungi un parametro di avvio:
sudoedit /etc/default/grub
Alla riga iniziale GRUB_CMDLINE_LINUX_DEFAULTaggiungi resume=/dev/YourSwapPartitionalla sezione tra virgolette (sostituisci con la partizione che hai identificato in precedenza). Usando il mio esempio:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=/dev/mmcblk0p3"
Ogni volta che si modifica questo file, è necessario eseguire sudo update-grubo le modifiche non avranno alcun effetto.
Ora devi riavviare. Quindi puoi provare a ibernare, eseguendo il comando:
sudo systemctl hibernate
Per riprendere, premi il pulsante di accensione e il sistema si avvierà.
Se i problemi persistono, avviare il debug.
Includo il mio caso di seguito come esempio, ma informazioni dettagliate sul debug degli stati S sono disponibili in questo blog e anche in questo .
Imposta alcuni altri parametri di avvio per acquisire più informazioni. Rimuovere quiete splashaggiungere initcall_debuge no_console_suspendciò causerà la stampa delle chiamate di sistema init sulla console in modo da poter vedere cosa non va. Ho impostato questo:
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/mmcblk0p3 no_console_suspend initcall_debug"
Il che mi ha aiutato a vedere cosa non andava nel riprendere dal letargo.
Nel mio caso, dopo aver ripreso ho perso il WiFi e il kernel era chiaramente sconvolto poiché la maggior parte dei comandi (ad esempio leggere qualcosa da /sys, ricaricare moduli o qualsiasi systemctlcomando) non funzionava - il processo sembrerebbe avviarsi e bloccarsi (tutto questo sarebbe tornato alla normalità dopo il riavvio ovviamente). Guardando il sistema arrestarsi molto lentamente e leggere tutti i messaggi di debug, ho notato che c'erano molti problemi con "brcm", quindi ho indovinato la colpa del mio modulo driver wireless Broadcom. Abbastanza sicuro ho regolato la mia procedura di ibernazione per scaricare prima il modulo:
sudo modprobe -r brcmfmac
sudo systemctl hibernate
al riavvio reinserisco il modulo
sudo modprobe brcmfmac
E tutto ha funzionato perfettamente. Devo anche inserire nella blacklist il btsdiomodulo che sembra essere incompatibile conbrcmfmac
Aggiornamento: ibernazione utilizzando un file di scambio il 17.04.
Ancora una volta con l'aiuto della pagina wiki di Arch e qualche aggiustamento aggiuntivo, sono riuscito a far funzionare l'ibernazione su 17.04 con un file di scambio. Ciò ha richiesto un parametro di avvio aggiuntivo, resume_offset=ndove n è il primo numero sotto physical_offsetnell'output di sudo filefrag -v /swapfile:
$ sudo filefrag -v /swapfile
Filesystem type is: ef53
File size of /swapfile is 1425873920 (348114 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 32767: 34816.. 67583: 32768:
1: 32768.. 63487: 67584.. 98303: 30720:
....
Pertanto, il parametro di avvio aggiuntivo nel mio caso è resume_offset=34816. È ancora necessario impostare un parametro di avvio per la ripresa della partizione. Questa sarà la partizione di root (o qualunque sia la partizione in cui si trova il tuo file di scambio) I miei parametri ora sono:
GRUB_CMDLINE_LINUX_DEFAULT="no_console_suspend initcall_debug resume=/dev/mmcblk1p2 resume_offset=34816"
Dov'è la /dev/mmcblk1p2mia partizione di root (la tua è più probabile che sia qualcosa di simile /dev/sda2).
Durante il curriculum ho visto caricare l'immagine con successo, ma nel mio caso (solo un esempio - YMMVAPD) poi alcuni altri driver ( i2c_designware) hanno lanciato alcuni errori e ho ottenuto un blocco completo del sistema al curriculum. L'ibernazione funziona se scarico quei moduli in aggiunta brcmfmac, ma il sistema diventa rapidamente inutilizzabile senza quei moduli. Ho quindi creato una sorta di script per scaricare i moduli con errori e reinserirli immediatamente al riavvio:
# remove buggy modules
modprobe -r brcmfmac i2c_designware_platform i2c_designware_core &&
# hibernate
echo disk > /sys/power/state
# reinsert
modprobe i2c_designware_core i2c_designware_platform brcmfmac
Quando voglio andare in letargo, corro sudo bash script. Funziona benissimo.
TL; DR
Utilizzare systemd, impostare un parametro di avvio per riprendere dallo scambio, identificare i driver con errori e scaricarli prima di avviare l'ibernazione. Se il sistema non può funzionare a lungo senza quei moduli o è necessario scaricarne diversi, potrebbe essere più semplice utilizzare un semplice script per avviare l'ibernazione.