Jak zdiagnozować / naprawić bardzo wolne uruchamianie na Ubuntu 18.04

47

Przez długi czas SSD nic nie robi.

  • Jak znaleźć i naprawić usterkę?
  • Już sprawdzone /etc/fstab, nie ma zamiany ani nic złego (32 GB pamięci RAM, bez zamiany)

[    2.173492] usb 2-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.173497] usb 2-1.6: Product: DW375 Bluetooth Module
[    2.173501] usb 2-1.6: Manufacturer: Dell Computer Corp
[    2.173511] usb 2-1.6: SerialNumber: 7CE9D3C0713B
[    2.323728] ata4: SATA link down (SStatus 0 SControl 300)
[    2.441062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input6
[    2.640309] ata5: SATA link down (SStatus 0 SControl 300)
[    2.954947] ata6: SATA link down (SStatus 0 SControl 300)
[    3.068090] clocksource: Switched to clocksource tsc
[   36.584826] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[   36.726117] ip_tables: (C) 2000-2006 Netfilter Core Team
[   36.732610] systemd[1]: systemd 237 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +AC
L +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid)
[   36.751996] systemd[1]: Detected architecture x86-64.
[   36.753867] systemd[1]: Set hostname to <latitude-e5520>.
[   36.868561] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[   36.868594] systemd[1]: Reached target Remote File Systems.
[   36.868751] systemd[1]: Created slice User and Session Slice.
[   36.868869] systemd[1]: Created slice System Slice.
[   36.868948] systemd[1]: Listening on udev Control Socket.
[   36.868957] systemd[1]: Reached target Slices.
[   36.868996] systemd[1]: Listening on udev Kernel Socket.
[   36.895156] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   36.898185] lp: driver loaded but no devices found
[   36.903941] ppdev: user-space parallel port driver
boot 18.04 użytkownik105939
źródło
3
Czy to nowa instalacja? z lvm? może ten błąd: bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1768230 ?
pim
Aby zobaczyć WARNING:Failed to connect to lvmetad. Falling back to device scanning.komunikat, powinieneś wyłączyć spash / quiet boot (patrz: askubuntu.com/a/289/454520 )
pim
Chodzi o długie uruchamianie sieci. Usługa. Rozwiązanie z tej odpowiedzi pomogło mi.
gyr9i

Odpowiedzi:

60

Zaktualizowałem dzisiaj do 18.04 i napotkałem ten sam problem. Udało mi się to naprawić, uruchamiając jądro z noresumeparametrem.

Podobnie jak ty, nie mam też przestrzeni wymiany. W pewnym momencie aktualizacji zmodyfikowano konfigurację initramfs, dodając linię wskazującą na nieistniejącą partycję wymiany. Powolne uruchamianie było spowodowane tym, że szukał tej partycji, a następnie upłynął limit czasu po 30 sekundach.

Aby zaktualizować GRUB, aby automatycznie przekazywał tę opcję do jądra przy starcie:

  1. Zmodyfikuj plik /etc/default/grubpliku, aby ciąg noresumebył zawarty w GRUB_CMDLINE_LINUX_DEFAULTwierszu, na przykład:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash noresume"

  2. Uruchom to polecenie, aby zaktualizować GRUB: 

    sudo update-grub

  3. Zrestartuj komputer

Clifforus
źródło
1
noresume to naprawił, nic dziwnego w initramfs.
user105939
2
Uaktualniłem wczoraj do 18.04 i miałem ten sam problem (uruchomienie trwało 52 sekundy). Po ustawieniu parametru „noresume” zajęło to 21 sekund.
Erol
1
Możesz poprawić swoją i tak dobrą odpowiedź dzięki instrukcjom aktualizacji grub.
WinEunuuchs2Unix
9
Pamiętaj, że jest to obejście, ponieważ uniemożliwi ono wznowienie hibernacji systemu.
pim
2
Martwię się, że może to uniemożliwić mi korzystanie z hibernacji. Jednak to zadziałało dla mnie: askubuntu.com/questions/1013830/... (edycja /etc/initramfs-tools/conf.d/resume, zmiana RESUME = none z UUID i uruchomienie update-initramfs -u)
Gray Panther
19 
$ systemd-analyze blame

Sprawdź, które procesy zajmują najwięcej czasu podczas rozruchu.

Manoj
źródło
5
systemd-analyze blamenie pokaże czasu jądra i dla tego problemu. systemd-analyse timepokaże, że jądro utknęło podczas wyszukiwania systemu plików.
pim
2
dobra wskazówka, ale najdłuższy proces trwał tylko 1,6 sekundy, więc to narzędzie nie pomogło.
user105939
3
@Pim systemd-analyse timema literówkę, powinien miećz
RobAu
1
systemd-analyze critical-chainjest jeszcze lepszy niżblame
user535733
4

Uaktualniłem do 18.04 z 16.04. Czas rozruchu wynosił ponad 10 minut.
Próbowałem z „Brak ekranu powitalnego do jądra”, aby dowiedzieć się, które procesy zajmują najwięcej czasu podczas uruchamiania.

A start job is running for Raise network interfaces (1min 26s / 5min 24s)

Musimy więc skrócić czas, aby ten proces oszczędził czas uruchamiania. Aby to zrobić,

Musisz edytować

sudo nano /etc/systemd/system/network-online.target.wants/networking.service

Odnaleźć 

TimeoutStartSec=5min

Zmień na 

TimeoutStartSec=5s

i uruchom ponownie

krige
źródło
3

Możesz skonfigurować limit czasu dla Rozpocznij zadanie i Zatrzymaj zadania.

Edytuj /etc/systemd/system.confz podwyższonymi uprawnieniami i zmień / dodaj dwa wiersze, które są domyślnie komentowane od 90 sekund do 5 (lub cokolwiek wolisz) i odkomentuj to:

od: 

#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s

do:

DefaultTimeoutStartSec=5s
DefaultTimeoutStopSec=5s

Następnie zastosuj zmiany, przebudowując initramfs za pomocą polecenia:

sudo update-initramfs -u
markackerman8-gmail.com
źródło
0

Próbowałem innej metody, ale nic nie działało. potem okazało się, że był to problem ze sterownikiem karty graficznej. Rozwiązałem, używając dla mnie dodatkowych sterowników, to była Nvidia.

goto: oprogramowanie i aktualizacje -> wybierz sterownik karty graficznej z listy -> zastosuj zmiany

Uwaga: używam jądra w wersji 4.18.0-25-generic

habibun
źródło