Aktualizacja 9

Postanowiłem spróbować eksperymentu. Usunąłem dysk SSD z pulpitu i tymczasowo włożyłem go do laptopa Dell Latitude. I oto, ładował ładunek initrdo rząd wielkości szybciej, goląc 6 sekund czasu rozruchu ...

Jestem teraz trochę zdezorientowany ... może GRUB ma problem z chipsetem mojej płyty głównej?

Aktualizacja 8

Zauważyłem więc coś interesującego w świetle aktywności HDD. Podczas ładowania initrdjest prawie tak, jakby światło było PWMed przy 10% cyklu pracy lub coś w tym rodzaju. To sprawia, że zastanawiam się, czy odczyt GRUBA nie jest zoptymalizowany, może coś takiego jak wywołanie systemu operacyjnego w celu odczytania każdego bajtu zamiast odczytu obrazu jako strumienia bajtów?

Aktualizacja 7

Wygląda na to, że ładowanie początkowego ramdysku stanowi dużą część problemu.

W GRUB-ie nacisnąłem Cręczny wiersz poleceń. Następnie zacząłem wpisywać każdą linię z mojej domyślnej konfiguracji pojedynczo (wprowadzanie tych UUID-ów było bolesne!) , I zanotowałem czas wykonania polecenia. Oto, co znalazłem:

Większość poleceń została wykonana natychmiast
Polecenie załadowania jądra zajęło około jednej sekundy
Polecenie załadowania początkowego ramdysku trwało 7 sekund

Po wpisaniu wszystkich wierszy z pliku konfiguracyjnego przystępuję do uruchomienia boot. Od momentu naciśnięcia klawisza Enter do momentu pojawienia się ekranu logowania zajęło to około 7,5 sekundy.

Interesujący jest fakt, że ładowany obraz initrd ma 36 MB. Więc jeśli ładowanie trwało 7 sekund, to odczytuje to tylko z prędkością 5 MB / s!

Lampka aktywności dysku w mojej wieży świeci przez całe 7 sekund ...

Oto także interesujący fragment strony Wikipedii na temat initrd :

Inne dystrybucje Linuksa (takie jak Fedora i Ubuntu) generują bardziej ogólny obraz initrd. Te rozpoczynają się tylko od nazwy urządzenia głównego systemu plików (lub jego identyfikatora UUID) i muszą wykryć wszystko inne podczas uruchamiania. W takim przypadku oprogramowanie musi wykonać złożoną kaskadę zadań, aby zainstalować system plików root

Aktualizacja 6

Nathan Osman poprosił o czas uruchamiania w trybie pojedynczego użytkownika na czacie.

Od momentu, kiedy F10włączyłem GRUB, do momentu pojawienia się monitu, zajmuje to 13 sekund.

Rozmawiałem też z Zanną i Rinzwindem na czacie. Obaj mają 8 sekundowy start od momentu wciśnięcia przycisku zasilania. Moje 20 sekund pochodzi z GRUBA. Gdybym liczył czas POST, byłby jeszcze dłuższy!

Aktualizacja 5

Ubuntu może odczytać mój dysk SSD z maksymalną prędkością 550 MB / s ...

Aktualizacja 4

Usunąłem więc quiet splash $vt_handoffparametry z polecenia rozruchu w GRUB-ie na moim laptopie (pamiętaj, że ten laptop nie ma dysku SSD) i zauważyłem bardzo interesującą rzecz podczas sekwencji rozruchowej:

Wisi na tej linii przez 15 sekund:

[    4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped

Oto zdjęcie (niskiej jakości):

Nie jestem pewien, jakie to ma znaczenie ...

Aktualizacja 3

Zmierzyłem czas rozruchu jednej z moich innych maszyn z 14.04 (pamiętaj, że ta maszyna nie ma dysku SSD) i od momentu naciśnięcia klawisza Enter w GRUB aż do wyświetlenia ekranu logowania, zajmuje to 40 sekund.

Po wciśnięciu klawisza enter, siedzi na tym samym pustym fioletowym ekranie przez 20 sekund, po czym ładuje się animacja Ubuntu i zajmuje kolejne 20 sekund przed lądowaniem na ekranie logowania.

Spojrzałem na dane wyjściowe dmesg, ale nie do końca wiem, gdzie zakończyło się ładowanie. Myślę, że zakończyło się po 25 sekundach. Oto kilka ostatnich wierszy:

[   24.916824] wlan0: associated
[   24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   25.215550] init: kdm main process (869) killed by TERM signal
[   25.441216] vboxdrv: module verification failed: signature and/or  required key missing - tainting kernel
[   25.445587] vboxdrv: Found 2 processor cores.
[   25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[   25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[   25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[   25.476940] vboxpci: IOMMU not found (not registered)
[   33.174926] init: plymouth-upstart-bridge main process ended, respawning
[   36.495811] init: anacron main process (933) killed by TERM signal

Jeśli poprawnie go zinterpretowałem, wydaje się, że jest to uniwersalny problem GRUB.

Aktualizacja 2

Potrafiłem potwierdzić, że jest to problem z GRUB-em , ustawiając kolor tła GRUB-a na zielony, używając linii poleceń dostępnej po naciśnięciu Cw GRUB-ie.

Kiedy wcisnę Enter, dostaję pusty zielony ekran przez ~ 15 sekund, zanim załaduje się animacja rozruchowa Ubuntu ...

Aktualizacja

Myślę, że problem polega na tym, że GRUB długo ładuje obraz jądra.

Pytanie

Zainstalowałem Ubuntu 16.04 na moim dysku twardym Samsung 850 Pro 512GB i nie mogę zrozumieć, dlaczego mój czas rozruchu wynosi 20 sekund. (Od kiedy uderzyłem enter w GRUB). Pamiętaj, że 20, do którego się odnoszę, to 17 na ekranie logowania, a następnie kolejne 3 na pulpicie)

Nie jestem również pewien, czy jest to istotne, czy nie, ale:

Ubuntu jest zainstalowany w trybie MBR, ponieważ gardzę UEFI.
Mam zainstalowane zastrzeżone sterowniki Nvidia

Patrząc na wygenerowany obrazsystemd-analyze plot > bootimage2 , mój start najwyraźniej trwał 3 sekundy?

I patrząc na dmesg, mój start najwyraźniej zajął 4 sekundy. Ale odmierzyłem czas stoperem i zajęło to 20 sekund! (Nie wliczając czasu POST) Ponownie, pamiętaj, że 20, do którego się odnoszę, to 17 na ekranie logowania, a następnie kolejne 3 na pulpicie)

Oto jak przebiega sekwencja uruchamiania:

POCZTA
GRUB ładuje
Uruchamiam stoper, gdy nacisnę ENTER
Dostaję pusty fioletowy ekran przez ~ 15 sekund
Przez dwie sekundy widzę animację rozruchową Ubuntu
Wylądowałem na ekranie logowania
Zatrzymuję stoper
Wpisuję hasło, wciskam Enter i ponownie uruchamiam stoper.
Po 3 sekundach ląduję na pulpicie
Znowu zatrzymuję stoper.

Oto pełne dane wyjściowe z dmesg: http://paste.ubuntu.com/23955108/

A oto pierwsze wiersze z danych wyjściowych systemd-analyze blame:

   365ms dev-sda5.device
   327ms networking.service
   287ms accounts-daemon.service
   286ms ModemManager.service
   233ms systemd-logind.service
   216ms apport.service
   213ms grub-common.service
   209ms ondemand.service
   200ms irqbalance.service
   183ms speech-dispatcher.service
   178ms apparmor.service
   160ms gpu-manager.service
   148ms thermald.service
   148ms pppd-dns.service
   146ms systemd-user-sessions.service
   142ms alsa-restore.service
   140ms console-setup.service
   137ms rsyslog.service
   105ms NetworkManager.service
   104ms upower.service
   102ms avahi-daemon.service
   100ms systemd-udev-trigger.service

Ci ludzie mają ten sam problem:

Jakieś pomysły?

boot 16.04 grub2 ssd bootloader You'reAGitForNotUsingGit
źródło

Komentarze nie są przeznaczone do rozszerzonej dyskusji; ta rozmowa została przeniesiona do czatu .

Thomas Ward

Zadałem również pytanie o powolnym rozruchu, ale zniknęło z 29 sekund do 15 sekund, co jest teraz akceptowalne dla wolnego dysku SSD Kingfast mSata III w autobusie Sata II: askubuntu.com/questions/864277/…

WinEunuuchs2Unix

@ WinEunuuchs2Unix - W jaki sposób udało ci się przekonać GRUBa, by powiedział, kiedy skończył się ładowanie initramfs?

You'reAGitForNotUsingGit

@AndroidDev Nie zrobiłem nic specjalnego poza konfiguracją schematu rozruchowego i używaniem systemd-analyze blame. Dziwne jest to, że Grub utknął na „ładowaniu początkowego dysku RAM” przez około 10 sekund, kiedy powinno to być ułamek sekundy ze względu na rozmiar pliku. Potem opóźnienie właśnie zniknęło. Być może była to aktualizacja jądra? Może zmiany, które wprowadziłem, plymouthdnie jestem pewien.