Lange Startverzögerung beim Laden von Ubuntu / Begrüßungsbildschirm nach regelmäßigem Dist-Upgrade bei sauberer SSD-Installation (18.04)

24

Ich habe am Tag der offiziellen Veröffentlichung 18.04 seit einer sauberen SSD-Installation ausgeführt, ohne Probleme.
Das Einschalten der Anmeldung dauerte Sekunden (max. 10).

Dann habe ich heute Morgen ein regelmäßiges Upgrade durchgeführt :

$ sudo apt update && sudo apt dist-upgrade

Die installierten / aktualisierten Pakete waren :

Install: linux-headers-4.15.0-24:amd64 (4.15.0-24.26, automatic), linux-headers-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-extra-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-image-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic)
Upgrade: gnome-control-center-data:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-headers-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-image-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), linux-signed-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center-faces:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-generic:amd64 (4.15.0.23.25, 4.15.0.24.26)

Ich habe nach Abschluss des Upgrades einen Neustart durchgeführt und auf dem Ubuntu-Lade- / Begrüßungsbildschirm (vor der Anmeldung) eine Verzögerung von 2-3 Minuten festgestellt (ohne Fortschritt / Aktivität auf den Punkten).

Ich habe mich ausgeschaltet und versucht, erneut zu booten, aber diese Verzögerung wird jetzt konstant angezeigt. Auch das Herunterfahren ist viel langsamer.

Update # 1 (2018-07-03):
Analyse auf systemd:

$ sudo systemd-analyze blame
3min 53.073s plymouth-quit-wait.service
    2min 20.699s snapd.seeded.service
         49.949s snapd.service
          6.186s NetworkManager-wait-online.service
          1.148s dev-sda2.device
          1.098s plymouth-start.service

Dies zu zeigen plymouth-quit-wait.service(was meiner Meinung nach mit dem Laden / Begrüßungsbildschirm von Ubuntu zu tun hat) und snapd.seeded.servicebei weitem die am längsten laufenden Dienste zu initiieren waren. Also habe ich die Zeiten vorher dist-upgradeund nachher verglichen :

$ journalctl -u plymouth-quit-wait.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:38:05 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:15:46 user-laptop systemd[1]: Started Hold until boot process finishes up.
-- Reboot --
Jul 03 04:21:17 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:24:52 user-laptop systemd[1]: Started Hold until boot process finishes up.

Vor dem Upgrade plymouth-quit-wait.servicedauerte 3 Sekunden . Nach dem Upgrade dauerte es 3 Minuten 35 Sekunden

$ journalctl -u snapd.seeded.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:42:14 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:15:43 user-laptop systemd[1]: Started Wait until snapd is fully seeded.
-- Reboot --
Jul 03 04:22:47 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:24:49 user-laptop systemd[1]: Started Wait until snapd is fully seeded.

Vor dem Upgrade snapd.seeded.servicedauerte 0 Sekunden . Nach dem Upgrade dauerte es 2 Minuten 2 Sekunden.

Update Nr. 2 (06.07.2018): Mit
dem Boot heute Morgen kehrte die Verspätung zurück .
Ich denke, wir warten immer noch auf das Kernel / Plymouth / Snapd-Update .

Update Nr. 3 (12.07.2018):
Das Problem scheint behoben zu sein , aber ich habe kein Update für Snap oder Plymouth gesehen, und ich verwende immer noch den Kernel 4.15.0-24. Ich bin mir also nicht sicher, welches Paket-Update das Problem behoben hat oder ob es sich selbst irgendwie gelöst hat. Beim Lesen der Bug-Updates auf dem Launchpad ist mir unklar, was mit welchem ​​Paket / welchen Paketen gemacht wurde (oder wird). Wenn jemand das klarstellen kann, wäre das sehr nützlich.

boot 18.04 snap plymouth Broadsworde
quelle
Scheint mir , wie snapD wurde Impfen (die Snap - Datenbank erfrischend) für 02.20. Ein seltenes Ereignis, nichts kaputt. Wenn dies jedes Mal der Fall ist, melden Sie einen Fehler gegen snapd.
user535733
1
Ich habe das gleiche Problem nach einer Neuinstallation von Ubuntu 18.04: 3min 57.515s plymouth-quit-wait.service 2min 24.588s snapd.seeded.service
Alessandro Gaballo
1
Ich hatte heute das gleiche Problem, nachdem ich meinen Kernel auf 4.15.0-24-generic aktualisiert hatte.
user605331
1
Erwägen Sie, einen Thread auf forum.snapcraft.io zu starten . Hier hängen die Snap-Entwickler ab. Stellen Sie sicher, dass Sie NUR einen Thread starten, wenn Sie bereit sind, diesen bei der Fehlerbehebung und beim Testen zu helfen. Jeder sollte den gleichen Thread abonnieren und unnötige "Ich auch" -Kommentare vermeiden - halten Sie den Lärm niedrig, damit die Entwickler nicht entmutigt werden und sich abschalten.
User535733
2
Ich habe einen Fehler gemeldet unter : bugs.launchpad.net/snapd/+bug/1779872 Ich bin auf jeden Fall bereit, bei der Fehlerbehebung zu helfen
Broadsworde

Antworten:

15

Dies ist eine kernelbezogene Regression. Der Launchpad-Fehler lautet: https://bugs.launchpad.net/ubuntu/+bug/1779827

Drücken Sie zur Umgehung des Problems die Tasten und / oder bewegen Sie die Maus beim Start.

Kurz gesagt, Dienste, die / dev / urandom oder getrandom () verwenden, blockieren jetzt, bis genügend Entropie verfügbar ist. In der Vergangenheit war für / dev / urandom viel weniger Entropie erforderlich.

Der neueste Status von https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 lautet:

Die Metapakete wurden zurückgesetzt und der Fix wird gerade angewendet und hochgeladen.

Das snapd-Team untersuchte dies ebenfalls und arbeitete mit bson upstream zusammen, um sicherzustellen, dass zum Starten kein / dev / unrandom erforderlich ist ( https://github.com/snapcore/snapd/pull/5464 ).

Daher sollte dieses Problem bald über einen Kernel oder ein snapd-Update behoben werden.

Michael Vogt
quelle
1
Ich habe gerade den "Shift" -Start ausprobiert und das schien die Anmeldezeiten zu widerspiegeln, die ich vor dem Update gesehen hatte ... also was ist hier kaputt? Übrigens, "Shift" beim Booten gab mir kein Grub-Menü, aber es gab mir ein Login viel schneller.
Broadsworde
Michael, könntest du diese Antwort bearbeiten und die Informationen aus deiner anderen Antwort in diese einbauen und dann die andere löschen? Wir mögen eine Frage, eine Antwort hier ... Danke! ;-)
Fabby
Bitte kontaktiere einen Mod, um deine Accounts zusammenzuführen
Zanna
@Broadsworde, Spammen (wiederholtes Drücken) der Shift-Taste oder der Esc-Taste in Ubuntu 18.04 LTS bringt das Grub-Menü für mich auf. (Es ist nicht genug, nur den Schlüssel gedrückt zu halten; ich denke, es kann zwischen Computern unterschiedlich sein.)
sudodus
11

Sie können die Maus bewegen oder die Entropie im System erhöhen.

sudo apt install haveged

haveged website

Funktioniert für Standard-Kernel und von Ukuu. Auf diese Weise kann das System unter Kernel 4.17.4 ordnungsgemäß gestartet werden.

Radoslaw Brzozowski
quelle
Interessante Lösung. Ich habe das Problem noch nicht, weil ich kürzlich zum 4.4.0-130Experimentieren mit Virtualbox gewechselt bin, aber ich habe es installiert, havegedum meinen Computer zukunftssicher zu machen.
WinEunuuchs2Unix
5

Ich habe das gleiche Problem mit 4.15.0-24-generic #26-Ubuntu SMP

user@nb:~$ systemd-analyze blame |head
         4min 2s plymouth-quit-wait.service
          1.440s systemd-udev-settle.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

Für eine vorübergehende Problemumgehung müssen Sie nur Ihre Maus / Ihr Touchpad während des Startvorgangs bewegen , was zu einer "normalen" Startzeit führt. in meinem Fall:

user@nb:~$ systemd-analyze blame |head
          1.440s systemd-udev-settle.service
           882ms plymouth-quit-wait.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

Fix Source: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509

Francio
quelle
5

Ich habe dieses Manifest auf zwei von mir verwalteten Desktops gesehen. Das Ausführen des folgenden Befehls zum Installieren rng-toolslöst das Problem für mich:

sudo apt install rng-tools

Aus dem Arch-Wiki: Das rng-tools ist eine Reihe von Hilfsprogrammen, die sich auf die Erzeugung von Zufallszahlen im Kernel beziehen. Dies ist hauptsächlich nützlich, um die Entropiemenge im Kernel zu erhöhen und / dev / random schneller zu machen.

psiphi75
quelle