Vraag Lange opstartvertraging op Ubuntu-laad- / opstartscherm na regelmatige dist-upgrade op schone SSD-installatie (18.04)


Ik heb 18.04 gedraaid sinds een schone SSD-installatie op de dag van de officiële release, zonder problemen.
  Inschakelen om in te loggen was seconden (max. 10)

Dan, Ik heb een normale upgrade gedaan deze morgen:

$ sudo apt update && sudo apt dist-upgrade

De geïnstalleerde / opgewaardeerde pakketten 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)

Ik startte opnieuw op nadat de upgrade was voltooid en constateerde een vertraging van 2-3 minuten op de Ubuntu laad- / opstartscherm (voorafgaand aan inloggen) (zonder voortgang / activiteit aangegeven op de stippen).

Ik heb uitgeschakeld en probeerde opnieuw op te starten, maar krijg deze vertraging nu consequent. Ook afsluiten is veel langzamer.

Update # 1 (2018/07/03):
Analyse op 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

Dat te laten zien plymouth-quit-wait.service (waarvan ik nu geloof dat het gerelateerd is aan het Ubuntu loading / splash scherm) en snapd.seeded.service waren veruit de langstlopende services om te starten. Dus vergeleek ik de tijden vóór de dist-upgrade en daarna:

$ 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.

Voor de upgrade plymouth-quit-wait.service nam 3 seconden. Na de upgrade die nodig was 3 minuten 35 seconden

$ 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.

Voor de upgrade snapd.seeded.service nam 0 seconden. Na de upgrade die nodig was 2 minuten 2 seconden.

Update # 2 (2018/07/06):
De boot van vanmorgen zag de terugkeer van de vertraging.
Dus ik denk dat we stil zijn wachten op de kernel / plymouth / snapd-update.

Update # 3 (2018/07/12):
Het probleem lijkt te zijn opgelost, maar ik heb geen update voor snap of plymouth gezien en ik gebruik nog steeds 4.15.0-24 kernel. Dus ik weet niet zeker welke pakketupdate het probleem heeft opgelost of dat het zichzelf op de een of andere manier heeft opgelost. Als ik de bug-updates lees over het startvenster, is het voor mij onduidelijk wat er is gedaan (of wordt gedaan) voor welk pakket / welke pakketten. Als iemand kan verduidelijken, zou dat zeer nuttig zijn.


16
2017-07-03 10:31


oorsprong


Het lijkt erop dat ik snapd was zaaien (de snap-database vernieuwen) voor 2:20. Een zeldzame gebeurtenis, niets gebroken. Als het dat elke keer doet, dien dan een bug in tegen snapd. - user535733
Dank daarvoor. Tot nu toe draait het snapd seeden consequent op meer dan 2 minuten elke boot na de dist-upgrade, nadat het nul seconden ervoor is genomen. - Broadsworde
Ik heb hetzelfde probleem na een nieuwe installatie van Ubuntu 18.04: 3min 57.515s plymouth-quit-wait.service  2min 24.588s snapd.seeded.service - Alessandro Gaballo
Ik had hetzelfde probleem vandaag nadat ik mijn kernel had opgewaardeerd tot 4.15.0-24-generiek. - user605331
Ik heb een fout geregistreerd bij: bugs.launchpad.net/snapd/+bug/1779872 Ik ben zeker bereid om te helpen bij het oplossen van problemen - Broadsworde


antwoorden:


Dit is een kernel-gerelateerde regressie, de launchpad-bug is: https://bugs.launchpad.net/ubuntu/+bug/1779827

Als tijdelijke oplossing kunt u tijdens het opstarten op toetsen drukken en / of de muis verplaatsen.

In een notendop services die gebruik maken van / dev / urandom of getrandom () blokkeren nu totdat voldoende entropie beschikbaar is. In het verleden was er veel minder entropie nodig voor / dev / urandom.

De nieuwste status van https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 is dat:

De metapakketten zijn teruggedraaid en de correctie is aan de gang   worden toegepast en geüpload.

Het snapd-team heeft hier ook naar gekeken en met bson stroomopwaarts gewerkt om er zeker van te zijn dat er geen / dev / unrandom nodig is om te starten (https://github.com/snapcore/snapd/pull/5464)

Dus dit probleem zou snel opgelost moeten worden via een kernel of een snapd-update.


10
2017-07-04 08:01



Ik heb net de "shift" -boot geprobeerd en dat leek de opstarttijd weer te geven om in te loggen tijden die ik eerder dan de update had gezien ... dus wat is hier stuk? BTW, "shift" bij het opstarten gaf me geen menu, maar het gaf me veel sneller een login. - Broadsworde
Michael, wil je? Bewerk  dit antwoord en neemt u de informatie van uw andere antwoord op in deze en verwijdert u vervolgens de andere? We houden van één vraag, één antwoord hier ... Dank je! ;-) - Fabby
neem contact op met een mod om uw accounts samen te voegen - Zanna
@Broadsworde, Spamming (herhaaldelijk raken) van de Shift-toets of de Esc-toets in Ubuntu 18.04 LTS roept het grub-menu voor mij op. (Het volstaat niet om de sleutel gewoon ingedrukt te houden, ik vermoed dat het kan verschillen tussen computers.) - sudodus


U kunt de muis verplaatsen of de entropie in het systeem verhogen.

sudo apt install haveged

haveged website

Werkt voor de standaardkernel en uit ukuu. Hierdoor kan het systeem correct opstarten op kernel 4.17.4.


4
2017-07-04 21:08



Interessante oplossing. Ik heb het probleem nog niet, omdat ik onlangs ben overgeschakeld naar 4.4.0-130 voor het experimenteren met Virtualbox, maar ik heb geïnstalleerd haveged om mijn machine toekomstbestendig te maken. - WinEunuuchs2Unix


ik heb hetzelfde probleem met 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

Voor een tijdelijke oplossing, je moet het gewoon doen beweeg uw muis / touchpad tijdens het booten, wat resulteert in een "normale" opstarttijd; in mijn geval:

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

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


3
2017-07-03 18:22





Ik heb dit manifest gezien op twee desktops die ik beheer. Voer de volgende opdracht uit om te installeren rng-tools lost het probleem voor mij op:

sudo apt install rng-tools

Van Arch wiki: De rng-tools is een verzameling hulpprogramma's die verband houden met het genereren van willekeurige getallen in de kernel. Dit is vooral handig om de hoeveelheid entropie in de kernel te vergroten om / dev / random sneller te maken.


0
2017-07-16 20:26