Debian non parte: "resuming from hibernation"

[s3v]

...in attesa che il pacchetto initramfs-tools arrivi su Buster nella versione aggiornata...

Se non aumentano la severità di quel bug (adesso è "normal"), la correzione non arriverà su Buster; a meno che non utilizzino i backports più in là.
Dovrebbero farglielo notare in quel bug: solo su questo forum ci sono state quattro persone con lo stesso problema che impedisce di avviare correttamente Debian.

[Aki]

...in attesa che il pacchetto initramfs-tools arrivi su Buster nella versione aggiornata...

Se non aumentano la severità di quel bug (adesso è "normal"), la correzione non arriverà su Buster; a meno che non utilizzino i backports più in là.
Dovrebbero farglielo notare in quel bug: solo su questo forum ci sono state quattro persone con lo stesso problema che impedisce di avviare correttamente Debian.

Ciao s3v, la cosa singolare è che nelle mailing list ufficiali di Debian (debian-italian e soprattutto quella internazionale debian-user) non sono riferiti malfunzionamenti di questo tipo da quando Debian Buster è stata rilasciata, il che mi fa pensare che in realtà per alcuni dei casi segnalati in questo forum le cause siano altre e, semplicemente, viene riferita nella segnalazione l’ultimo messaggio che appare a schermo. L’utente njkjta è stato in grado di fornire elementi utili ad orientare le verifiche e quindi è stato possibile confermare il bug.

Nella patch l’autore indica:

hooks/resume: Disable resume when there are no suitable swap devices
In 0.131 the automatic selection of a resume device was changed to
disable resume if the largest swap device was encrypted with a
ephemeral key.

In 0.132 I changed the automatic selection to also reject zram
devices, but I also changed it to loop over all swap devices since
zram might well be used alongside a conventional swap device that we
could use. Unfortunately, in case swap devices are available but none
are suitable, this results in selecting the last one.

Closes: #916696
Thanks: Trek <trek00@inbox.ru>
Signed-off-by: Ben Hutchings's avatarBen Hutchings <ben@decadent.org.uk>

Quanti utenti di questo forum hanno partizioni di swap cifrate con una “ephemeral key” (chiave cifrata casuale) o un file di swap altrimenti inutilizzabile con variabile di RESUME non valorizzata ?

[ilpescatorefolle]

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

purtroppo ho dovuto ridare al mio amico il pc, non so piu' se il problema è rimasto...
vedo pero' che si presente spesso quando c'è convivenza tra win10+deb10

[xtow]

Anche io avevo lo stesso problema del "resume" dovevo aspettare 1,30 minuti prima che il sistema si avviasse, mentre con la 9 non avevo nessun problema, in pratica individuava lo UUID della RAM in maniera errata. in pratica per scoprire lo UUID di cui vuole fare il "resume" basta dare il seguente comando

Codice: Seleziona tutto

grep -rw RESUME /etc/initramfs-tools/initramfs.conf         /etc/initramfs-tools/conf.d         /usr/share/initramfs-tools/conf.d/

Confrontarlo con UUID attuale,

Codice: Seleziona tutto

/sbin/blkid

e verificare quello scritto in /etc/fstab, nel mio caso erano completamente diversi. È bastato cambiare l'UUID (della RAM) per risolvere.