Das Starten des Xubuntu 18.04-Kernels dauert lange

Nach dem Upgrade von 17.10 habe ich längere Startzeiten erlebt. Anfangs dauerte es mehr als 5 Minuten. dmesgenthüllte, dass der Schuldige ein nicht existierendes Diskettenlaufwerk war, das der Kernel zu finden versuchte.

Nachdem ich das sofort entfernt hatte, gingen die 5 Minuten auf ungefähr 40 Sekunden zurück, was meiner Meinung nach immer noch mehr ist als vor dem Update. Beim dmesgerneuten Ausführen wird angezeigt, dass das Mounten eines Dateisystems ( vollständige Ausgabe ) 30 Sekunden dauert. Die folgende Meldung lautet:

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

Ich starte von einer SSD mit zwei anderen angeschlossenen Festplatten, von denen eine in ext4 formatiert ist, aber keine Systemdaten enthält. Ich nehme an, das ist die SSD. Während dieser 30 Sekunden wird weder Text angezeigt, noch wird nur ein leerer Bildschirm angezeigt.

Jetzt sagte ich, dass es sich langsamer anfühlt als vor dem Update, da ich keine genauen Zeiten von vorher habe. Meine erste Frage ist also, ob es normal ist, 30 Sekunden zum Mounten eines Dateisystems zu benötigen, und wenn nein, wie man mehr herausfindet über was könnte die Verzögerung verursachen?

EDIT 1:

Das Ein- und Ausschalten des Swaps hat keinerlei Auswirkungen

Inzwischen habe ich auch eine andere Festplatte in meinen Computer installiert. Es scheint meine Startzeit um etwa 10 Sekunden weiter verlängert zu haben, wobei eine weitere Zeile in der dmesgAusgabe unmittelbar vor der oben genannten 30-Sekunden-Verzögerung erscheint:

[    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)

EDIT 2:

systemd-analyze blameErgebnisse sind hier

In der Zwischenzeit haben die dmesgZeilen , die ich oben beschuldigt habe, nach mehreren Neustarts ihre Zeiten folgendermaßen geändert:

[    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)

Ich werde ein paar Neustarts durchführen, um herauszufinden, ob sich dies zufällig ändert oder gleich bleibt (der Codeblock in der ersten Bearbeitung stammt vom ersten Start nach dem Einlegen der zusätzlichen Festplatte).

BEARBEITEN 2.5: Das random: crng init doneerscheint normalerweise in Zeiten wie in Bearbeitung 1 gezeigt, selten wie in Bearbeitung 2. Es scheint ... zufällig zu sein.

Ich hatte das gleiche Problem. Während der Startmeldungen wird angezeigt, dass das Warten auf die Wiederaufnahme des Geräts abgelaufen ist. Überprüfen Sie, /etc/initramfs-tools/conf.d/resumeob eine UUID enthalten ist, z. B. RESUME=some-uuidentfernen Sie die UUID und ersetzen Sie sie durch "none" RESUME=none. Nach diesem Lauf sudo update-initramfs -uk allsollte es gut sein zu gehen.

Ich hatte dieses Problem schon oft und meine Lösung funktioniert in allen Situationen.

Beim Ausführen von dsmeg wird der Fehler wie folgt angezeigt:

[    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)

Die Lösung ist:

Vergleichen Sie zuerst Ihre fstab und 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$

Wie Sie sehen können, hat mein Swap unter / dev / sda7 in fstab eine andere UUID als in blkid. Dies wurde in meinem Fall durch eine andere Linux-Installation verursacht, die den Swap neu aufteilte und die UUID änderte. Die Startverzögerung wird dadurch verursacht, dass das System versucht, die neue UUID des Swaps zu finden. Um dies zu beheben, kopieren Sie einfach die UUID in blkid, die nicht mit der fstab-Datei übereinstimmt, und speichern Sie sie.

Wenn nach dem Neustart der Startfehler weiterhin besteht, müssen Sie zusätzlich Ihre Datei initramfs.conf bearbeiten.

Tun Sie dies durch:

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

Schreiben Sie dann entweder durch Erstellen einer neuen Datei oder Bearbeiten der aktuellen Lebenslaufdatei in die erste Zeile RESUME = UUID = << UUID von Swap >>

Zum Beispiel sieht meine so aus

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

Führen Sie dann den folgenden Befehl aus, um Ihre initramfs-Datei zu aktualisieren.

#sudo update-initramfs -u

Dann neu starten. Der Fehler wird verschwunden sein.

Ich erlebte eine ähnliche Verlängerung der Startzeiten, und nach der Untersuchung mit dmesgund systemd-analyze blameder Schuldige schien zu seinrandom: crng init

Das Problem scheint nicht genug Entropie beim Booten von der SSD zur Initialisierung zu sein. Diese Hypothese scheint bestätigt zu sein, da das Wackeln der Maus während des Startvorgangs die Startzeit von etwa 2 Minuten auf ungefähr das verringert, was sie zuvor war.

Beim Booten wartet der Kernel auf Mausbewegungen, um den Zufallszahlengenerator zu initialisieren. Kernel-Nachrichten beim Booten:
sudo dmesg | less

Das Problem:
kernel: random: crng init done

Die Lösung:
sudo apt install haveged
sudo systemctl enable haveged

Ich hatte dieses Problem mit der langsamen Startzeit unter Ubuntu 19.04, nachdem ich die Swap-Partition entfernt und die Swap-Datei erstellt hatte.

Die Ausgabe von 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'

Keine Swap-Datei in / etc / fstab. Alle montierten Festplatten / UUIDs waren korrekt.

Ich habe nachgesehen, /etc/initramfs-tools/conf.d/resumeaber diese Datei fehlte.

Ich renne einfach

sudo update-initramfs -uk all

Und jetzt bootet es richtig schnell.