Jądro Xubuntu 18.04 trwa długo

Po aktualizacji z wersji 17.10 mam dłuższe czasy uruchamiania. Początkowo zajęło to ponad 5 minut. dmesgujawnił, że winowajcą była nieistniejąca stacja dyskietek, którą jądro próbowało znaleźć.

Po szybkim usunięciu 5 minut skróciło się do około 40 sekund, co wydaje mi się, że jest to więcej niż zajęło przed aktualizacją. Uruchomiony dmesgponownie pokazuje, że trwa 30 sekund na zamontowanie systemu plików ( pełna moc ), z następującym komunikatem:

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

Uruchamiam z dysku SSD, z podłączonymi dwoma innymi dyskami twardymi, z których jeden jest sformatowany w ext4, ale nie zawiera danych systemowych. Przypuszczam, że to jest dysk SSD. W ciągu tych 30 sekund żaden tekst nie jest wyświetlany, ani rozbryzgiwanie, tylko pusty ekran.

Teraz powiedziałem, że wydaje się być wolniejszy niż przed aktualizacją, ponieważ nie mam dokładnych czasów z poprzedniej, więc moje pierwsze pytanie brzmi: czy normalne jest 30 sekund na zamontowanie systemu plików, a jeśli nie, jak dowiedzieć się więcej o tym, co może powodować opóźnienie?

EDYCJA 1:

Włączanie lub wyłączanie wymiany nie ma żadnego wpływu na serwer

W międzyczasie zainstalowałem także inny dysk twardy na moim komputerze. Wydaje się, że jeszcze bardziej wydłużył mój czas rozruchu o około 10 sekund, z kolejną linią pojawiającą się na dmesgwyjściu, tuż przed wspomnianym 30-sekundowym opóźnieniem:

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

EDYCJA 2:

systemd-analyze blamewyniki są tutaj

tymczasem po kilku ponownych uruchomieniach dmesglinie, które obwiniłem powyżej, zmieniły w ten sposób swoje czasy:

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

Zrobię kilka restartów, aby dowiedzieć się, czy to zmienia się losowo, czy pozostaje takie samo (blok kodu w pierwszej edycji pochodzi z pierwszego uruchomienia po włożeniu dodatkowego dysku twardego).

EDYCJA 2.5: random: crng init donezwykle pojawia się w czasach pokazanych w edycji 1, rzadko jak w edycji 2. Wydaje się, że jest ... losowa.

Miałem ten sam problem. Podczas komunikatów rozruchowych powiedziałby, że upłynął limit czasu oczekiwania na wznowienie urządzenia. Sprawdź, /etc/initramfs-tools/conf.d/resumeczy jest w nim identyfikator UUID, np. RESUME=some-uuidUsuń identyfikator UUID i zastąp go „none” RESUME=none. Po tym biegu sudo update-initramfs -uk allpowinno być dobrze.

Miałem ten problem wiele razy, a moje rozwiązanie działa we wszystkich sytuacjach.

Podczas uruchamiania dsmeg błąd pojawia się jako:

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

Rozwiązaniem jest:

Najpierw porównaj swoje fstab i 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$

Jak widać, moja zamiana w / dev / sda7 ma inny identyfikator UUID w fstab niż w blkid. Było to w moim przypadku spowodowane inną instalacją Linuksa zmieniającą partycję wymiany i powodującą zmianę UUID. Opóźnienie rozruchu spowodowane jest przez system próbujący znaleźć nowy identyfikator UUID wymiany. Aby to naprawić, po prostu skopiuj UUID do blkid, który nie pasuje do pliku fstab, a następnie zapisz.

Jeśli po ponownym uruchomieniu nadal występuje błąd rozruchu, musisz dodatkowo edytować plik initramfs.conf.

Zrób to przez:

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

Następnie, tworząc nowy plik lub edytując bieżący plik CV, napisz w pierwszym wierszu RESUME = UUID = << UUID zamiany >>

Na przykład mój wygląda

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

Następnie uruchom poniższe polecenie, aby zaktualizować plik initramfs.

#sudo update-initramfs -u

Następnie uruchom ponownie. Błąd zniknie.

Doświadczyłem podobnego wydłużenia czasu rozruchu, a po zbadaniu sprawy dmesgi systemd-analyze blamesprawcy wydawało się, że takrandom: crng init

Problemem wydaje się niewystarczająca entropia podczas uruchamiania z dysku SSD do inicjalizacji. Ta hipoteza wydaje się potwierdzona, ponieważ poruszanie myszą kilka razy podczas rozruchu skraca czas rozruchu z około 2 minut w dół, aby zbliżyć się do tego, co było wcześniej.

Podczas rozruchu jądro czeka na ruchy myszy, aby zainicjować generator liczb losowych. Komunikaty jądra przy rozruchu:
sudo dmesg | less

Problem:
kernel: random: crng init done

Rozwiązanie:
sudo apt install haveged
sudo systemctl enable haveged

Miałem ten problem z wolnym czasem uruchamiania na Ubuntu 19.04 po usunięciu partycji wymiany i utworzeniu pliku wymiany.

Dane wyjściowe 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'

Brak pliku wymiany w / etc / fstab. Wszystkie zamontowane dyski / Uuids były prawidłowe.

Sprawdziłem, /etc/initramfs-tools/conf.d/resumeale brakuje tego pliku.

Po prostu biegnę

sudo update-initramfs -uk all

A teraz bardzo szybko się uruchamia.