Debian non parte: "resuming from hibernation"

[ilpescatorefolle]

ho un q9400 intel, r5 230, mobo msi con chipset g41, 4+2GB ddr3, hd 1TB sata2 partizionato Windows 10 + Debian 10

l'installazione della Debian è andata perfetta ma già dal primo riavvio mi compare la scritta "resuming from hibernation" e non si vede più nulla

sulla stessa macchina era presente una Debian9 per 3 anni ed ha funzionato sempre benissimo...

[njkjta]

Ciao,
stesso problema sul mio vecchio netbook Asus 1215B procedendo con un'installazione pulita (amd64) di Debian 10 sia da iso Netinstall (unofficial con firmware) sia da iso DVD1. Premetto che il portatile non ha mai avuto problemi con le precedenti versioni di Debian.
Non credo che sia un problema reale di "ibernazione" perché anche su un altro portatile ma appare quel messaggio ma si avvia e funziona correttamente.
Ho provato ad avviare temporaneamente grub (tasto 'e') rimuovendo la voce 'quiet' e appare la schermata in allegato, come se non venisse riconosciuta la partizione o mancasse un modulo per riconoscerla, però aggiungendo al boot l'opzione 'acpi=off' il portatile si avvia e parte in modalità grafica con una risoluzione ridotta.
Appena posso faccio ulteriori verifiche.

Njkjta

[njkjta]

A questo punto sono convinto che ci sia qualche problema nella gestione del risparmio energetico.
Ho fatto qualche ricerca e provato a modificare l'opzione del kernel in 'acpi_osi=linux' ma non ho risolto.
Funziona tutto correttamente solo disabilitando l'acpi: 'acpi=off' con modifica permanente nel file /etc/default/grub e suggessivo aggiornamento di Grub (update-grub), peccato che si perdano alcune funzionalità ormai date per scontate tra cui lo spegnimento automatico del pc (ora devo premere il tasto fisico) o la visualizzazione della carica residua della batteria.

Spero che qualcuno abbia dei suggerimenti a riguardo anche in merito a quali log controllare.
Se il problema è parzialmente risolto con le indicazioni che ho dato ti consiglio di cambiare l'oggetto della discussione.

Njkjta

[Aki]

@njkjta:
Invia il log di /var/log/syslog. Inoltre, prova a passare a grub, invece dell’opzione ACPI=off , l’opzione rootdelay=20 e verifica se il malfunzionamento continua a presentarsi.

[njkjta]

Ciao Aki, grazie del supporto.
In allegato il file syslog che ho "ripulito" in modo tale che riporti solo un avvio con acpi attivo ed il successivo con acpi=off che permette di accedere al sistema.
Ho provato anche l’opzione rootdelay=20 ma il problema all'avvio persiste; se può servire genero il log anche con questa modifica.

Grazie,
Njkjta

[s3v]

https://www.reddit.com/r/debian/comment ... bernation/

Che porta qui: https://askubuntu.com/questions/1116778 ... 95#1116795

EDIT
Rinomino il titolo della discussione per renderlo aderente al problema.

EDIT2:
In quel messaggio si fa riferimento all'UUID della partizione di swap. Viene anche accettato RESUME=NONE .

[njkjta]

Ciao s3v, ho controllato il contenuto del mio file 'resume' e riporta correttamente l'UUID della mia partizione di swap.
Ho comunque provato a sostituirne il contenuto anche con il valore NONE:

Codice: Seleziona tutto

$ echo "RESUME=NONE"|sudo tee /etc/initramfs-tools/conf.d/resume
RESUME=NONE
$ sudo update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
W: initramfs-tools configuration sets RESUME=NONE
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/sda5
I: (UUID=0859c117-87fb-43ba-aef6-7806ef082c3b)
I: Set the RESUME variable to override this.


ma al boot, dopo aver rimosso temporaneamente l'opzione acpi=off, il blocco del sistema si ripresenta.

[Aki]

@njkjta:
Ho letto il file log.tar.gz, nel quale non c'è (apparentemente) traccia dell'errore che hai inviato (foto) nel primo messaggio relativamente alla impossibilità del kernel (in fase di avvio con montato l'initramfs) di trovare il root file system con uno specifico UUID. Dal log inviato, questo UUID non l'ho reperito né nella prima (avvio senza acpi=off) che nella seconda parte (avvio con acpi=off) del log. Questo può far ipotizzare che tale UUID è presente in qualche file di configurazione nell'initramfs, magari residuo di qualche precedente configurazione / installazione e/o presente ancora nella configruazione del root file system.

La partizione dall'UUID "misterioso" non sembra essere quella di swap (che ha un UUID diverso, riportato nel log di avvio con acpi=off) come anche s3v ha giustamente evidenziato con il suo precedente intervento.

Allora, gli script di avvio nell'initramfs da dove prendono questo UUID ?

Potrebbe essere utile che fornissi i log mentre sei con l'initramfs attivo (dopo il fermo con l'errore) ed, inoltre, analizzassi l'initramfs, che puoi eventualmente decomprimere dopo aver avviato il sistema con acpi=off (per analizzarne i contenuti) oppure inviare come file binario con un servizio come http://tinyupload.com o con quello che maggiormente ti aggrada.

[njkjta]

Scusate, involontariamente devo aver allegato la foto della prima installazione, quella tramite netinstall, mentre l'installazione attuale è la versione mate unofficial completa di driver non-free per l'attivazione del wifi (speravo di risolvere con i driver proprietari). Il file di log è relativo a questa seconda installazione, per questo c'è discrepanza con l'uuid.

[Aki]

Scusate, involontariamente devo aver allegato la foto della prima installazione, quella tramite netinstall, mentre l'installazione attuale è la versione mate unofficial completa di driver non-free per l'attivazione del wifi (speravo di risolvere con i driver proprietari). Il file di log è relativo a questa seconda installazione, per questo c'è discrepanza con l'uuid.

In tal caso, fornisci i corretti riferimenti all’errore che ti si presenta e quanto ti ho chiesto nel mio precedente messaggio.

[njkjta]

Vi aggiorno stasera quando torno da lavoro e posso mettere mano sulla macchina.

Grazie

[Aki]

Grazie per la risposta. Credo di aver trovato un bugreport specifico: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916696 con l’indicazione per la soluzione. Per ulteriori dettagli la patch è https://salsa.debian.org/kernel-team/in ... 2796b470c8

[njkjta]

Come suggerito, in attesa che il pacchetto initramfs-tools arrivi su Buster nella versione aggiornata, ho applicato la patch (riporto i passaggi così potete dirmi se ho commesso errori):
1) Ho sostituito il file /usr/share/initramfs-tools/hooks/resume con quello aggiornato;
[/code]
2) Ho aggiornato initramfs

Codice: Seleziona tutto

sudo update-initramfs -u -k all


3) Ho spento e poi riavviato la macchina.

Purtroppo anche con la patch il boot non si conclude positivamente: rispetto alla iso netinstall che si bloccava nella fase di initramfs, come riportato nella foto, ora la Debian Buster che ho installato (la versione amd64 con firmware non-free) esegue alcune fasi del boot e poi lo schermo si spegne senza permettermi di intervenire in console. Ho notato che non devo forzare (pressione prolungata) lo spegnimento ma basta premere poco il pulsante fisico di accensione per eseguire lo spegnimento , come se fosse già nello stato di halt (come avviene con ACPI=off).

Come detto in precedenza, se accedo al pc con ACPI=off la macchina funziona e il file resume contiene l'UUID=0859c117-87fb-43ba-aef6-7806ef082c3b che corrisponde alla mia partizione sda5 di swap.

Allego il syslog aggiornato con il primo avvio con acpi attivo ed il secondo avvio (da riga 1226) con ACPI=off.
Nel primo avvio non trovo l'UUID della swap a differenza del secondo avvio.

Riporto il link del file compresso initrd.img che supera i 50 MB

A margine delle prove effettuate ho continuato a fare ricerche sui forum ed ho trovato altri casi analoghi al mio relativi ad installazioni pulite di Buster fallite su hardware funzionante con stretch e collegate al problema del "resuming from hibernation"", però non ho letto suggerimenti risolutivi, tranne quello di procedere con l'installazione di Stretch e successivo upgrade a Buster.
Visto che si tratta di un pc muletto non ho urgenza di risolvere se pensate che possa essere utile posso anche reinstallare la versione ufficiale netinstall con il problema mostrato in foto.

[Aki]

@njkjta:
Dai log che hai inviato, l'errore indicato all'oggetto di questa discussione risulterebbe essere stato risolto, quindi il malfunzionamento che adesso riferisci sembrerebbe essere di natura diversa, probabilmente legato alla gestione energetica della scheda grafica. In tal senso, penso sarebbe opportuno aprire una discussione specifica. Per il momento, comunque, analizzando i log a confronto risulta quanto segue nel log in allegato a seguito del comando

Codice: Seleziona tutto

 $ grep -i "radeon\|linux version" syslog

Nel confronto, ho notato che, in caso di acpi=off, non viene avviato il servizio che regola la luminosità dello schermo, che invece è avviato nella prima sezione del log relativa al boot senza acpi=off:

Codice: Seleziona tutto

Aug  7 23:33:37 Scirocco systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:radeon_bl0...
Aug  7 23:33:37 Scirocco systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:radeon_bl0.


Inoltre, il servizio "Load/Save Screen Backlight Brightness of backlight:radeon" risulterebbe essere avviato due volte (strano). L'avvio di questo servizio è compatibile, naturalmente, con l'avvio di una funzionalità comunque collegata alla risparmio energetico, ma poiché riferisci specificamente nella descrizione del malfunzionamento (ultimo tuo messaggio) che lo schermo "diventa nero", questo servizio potrebbe essere implicato. Pertanto, ti suggerirei di disattivarlo tramite systemctl, verificare che effettivamente non sia avviato automaticamente all'avvio del sistema operativa e, quindi, verificare se ne hai un beneficio. In caso di esito negativo, suggerirei di aprire una discussione specifica essendo off-topic rispetto all'argomento (risolto, nel tuo caso, se ho ben compreso e te ne chiedo conferma) della presente discussione (Debian non parte: "resuming from hibernation")

[njkjta]

A quanto pare sono stato sfortunato con questa installazione con doppio bug...
@Aki: Ti ringrazio per l'analisi dettagliata. In realtà avevo pensato inizialmente anche ad un problema sul risparmio energetico della scheda grafica ed avevo provato a rimuovere la funzionalità al boot con l'opzione 'amdgpu.runpm=0' ma senza risultato (anche ora dopo la modifica del resume). Farò ulteriori verifiche seguendo anche le tue indicazioni ed eventualmente aprirò una nuova discussione.

Approfitto della comunicazione per chiedere se l'utente 'ilpescatorefolle' ha potuto fare delle prove sulla base di quanto è stato discusso ed eventualmente darcene riscontro.

Grazie,
Nkjta