Ecco un paio di fix per questo problema che, a dispetto del nome, non c’entra nulla con KDE.
Il bug e’ stato segnalato tempo fa nella versione 7.04 di Ubuntu ma si puo’ riscontrare tutt’ora anche sulla 7.10 . Giusto ieri sera mi e’ capitato tra le mani un notebook della Compaq che all’avvio (circa 2 minuti) presentava il caratteristico messaggio:

Loading, pease wait…
Kinit: name_to_dev_t(/dev/disk/by-uuid/3c7a8f65-b709-494a-92f1-318a38220def)= sda5(8,5)
kinit: No resume image, doing normal boot…

Ho letto un po’ cercando di capire esattamente cosa potesse essere, a parte qualcosa relativo all’UUID, la cui introduzione ha portato piu’ sventure che fortuna..
Alcuni pensano possa trattarsi di un “sistema svegliato male” dal suspend precedente, sta di fatto che non tutte le soluzioni, nei feedback, sembrano sbloccare la situazione.
Io abbraccio questa ultima teoria perche’ succede spesso anche a me quando spengo “brutalmente” il notebook per testare, ad ogni nuova versione di kernel, varie combinazioni per ottenere un suspend che sia davvero un suspend (su RAM) e un Ibernazione che sia davvero un ibernazione (suspend su disco)
Vediamo nel dettaglio quali sono questi fix:

1- Metodo Divilinux

Aggiungiamo al file /boot/grub/menu.lst l’opzione noresume, esempio:

sudo kate /boot/grub/menu.lst

La stringa di avvio del nostro kernel diventera’:

title Ubuntu 7.10, kernel 2.6.23-real
root (hd0,0)
kernel /boot/vmlinuz-2.6.23-real root=UUID=3c152956-f11a-4692-8b77-54a70b14a0d9 ro quiet splash noresume
initrd /boot/initrd.img-2.6.23-real
quiet

Lanciamo:

sudo update-initramfs -u

2- Modificare direttamente l’initramfs
sudo kate /etc/initramfs-tools/conf.d/resume
Disabilitiamo la voce:

RESUME=XXXXx-XXX-XXXX-XXXX

Anteponendo il simbolo “#“:

#RESUME=XXXXx-XXX-XXXX-XXXX

Salviamo il file e lanciamo:

sudo update-initramfs -u

Spero di avervi regalato qualche ora di sonno in piu’, pero’ ricordo che queste modifiche disabilitano si i messaggi di warning eliminando l’attesa lunghissima al boot..ma di fatto rendono impraticabili sia il suspend che l’hibernate.

SEMI-OFF-TOPIC: Non vorrei rigirare il coltello nella piaga:

Nemmeno col kernel 2.6.23 si riesce a mandare in letargo (su disco o su ram) il nostro sistema (utilizzando lo stage S3 dell’acpi):

echo disk > /sys/power/state

Suspend su RAM:

echo -n mem > /sys/power/state

Bug n° 103148

😉

Related Posts Plugin for WordPress, Blogger...

Il tuo indirizzo ip:
3.234.214.113

Valutazione 3.00 su 5
happy wheels 2 demo

Category:

Senza categoria

Tags:

Commenti via Facebook:

Leave a Reply

Your email address will not be published. Required fields are marked *

*

19 Comments

  • Maramax ITALY 12 anni ago

    Guarda che secondo me quelli non sono degli warning, ne dei problemi.

    Si tratta solamente della normale procedura di boot: viene effettuato un controllo nello swap e se è presente l’immagine del sistema “ibernato” allora viene “scongelato” altrimenti (ed è il caso da te indicato) si procede al normale boot “pulito”.

      Quota

  • Concordo in pieno con Maramax, tant’è che io ho sempre quel messaggio, ma non ho problemi nella velocità di avvio ne di nessun’altra natura.

      Quota

  • @Maramax
    Ad alcuni il resume rimane fisso..anche se si riavvia per diverse volte il sistema.
    Meglio saperlo comunque..alla fine il boot va avanti, su questo non c’e’ dubbio..ma prima di prendere provvedimenti affrettati o che possono provocare disastri, io preferisco sempre chiarire di cosa si tratta ..

      Quota

  • @Cobra78
    vedi..anche a te rimane..
    Pero’ sei fortunato visto che non hai rallentamenti al boot

      Quota

  • Purtroppo resume e suspend danno un sacco di problemi…su KDE. Disperato, sono passato a GNOME da un paio di settimane, sempre su Ubuntu, e non ho più avuto problemi di sorta – quindi il problema NON riguarda il kernel. Da quel che dice un mio amico informatico, il problema sta tutto nell’interfaccia di KDE al kernel, che è diversa da quella di GNOME (che utilizza dbus). Siccome in KDE4 cambiano appunto l’interfaccia del kernel di KDE con dbus, i nostri problemi a proposito di suspend e resume potrebbero essere vicini ad una felice conclusione 😀

      Quota

  • @Luca
    mi spiace ma il suspend non c’entra nulla col desktop manager..
    Il tuo amico, se e’ informatico, dovrebbe sapere che il suspend e l’hibernate dipendono dall’acpi
    D-bus e’ un layer che riceve le informazioni da hal quando si collegano le periferiche..anche questo non c’entra molto col desktop manager, visto che sono tool di sistema e non di kde gnome xfce o altro..
    In Kde4 cambiano l’interfaccia del kernel di kde??..ma sai quello che stai dicendo?
    😀

      Quota

  • masand UNITED STATES 12 anni ago

    Grazie Divi!!!

    Proprio un paio di giorni fa avevo messo Kubuntu 7.10 sul portatile di un mio collega (HP) e, nemmeno a dirlo, il problema si è presentato da subito rendendo il boot molto lungo…

    Ho letto la tua guida e ho risolto al volo…

    Grazie ancora!!!

    Un saluto a tutti…
    masand

      Quota

  • @ Divilinux: be’ di sicuro D-bus ci sara’ di default su KDE4…

    http://en.wikipedia.org/wiki/Dbus

    In particolare,

    D-Bus is designed for two specific cases:
    […]
    -Communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes.

    se cio’ che dici e’ vero, mi spieghi perche’ da quando ho cambiato DE, da KDE a GNOME, sempre su Ubuntu, il resume va sempre liscio (NetworkManager a parte, ma quello e’ buggato di suo :P)? 🙂

    Ah cmq se ci sono strafalcioni…sappi che di informatica mi intendo solo un poco, studio biologia 🙂

      Quota

  • @Luca
    D-bus c’e’ gia’ da una vita, quindi col kde4 non vanno certo ad introdurlo..
    La domanda che fai e’ fuori luogo e anche un po’ ad indovinello visto che non lo posso sapere con precisione..per me potresti anche avere installato un nuovo kernel tra gli aggiornamenti..poi il fatto di cambiare da kde a gnome ti ha fatto pensare che dipenda dal desktop manager ma non e’ proprio cosi’
    Ma dimmi allora, come mai a me il suspend e l’ibernazione funzionano perfettamente pur avendo KDE?..inoltre se vedi l’ultima immagine che ho incluso riguarda proprio la sezione acpi del kernel..e HIBERNATION e SUSPEND sono due moduli compilati internamente
    Ma a parte questi strafalcioni..(si e’ qua per imparare giusto)?..ti passo anche:

    http://rtr.ca/dell_i9300/

    dove un utente spiega ottimamente come sistemare il suspend su di un Dell..e questo utente ha Kubuntu
    D-bus mette in comunicazione alcuni eventi del kernel, come ti dicevo prima (quando si monta un hdd sul desktop, la dialog che spunta e’ opera di hal che passa le informazioni a d-bus) ma c’e’ gia’ (hal+dbus sono fissi da circa due anni)
    Il suspend e l’hibernations non a tutti funzionano per via delle tabelle ACPI sballate o diverse da bios a bios..senza contare i bug come il pnp o altri..che fortunatamente non tutti abbiamo.
    Se ti interessa sapere come utilizzare il suspend e l’hibernation senza passare per l’acpi puoi leggere questo articolo

    http://divilinu.wordpress.com/2007/05/07/abilitare-suspend-e-hibernate-feisty/

    Un altra cosa..kde non ha nessun kernel..linux e’ il kernel..mentre kde, gnome, xfce, e17 sono solo desktop-manager..fanno parte del sistema non del kernel..tant’e’ che puoi tranquillamente rimuovere kde e X e usare solo la riga di comando
    Io non dico che non ti intendi di informatica, non posso saperlo, ma di linux vedo che stai muovendo ora i primi passi.
    Quello che dico non sono mie teorie o cose inventate..questo e’ un blog prossimo al milione di consultazioni e la frequenza giornaliera si aggira sui 6000 utenti..
    Ah dimenticavo:

    D-Bus is designed for two specific cases:
    […]
    -Communication between the desktop session and the operating system, where the operating system would typically include the kernel and any system daemons or processes.

    – Comunicazioni tra sessione desktop (non specificato quale) e il sistema operativo (ubuntu ad esempio), dove per sistema operativo si intende l’insieme di kernel + demoni o processi + desktop manager.
    Spero di averti chiarito le idee, anche se dovevo stare stretto con le spiegazioni, altrimenti per quanto mi riguarda puoi anche pensare che sia colpa di kde e andare in giro a raccontarlo..

    😉

      Quota

  • @Divilinux

    Be’ ok grazie mille 🙂 Adesso rileggo con più calma e vedo di capire meglio come funziona il tutto…cmq non sono nuovo a Linux (uso (K)ubuntu da un anno circa) ma diciamo che a parte poche cose sono sempre rimasto più utente che informatico 😀 (cmq almeno al fatto che kde=!kernel linux ci arrivo 😉 ).

    Grazie mille per il link (ho un inspiron in effetti)…il problema è che i miei dispiaceri iniziano soprattutto con il suspend dopo chiusura del lid…che nella guida linkata viene disabilitato 🙁 Suspend senza usare il lid *credo* funzioni ma non ne sono sicuro (scusa per la mia imprecisione in precedenza). In generale la cosa è aleatoria…ogni tanto invece di fare il resume fa il reboot :/

    Come kernel utilizzo quello Vanilla di linux, non ho fatto compilazioni e installazioni personalizzate, quindi il problema non è di sicuro lì 🙂

      Quota

  • @Luca
    per il lid e’ piuttosto semplice, nel file

    /etc/default/acpi-support

    si possono configurare tutte queste cose..se non sbaglio l’opzione e’ questa:

    # Should we switch the screen off with DPMS on suspend?
    #USE_DPMS=true

    va commentata o il monitor non si riaccende dopo la sospensione…credo he..non vorrei sbagliarmi

      Quota

  • filo1234 ITALY 12 anni ago

    Ho sempre notato quel messaggio…ma non mi sono mai posto la domanda…è un problema?? visto che si avviava tutto tranquillamente e vedevo quel messaggio anche su altri pc…ma è un problema reale??e cosa comporta?? grazie

      Quota

  • @filo1234
    non e’ compromettente per l’avvio del sistema, e’ solo una funzione che cerca di “resumare” una precedente sospensione..

      Quota

  • ciao divi 🙂
    hai provato con il kernel 2.6.24rc2 ? a me con quello il resume funziona 🙂

      Quota

  • @graymalkin
    no, non l’ho provato quel kernel..ma lo faro’ al piu’ presto
    Non ho problemi di suspend..ho solo voluto provare quelle due nuove feature del 2.6.23..che puntualmente non hanno funzionato.

      Quota

  • @Divilinux

    Spiacente di deluderti :'( Io non so il motivo, ma mentre sotto GNOME le azioni relative alla apertura/chiusura del display (mandare in sospensione su RAM) funzionano SEMPRE senza problemi, su KDE non è così; a volte funzionano, a volte no, in maniera totalmente imprevedibile. Questo con tutto configurato per funzionare. Per me il portatile è un sistema mobile, che utilizzo ad esempio anche a lezione per prendere appunti, e quindi la sicurezza che quando chiudo il lid il computer si sospenda è fondamentale.
    Spero vivamente di avere ragione nel dire che passare da DCOP a DBUS in KDE4 risolverà questo problema, perché altrimenti mi sa che resterò fisso con GNOME. Mi piace molto meno, ma funziona -_-.

      Quota

  • Avevo lo stesso problema.
    Per riuscire ho dovuto però modificare la riga di /boot/grub/menu.lst
    # defoptions=quiet splash
    in
    # defoptions=quiet noresume
    Grazie davvero.

      Quota

  • @medd
    una leggera variante su quello indicato nell’articolo
    L’importante, come sempre, e’ che funzioni
    😉

      Quota

Pings

  1. Il finto errore di “Kinit” ITALY WordPress 16 Agosto 2010