Aggiornamento 9
Ho deciso di provare un esperimento. Ho rimosso l'SSD dal desktop e temporaneamente l'ho inserito nel mio laptop Dell Latitude. Ecco, ha caricato initrdun ordine di grandezza più veloce, rasando 6 secondi dal tempo di avvio ...
Sono un po 'confuso ora ... forse GRUB ha un problema con il chipset della mia scheda madre?
Aggiornamento 8
Quindi ho notato qualcosa di interessante sulla luce dell'attività dell'HDD. Durante il caricamento initrd, è quasi come se la luce fosse PWMed con un duty cycle del 10% o qualcosa del genere. Questo mi chiedo se la lettura di GRUB non sia ottimizzata, forse qualcosa come fare una chiamata al sistema operativo per leggere ogni byte anziché leggere l'immagine come flusso di byte?
Aggiornamento 7
Sembra che il caricamento del ramdisk iniziale rappresenti gran parte del problema.
All'interno di GRUB, ho premuto Cper il prompt dei comandi manuale. Ho quindi proceduto a digitare ogni singola riga dalla mia configurazione predefinita in una alla volta (inserire quegli UUID era doloroso!) E ho notato il tempo impiegato dal comando al termine. Ecco cosa ho trovato:
- La maggior parte dei comandi è stata completata istantaneamente
- Il comando per caricare il kernel ha richiesto circa un secondo
- Il comando per caricare il ramdisk iniziale ha impiegato 7 secondi
Dopo aver digitato tutte le righe dal file di configurazione, quindi procedere con l'esecuzione boot. Dal momento in cui ho premuto Invio fino alla comparsa della schermata di accesso, sono stati necessari circa 7,5 secondi.
È interessante notare che l'immagine initrd che sta caricando è di 36 MB. Quindi, se ci sono voluti 7 secondi per caricarlo, allora lo sta leggendo solo a 5 MB / sec!
La spia di attività del disco sulla mia torre rimane accesa per tutti i 7 secondi ...
Ecco anche un frammento interessante della pagina Wikipedia su initrd :
Altre distribuzioni Linux (come Fedora e Ubuntu) generano un'immagine initrd più generica. Questi iniziano solo con il nome del dispositivo del file system radice (o del suo UUID) e devono scoprire tutto il resto all'avvio. In questo caso, il software deve eseguire una complessa cascata di attività per montare il file system radice
Aggiornamento 6
Nathan Osman ha richiesto il tempo di avvio in modalità utente singolo in chat.
Dal momento in cui ho premuto F10GRUB al momento in cui appare il messaggio, ci vogliono 13 secondi.
Inoltre, stavo parlando con Zanna e Rinzwind in chat ed entrambi hanno un avvio di 8 secondi dal momento in cui è stato premuto il pulsante di accensione. I miei 20 secondi provengono da GRUB. Se contassi il tempo POST, sarebbe ancora più lungo!
Aggiornamento 5
Ubuntu può leggere il mio SSD alla sua velocità massima di 550 MB / sec ...
Aggiornamento 4
Quindi ho rimosso i quiet splash $vt_handoffparametri dal comando di avvio in GRUB sul mio laptop (tenere presente che questo laptop non ha un SSD) e ho notato una cosa molto interessante durante la sequenza di avvio:
Si blocca su questa linea per 15 secondi:
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
Ecco un'immagine (di bassa qualità):
Non sono sicuro di quale sia il significato di questo ...
Aggiornamento 3
Ho programmato l'avvio di una delle mie altre macchine con 14.04 (tenere presente che questa macchina non ha un SSD) e dal momento in cui ho premuto invio in GRUB fino a quando appare la schermata di accesso, ci vogliono 40 secondi.
Dopo aver premuto Invio, si trova sulla stessa schermata viola vuota per 20 secondi, dopodiché l'animazione di Ubuntu si carica e ci vogliono altri 20 secondi prima di atterrare nella schermata di accesso.
Ho guardato l'output da dmesg, ma non riesco a capire da dove sia finito l'avvio. Penso che sia finito in 25 secondi. Ecco le ultime righe:
[ 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
Se l'ho interpretato correttamente, sembra essere un problema di GRUB universale.
Aggiornamento 2
Sono stato in grado di confermare che si tratta di un problema di GRUB impostando il colore di sfondo di GRUB su verde utilizzando la riga di comando accessibile premendo Cin GRUB.
Quando premo invio, ottengo una schermata verde vuota per ~ 15 secondi prima che l'animazione di avvio di Ubuntu venga caricata ...
Aggiornare
Penso che il problema sia che GRUB impiega molto tempo a caricare l'immagine del kernel.
Domanda
Ho installato Ubuntu 16.04 sul mio SSD Samsung 850 Pro da 512 GB e non riesco a capire perché il mio tempo di avvio è di 20 secondi. (Dal momento in cui ho premuto invio in GRUB). Tieni presente che il 20 a cui mi riferisco è 17 nella schermata di accesso e quindi altri 3 sul desktop)
Inoltre, non sono sicuro che ciò sia pertinente o meno, ma:
- Ubuntu è installato in modalità MBR, perché disprezzo UEFI.
- Ho installato i driver proprietari Nvidia
Guardando l'immagine generata dasystemd-analyze plot > bootimage2 , la mia startup apparentemente ha impiegato 3 secondi?
E guardando dmesg, la mia startup apparentemente ha impiegato 4 secondi. Ma l'ho cronometrato con il mio cronometro e ci sono voluti 20 secondi! (Escluso il tempo POST) Ancora una volta, tieni presente che il 20 a cui mi riferisco è 17 nella schermata di accesso, quindi altri 3 sul desktop)
Ecco come va la sequenza di avvio:
- INVIARE
- Carichi GRUB
- Inizio il cronometro quando premo INVIO
- Ottengo uno schermo viola vuoto per ~ 15 secondi
- Vedo l'animazione di avvio di Ubuntu per due secondi
- Atterro sulla schermata di accesso
- Fermo il cronometro
- Inserisco la mia password, premo invio e riavvio il cronometro.
- Dopo 3 secondi atterro sul desktop
- Fermo di nuovo il mio cronometro.
Ecco l'output completo da dmesg: http://paste.ubuntu.com/23955108/
Ed ecco le prime righe dall'output di 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
Queste persone hanno lo stesso problema:
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-temporarily-stuck-on-a-purple-screen/
- E sembra che anche le persone con ARCH abbiano questo problema ...
Qualche idea?
systemd-analyze blame. La parte strana è che Grub è stato bloccato sul "caricamento del disco ram iniziale" per circa 10 secondi quando dovrebbe essere una frazione di secondo a causa delle dimensioni del file. Quindi il ritardo è appena andato via. Forse è stato un aggiornamento del kernel? Forse le modifiche che ho apportato plymouthdnon sono sicuro.