Il riavvio si blocca al 100%, possibilmente in mountall


8

AGGIORNAMENTO: sembra che mountall sia sospeso all'interno della routine emit_event (), che chiama dopo / viene rimontato per emettere un evento in tal senso. All'interno di emit_event, chiama ply_boot_client_flush (), quindi costruisce l'array env, chiama upstart_emit_event (), quindi dbus_pending_call_block (). E lì si blocca. Quindi qualche idea sul perché dbus_pending_call_block si bloccherebbe indefinitamente? Plymouth rotta? dbus? upstart? Qualche suggerimento per correzioni o ulteriore diagnostica?

Il riavvio della mia macchina Ubuntu 10.04 LTS, 64 bit AMD si blocca al 100%. La spia di accesso all'unità è spenta, ma i tasti alt-sysreq funzionano. L'hardware è un laptop Lenovo W700ds. Ora, mi scuso in anticipo, perché sono molto limitato nelle informazioni sul sistema che ho a disposizione e in quello che posso fare con esso (perché non si avvierà). Posso eseguire l'avvio dal CD 10.04, utilizzandolo come un disco di ripristino. Riesco a montare, montare, leggere e scrivere sulle mie partizioni: stanno bene. Ho già provato a riformattare il mio scambio con mkswap. Ho 4 partizioni ext4 sul mio sistema: sda1 è /, sda2 è / usr, sda3 è / home e un quarto che uso per l'archiviazione dei dati / sdb1 (è l'intero disco, monta sul mountpoint / hdb che ho creato) . C'è anche / sda4 che è swap. In questo momento sto scrivendo questo da un browser che ho aperto nella "sessione di salvataggio" dal 10.

Vorrei NOTEVOLMENTE apprezzare suggerimenti / commenti su cosa avrei potuto fare per aiutare a diagnosticare ciò che è appeso, perché e che cosa potrei fare per risolvere il problema. Ho già fatto una ricerca sul web, ma non ho trovato nulla di nuovo in questo senso (alcuni bug report di 1-1,5 anni con sintomi simili, ma le loro correzioni non funzionavano).

Ho installato 10.04 su un nuovo disco intorno al primo luglio, quindi ho usato aptitude per aggiornare tutto. Da allora ho installato LOTTIdi pacchetti (allego il registro dpkg di seguito). Con sda da 750 GB (/ 20 GB, / usr 80 GB) avevo molto spazio per installare i pacchetti che "un giorno avrei potuto usare". Mi chiedo se è uno di questi pacchetti che ho installato che ha rovinato il mio sistema? Ho installato il kernel 2.6.32-32-generico e riavviato, ma da allora ho installato molti più pacchetti. Riavvio il computer il più raramente possibile, preferendo ibernarlo mentre vado da un posto all'altro. Ultimamente, però, ho notato uno strano comportamento associato alla sospensione: quando il sistema si disattivava, visualizza lo screen saver gnome con la password necessaria per sbloccare - beh, non riconosceva la mia password! Ho dovuto alt-F1, accedere come root e uccidere lo screen saver. Quindi tutto andrebbe bene, o almeno così sembrava. Anche, dopo il letargo vedevo spesso per un attimo mentre lampeggiavano spazzatura colorata sullo schermo. Sarebbe andato via, quindi non ho cercato di trovare la causa. Un altro punto forse rilevante è che avevo bisogno di usare "nomodeset" nell'installazione di 10.04, e quando richiamo la shell di salvataggio dallo stesso CD, se uso solo nomodeset alla fine si bloccherà con un LED NumLock o Caps Lock LED lampeggiante ( crash?), ma se uso anche "noapic nolapic acpi = off", allora va bene. Ho provato queste opzioni con il mio sistema per vedere se risolvono il problema di blocco dell'avvio - non lo fanno. se uso solo nomodeset alla fine si bloccherà con un LED NumLock lampeggiante o BLOC MAIUSC (crash?), ma se uso anche "noapic nolapic acpi = off", allora si presenta ok. Ho provato queste opzioni con il mio sistema per vedere se risolvono il problema di blocco dell'avvio - non lo fanno. se uso solo nomodeset alla fine si bloccherà con un LED NumLock lampeggiante o BLOC MAIUSC (crash?), ma se uso anche "noapic nolapic acpi = off", allora si presenta ok. Ho provato queste opzioni con il mio sistema per vedere se risolvono il problema di blocco dell'avvio - non lo fanno.

Questa è una macchina che uso per lavoro così come per quasi tutto il resto, in modo da ottenere è di fare il boot di nuovo è un TOP priorità. / home è intatta, il che è buono. Ma sto cercando di diagnosticare (molto meno correzione) questa causa dello stivale sospeso.

Avvio il sistema e inizia a eseguire lo script di configurazione mountall in /etc/init/mountall.conf. Vedo l'output di mountall che esegue fsck - 4 righe che dicono: fsck da util-linux-ng 2.17.2 (che è uno per partizione ext4). Quindi ci sono altre 4 righe di fsck che informano l'utente che le partizioni sono state ritenute "pulite". E questo è tutto - tutto si ferma. Il LED di attività dell'unità si spegne. Posso usare i tasti alt-sysreq, ma finora non si sono dimostrati utili. Ho visto una segnalazione di bug in cui un utente utilizzava alt-sysreq-i per terminare il processo e lo ha fatto cadere in una shell. Per me, dice che ha ucciso i processi (udev e udev-bridge e plymouth, dice il suo risveglio udev, ecc.), Ma non ottengo alcun guscio.

Ho cercato di determinare cosa è esattamente appeso. A tal fine, ho armeggiato con /etc/init/mountall.conf. Ho aggiunto le righe dell'eco e ho aggiunto l'opzione -v (verbose) al exec di mountall. Non vengono mostrate linee di eco dopo che il exec di mountall è stato mostrato, quindi questo potrebbe significare che mountall è sospeso. In alternativa, potrebbe non essere visualizzato l'ultimo output, nel qual caso mountall potrebbe essere uscito e qualcos'altro potrebbe essere sospeso. Noto che alt-sysreq-i non dice che mountall è stato ucciso. Ho provato a restringere ciò su cui potrebbe essere sospeso il sistema commentando sda3 (/ home), swap e sdb1 (/ hdb) da fstab, ma si blocca ancora.

C'è molto che posso fare da solo, ma mi sento come se fossi sopra la mia testa qui. Vorrei, ad esempio, ottenere il codice sorgente per mountall, aggiungere flag stampati, ricompilarlo e incollarlo sul mio sistema - per restringere A) se mountall è in realtà sospeso e B) a cosa è sospeso. MA, non riesco ad avviare la mia macchina su una shell da cui compilare - e l'ambiente del disco di ripristino è solo 2.6.32-28-generico # 55 - quindi non corrisponderebbe al mio sistema. Vorrei rimuovere o reinstallare i pacchetti, ma ancora una volta non riesco ad avviare il mio computer e farlo.

(il mio file di registro di dpkg è composto da diversi MB, quindi lo allego in una finestra di dialogo seguente)

Grazie Greg


bene, se è possibile avviare chiavetta USB o livecd, montare i dischi lì è possibile eseguire il chroot nel computer e rimuovere i pacchetti. D'altra parte, hai detto che questo è il tuo computer di lavoro, ha la massima priorità. Quindi, confrontare il tempo dedicato alla ricerca di ciò che è sbagliato con il tempo di installazione pulita (hai casa su partizione separata)?
Denwerko,

Vorrei fare eco a @denwerko - probabilmente ci vorranno solo un paio d'ore per fare un'installazione pulita e quindi installare qualsiasi software aggiuntivo di cui hai bisogno. Inserisci una chiavetta USB / unità USB esterna e copia il contenuto di / home su di essa. Puoi ripristinarlo in seguito. Quanto alla "stabilità" - dipende - quali pacchetti hai installato e da dove? L'installazione di pacchetti da PPA e la compilazione di codice probabilmente causeranno maggiore instabilità rispetto all'installazione di pacchetti standard dal centro software / gestore pacchetti sinaptici.
Fossfreedom

@greg - quale hardware hai installato che necessitava di driver extra - ad es. scheda di rete / scheda grafica? Hai provato a semplificare il tuo desktop disabilitando / estraendo tutte le carte - lascia solo le basi come la grafica integrata e la tastiera cablata?
Fossfreedom

@Greg se questo viene risolto perché la loro risposta non è accettata? Segui le regole generali per AskUbuntu e aggiungi il tuo sollution alle risposte e accettalo.
Rinzwind,

Risposte:


1

Denwerko: Non ho fatto nulla alla mia macchina che avrebbe dovuto produrre questo risultato. Era abbastanza stabile con Ubuntu 9.10 - non è mai successo niente del genere. Tutto armeggiare con sorgenti, ricompilare cose - è stato tutto un codice spazio utente. Non ho armeggiato affatto con il sistema operativo. Né ho installato alcun codice spaziale del sistema operativo al di fuori dei canali standard (gestore pacchetti aptitude / synaptic, pacchetti deb ottenuti tramite tali strumenti). Greg ieri

Tuttavia, ho ottenuto il codice sorgente per mountall 2.15.3 e l'ho compilato nell'ambiente di ripristino, dopo 5 installazioni (libnih-dev, libnihdbus-dev, lindbus-1-dev, linudev-dev, libplymouth-dev) . Ho aggiunto stampe di debug nel codice tramite nih_info () chiamate e ho creato le spawn che eseguono il blocco fsck anziché il non blocco. Sto lavorando alla teoria che mountall si sta schiantando da qualche parte (o nih, o dbus o plymouth ...). A quanto pare non riesco a ottenere l'output nello stesso posto nel codice a ogni esecuzione, ma sembra fermarsi qualche volta dopo il rimontaggio di / dev / sda1 su / - nella routine montata (). Greg ieri

Ho anche fatto dpkg -r di pacchetti tramite chroot come hai suggerito, e sembra funzionare (tranne uno script di disinstallazione che voleva fare qualcosa con / proc). Ho disinstallato wine e i pacchetti di compatibilità a 32 bit necessari (lib32nss, ia32lib, lib32v4l, ecc.) E diversi pacchetti ibus che non sono installati nell'ambiente di salvataggio (alcuni pacchetti ibus lo sono, e sono stato attento a non rimuoverli) plasma-widget-kimpanel-backend-ibus, ibus-qt4, ibus-qt1. Niente di tutto ciò ha influenzato il problema, quindi ho rimosso più pacchetti che non mi servono ora (widget wx e pacchetti jdk, ecc.) -Non effetto

AGGIORNAMENTO: sembra che mountall sia sospeso all'interno della routine emit_event (), che chiama dopo / viene rimontato per emettere ed eventi in tal senso. All'interno di emit_event, chiama ply_boot_client_flush (), quindi costruisce l'array env, chiama upstart_emit_event (), quindi dbus_pending_call_block (). E lì si blocca. Quindi qualche idea sul perché dbus_pending_call_block si bloccherebbe indefinitamente? Plymouth rotta? dbus? upstart? Qualche suggerimento per correzioni o ulteriore diagnostica?

SOLUZIONE Quindi, sembra che avessi installato cloud-init e cloud-utils perché un giorno avrei voluto giocarci. Will, scopre che cloud-init si avvita con la configurazione di ureadahead e si avvia quando si verifica l'evento dbus 'montato /', che ha causato il blocco del mio sistema non appena ha inviato quel messaggio dbus, che si verifica dopo / viene rimontato da ro a r / w. Ho disinstallato cloud-init e cloud-utils e ora tutto sembra a posto. Tranne, ho sonno e ho perso 24 ore della mia vita: \

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.