L'avvio di Ubuntu 14.04 si blocca al logo dopo l'aggiornamento

2

Ieri ho fatto un update / dist-upgrade . Oggi, ho acceso la macchina ed era appeso alla schermata di caricamento con logo e punti in bicicletta: ho aspettato questa schermata per circa un'ora diverse volte senza risultati. Se interrompo upstart con ctrl-alt-del, l'avvio riprende / completa, ma mi mette al login della console tty. X inizia, pochi secondi dopo, ma viene immediatamente visualizzata una finestra di dialogo sulla grafica configurata in modo errato. Aggiornamento : il problema X è stato risolto facendo apt-get install nvidia-current . Il problema di interruzione è ancora presente.

Sfortunatamente, ogni vantaggio che ho trovato sul perché questo potrebbe accadere si è trasformato in un vicolo cieco. Ecco il mio boot.log (da /var/log ) che mostra dove ho interrotto l'avvio. Si può vedere che si blocca proprio mentre si avvia "abilita i dispositivi di blocco crittografati al tempo di avvio rimanenti" (questo è da cryptdisks ), ma la rimozione di quel servizio non fa differenza. Ho provato praticamente tutto da questa segnalazione di bug di menta , che descrive sintomi quasi identici ai miei, inutilmente. A questo punto, sono abbastanza sicuro che cryptdisks è un'aringa rossa e che è qualcosa di completamente diverso.

Ho anche scoperto che riprendere l'avvio dalla modalità di ripristino sembra caricare le cose in un ordine diverso. Upstart si blocca ancora, ma non dopo cryptdisks . Se ctrl-alt-del, mi porta al gestore di login grafico invece di un tty, e posso accedere con successo. Tuttavia, il sistema non è ancora completamente funzionante; Plug and play USB sembra non funzionare, non posso usare il mio secondo monitor, e devo fare manualmente start resolvconf per accedere a Internet. Ecco il file boot.log da uno di questi startup.

Devo aggiungere che sto crittografando il mio HDD con LUKS , e il blocco si verifica dopo aver inserito correttamente la password di decrittografia. Ecco il mio fstab , nel caso abbia qualcosa a che fare con le cose:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=9e7c1e90-f3e4-4075-b3b0-e3ccb6d933c7 /boot           ext2    defaults        0       2
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

Che sta succedendo qui?

    
posta Chaosed0 18.12.2014 - 21:45

2 risposte

4

La causa principale era un numero enorme di file nella mia directory /tmp .

Ho usato la directory /tmp per archiviare milioni di file in precedenza. Si scopre che avere tanti file lì causa il servizio che pulisce /tmp a richiedere molto, molto tempo (duh). Dopo aver spostato i file fuori da /tmp , il problema è risolto. Non aveva nulla a che fare con l'aggiornamento; è stata solo una coincidenza.

Nel caso in cui aiuti qualcuno più tardi, ecco il processo che ho usato per capirlo. Ho attivato la "chiave Magic SysRq" modificando etc/sysctl.d/10-magic-sysrq.conf . Quindi, ho riprodotto il problema riavviando; quando l'avvio si è bloccato, ho premuto Alt - SysRq - t . Questo ha scaricato quanto segue nel buffer del kernel, letto usando dmesg :

[   36.318527] SysRq : Show Blocked State
[   36.318696]   task                        PC stack   pid father
[   36.318719] find            D ffff88041dd93480     0   839    788 0x00000000
[   36.318721]  ffff880405d07a48 0000000000000082 ffff880401136000 ffff880405d07fd8
[   36.318723]  0000000000013480 0000000000013480 ffff880401136000 ffff88041dd93d18
[   36.318725]  ffff88041dfab460 0000000000000002 ffffffff811ef380 ffff880405d07ac0

Si scarica molto più di questo, ma questa è la parte rilevante. Questo mostra che l'attività bloccata è find . Dopodiché, era solo una questione di un amico informato sapendo che il /tmp del servizio di pulizia era un probabile colpevole.

    
risposta data Chaosed0 05.01.2015 - 22:04
3

Grazie, Chaosed0, per tornare con la tua soluzione (ovvero un numero enorme di file in / tmp). [Ho provato a postare questo come commento ma non ho abbastanza punti reputazione]

Mi sono imbattuto nello stesso problema con il server Ubuntu (14.04) ed è stato molto difficile diagnosticare fino a quando ho trovato il tuo post.

Quando ho riavviato la macchina, sembrerebbe bloccarsi proprio prima che normalmente mostrasse la console di login. Potrebbe essere sbloccato premendo Ctrl + Alt + Del , il che causerebbe la stampa di un messaggio di registro che wait-for-state (rcplymouth-shutdown) è stato terminato. Quel messaggio di log mi ha indirizzato lungo il percorso sbagliato di frugare vari script di plymouth e poi provare a disabilitare completamente la plymouth: - (

In realtà, il processo di avvio non era deadlock, era solo in attesa del completamento di /tmp per il completamento. Quella macchina aveva decine di migliaia di file sotto /tmp , quindi ci sarebbe voluto molto tempo per fare il clean-up.

Quindi la correzione per me era di avviare il ripristino, ottenere una shell di root e poi rm -rf /tmp/* . Dopo circa un'ora, il lavoro rm è stato completato. Poi ho riavviato e tutto ha funzionato normalmente.

Sarebbe fantastico se un messaggio di log potesse essere stampato quando inizia il clean-up di /tmp .

    
risposta data jamuir 10.02.2015 - 20:47

Leggi altre domande sui tag