Il kernel Xubuntu 18.04 impiega molto tempo ad avviarsi


10

Dopo l'aggiornamento dalla 17.10, ho riscontrato tempi di avvio più lunghi. All'inizio ci sono voluti più di 5 minuti. dmesgha rivelato che il colpevole era un'unità floppy inesistente, che il kernel ha cercato di trovare.

Rimuovendo prontamente quello, i 5 minuti sono scesi a circa 40 secondi, che ritengo siano ancora più di quelli necessari prima dell'aggiornamento. L'esecuzione di dmesgnuovo mostra che occorrono 30 secondi per montare un filesystem ( output completo ), con il seguente messaggio:

[   36.362834] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Sto eseguendo l'avvio da un SSD, con altri due dischi rigidi collegati, uno dei quali è formattato in ext4, ma non contiene dati di sistema. Presumo che questo sia l'SSD. Durante questi 30 secondi, non viene visualizzato alcun testo, né splash, solo uno schermo vuoto.

Ora, ho detto che sembra più lento di prima dell'aggiornamento, perché non ho tempi esatti da prima, quindi la mia prima domanda è, è normale impiegare 30 secondi per montare un filesystem e, in caso negativo, come saperne di più su cosa potrebbe causare il ritardo?

MODIFICA 1:

L'attivazione o la disattivazione dello scambio non ha alcun effetto

Nel frattempo ho anche installato un altro disco rigido nel mio computer. Sembra che abbia prolungato ulteriormente il mio tempo di avvio di circa 10 secondi, con un'altra linea che appare in dmesguscita, proprio prima del suddetto ritardo di 30 secondi:

[    3.312351] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   17.169519] random: crng init done
[   51.611617] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

MODIFICA 2:

systemd-analyze blamei risultati sono qui

nel frattempo, dopo diversi riavvii, le dmesglinee che ho incolpato sopra hanno cambiato i loro tempi in questo modo:

[    3.348384] hid-generic 0003:09DA:F613.0005: input,hiddev0,hidraw4: USB HID v1.11 Keyboard [COMPANY USB Device] on usb-0000:00:12.1-1/input2
[   34.091886] random: crng init done
[   36.488321] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)

Farò un paio di riavvii per scoprire se questo cambia casualmente o rimane lo stesso (il blocco di codice nella prima modifica è dal primo avvio dopo aver inserito l'HDD aggiuntivo).

EDIT 2.5: il random: crng init donesolito appare in tempi come mostrato nella modifica 1, raramente come nella modifica 2. Sembra essere ... casuale.


Puoi eseguire systemd-analyze blamee modificare la tua domanda per includere l'output di questo comando?
vidarlo,

L'ho eseguito prima e la somma dei risultati era inferiore a 8-9 secondi, quindi ho pensato che sarebbe stato irrilevante. Ho aggiunto i risultati.
Jes Wanson,

Risposte:


17

Ho avuto lo stesso problema. Durante i messaggi di avvio si direbbe che è scaduto in attesa del riavvio del dispositivo. Controlla /etc/initramfs-tools/conf.d/resumese c'è UUID come RESUME=some-uuidrimuovi uuid e sostituiscilo con "none" RESUME=none. Dopo quella corsa sudo update-initramfs -uk all, dovrebbe andare bene.


2
Finalmente! Questo ha risolto un problema che ho esaminato per innumerevoli ore - ora ha dimezzato il tempo di avvio. Informazioni utili su questo curriculum: askubuntu.com/questions/1057556/…
Casperrw,

1
questo sembra funzionare anche per me, ho avuto circa 38 secondi di avvio prima e 8 secondi dopo.
Pablo Pazos il

Il problema è apparso per me dopo l'aggiornamento della distro dal 16.04 al 18.04 - e questo metodo rimuove anche il ritardo degli anni 30 per me.
Bonlenfum,

5

Ho avuto questo problema numerose volte e la mia soluzione funziona in tutte le situazioni.

Quando si esegue dsmeg, l'errore viene visualizzato come:

[    6.382044] random: crng init done
[    6.382048] random: 7 urandom warning(s) missed due to ratelimiting
[   32.162934] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)

La soluzione è:

Per prima cosa confronta il tuo fstab e blkid:

$ blkid
/dev/sda1: UUID="C0C0-7641" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1085d848-f8b9-45e2-a6be-087acb32a820"
/dev/sda3: LABEL="Windows" UUID="8662302C623022FB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="de399a3e-c832-4dca-a09d-f65789425b89"
/dev/sda4: LABEL="Windows RE tools" UUID="2262513962511341" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="18feb4e1-5770-4e13-92b8-bb8ba8005536"
/dev/sda5: UUID="81a474ab-98bf-4d40-b03e-e5e647163d7e" TYPE="ext4" PARTLABEL="Arco Linux" PARTUUID="3759200f-6317-4487-8b10-3a0140c67bd5"
/dev/sda6: LABEL="rootMX17" UUID="7bae9e4d-61fa-4187-b11f-517c799f7c94" TYPE="ext4" PARTLABEL="MX Linux" PARTUUID="417c8cbd-11b7-4fe6-9b15-ac9082d74460"
/dev/sda7: UUID="d9539219-1c29-468f-bbd0-106663fdef59" TYPE="swap" PARTLABEL="Swap" PARTUUID="fefe3061-bf7b-4a26-8c20-08e209acc28e"



$ sudo nano /etc/fstab


# /etc/fstab: static file system information
#
# Created by make-fstab on Mon Nov 19 17:10:30 EST 2018

# <file system>                            <mount point>                               <type>     <$

#-> /dev/sda6  label=rootMX17
UUID=7bae9e4d-61fa-4187-b11f-517c799f7c94  /                                           ext4       d$
#-> /dev/sda1
UUID=C0C0-7641                             /boot/efi                                   vfat       d$
#-> /dev/sda7
UUID=42e5a9cd-b6e1-4d57-9a3a-2ad910862579  swap                                        swap       d$

Come puoi vedere il mio swap su / dev / sda7 ha un UUID diverso in fstab rispetto a blkid. Questo è stato, nel mio caso, causato da un'altra installazione di Linux che ripartiziona lo swap e causa la modifica dell'UUID. Il ritardo di avvio è causato dal sistema che cerca di trovare il nuovo UUID dello swap. Per risolverlo, basta copiare l'UUID in blkid che non corrisponde al file fstab, quindi salvare.

Se dopo il riavvio l'errore di avvio è ancora presente, è necessario modificare ulteriormente il file initramfs.conf.

Fallo tramite:

$ sudo nano  /etc/initramfs-tools/conf.d/resume

Quindi, creando un nuovo file o modificando il file di ripresa corrente, scrivi sulla prima riga RESUME = UUID = << UUID di scambio >>

Ad esempio, il mio sembra

RESUME=UUID=d9539219-1c29-468f-bbd0-106663fdef59

Quindi eseguire il comando seguente per aggiornare il file initramfs.

#sudo update-initramfs -u

Quindi riavviare. L'errore sparirà.


1

Ho sperimentato un aumento simile dei tempi di avvio e dopo aver indagato con dmesge systemd-analyze blameil colpevole sembrava esserlorandom: crng init

Il problema sembra non essere abbastanza entropia nell'avvio dall'SSD per l'inizializzazione. Questa ipotesi sembra essere confermata perché agitando un po 'il mouse durante l'avvio, il tempo di avvio diminuisce di circa 2 minuti per avvicinarsi a quello che era prima.


1

All'avvio, il kernel attende i movimenti del mouse per inizializzare il generatore di numeri casuali. Messaggi del kernel all'avvio:
sudo dmesg | less

Il problema:
kernel: random: crng init done

La soluzione:
sudo apt install haveged
sudo systemctl enable haveged


0

Ho avuto quel problema con il tempo di avvio lento su Ubuntu 19.04 dopo aver riscritto la partizione di swap e aver creato il file di scambio.

L'output di dmesg

[    2.220963] hid-generic 0003:1B1C:1B0F.0003: input,hidraw2: USB HID v1.11 Device [Corsair Corsair M45 Gaming Mouse] on usb-0000:00:14.0-1/input2
[   33.321639] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null)
[   33.407323] systemd[1]: RTC configured in localtime, applying delta of 120 minutes to system time.
[   33.417651] systemd[1]: Inserted module 'autofs4'

Nessun file di scambio in / etc / fstab. Tutti i dischi / uuidi montati erano corretti.

Ho controllato /etc/initramfs-tools/conf.d/resumema quel file mancava.

Io corro e basta

sudo update-initramfs -uk all

E ora si avvia molto velocemente.

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.