Update 9
Ich beschloss, ein Experiment zu versuchen. Ich habe die SSD von meinem Desktop entfernt und sie vorübergehend in meinen Dell Latitude-Laptop eingelegt. Und siehe da, es wurde initrdum eine Größenordnung schneller geladen und die Startzeit um 6 Sekunden verkürzt ...
Ich bin jetzt ein wenig verwirrt ... Vielleicht hat GRUB ein Problem mit dem Chipsatz meines Motherboards?
Update 8
Also fiel mir etwas Interessantes an der HDD-Aktivitätsleuchte auf. Beim Laden initrdist es fast so, als würde das Licht mit einem Tastverhältnis von 10% oder so PWMed betrieben. Ich frage mich daher, ob der Lesevorgang von GRUB nicht optimiert ist. Vielleicht wird so etwas wie ein Betriebssystemaufruf ausgeführt, um jedes Byte zu lesen, anstatt das Bild als Bytestream zu lesen.
Update 7
Es scheint, dass das Laden der ersten Ramdisk ein großer Teil des Problems ist.
In GRUB habe ich Cauf die manuelle Eingabeaufforderung gedrückt . Ich fuhr dann fort, jede einzelne Zeile aus meiner Standardkonfiguration einzeln einzugeben (die Eingabe dieser UUIDs war schmerzhaft!) Und notierte die Zeit, die der Befehl zum Abschluss benötigte. Folgendes habe ich gefunden:
- Die meisten Befehle wurden sofort ausgeführt
- Der Befehl zum Laden des Kernels dauerte ungefähr eine Sekunde
- Der Befehl zum Laden der ersten Ramdisk dauerte 7 Sekunden
Nachdem ich alle Zeilen aus der Konfigurationsdatei eingegeben habe, fahre ich fort boot. Von der Eingabe der Eingabetaste bis zur Anzeige des Anmeldebildschirms dauerte es ungefähr 7,5 Sekunden.
Interessant ist die Tatsache, dass das geladene Initrd-Image 36 MB groß ist. Wenn das Laden also 7 Sekunden gedauert hat , wird es nur mit 5 MB / s gelesen!
Die Festplattenaktivitätsanzeige an meinem Turm bleibt für die gesamten 7 Sekunden an ...
Hier ist auch ein interessanter Ausschnitt aus der Wikipedia-Seite über initrd :
Andere Linux-Distributionen (wie Fedora und Ubuntu) generieren ein allgemeineres initrd-Image. Diese beginnen nur mit dem Gerätenamen des Root-Dateisystems (oder seiner UUID) und müssen beim Start alles andere erkennen. In diesem Fall muss die Software eine komplexe Kaskade von Aufgaben ausführen, um das Root-Dateisystem bereitzustellen
Update 6
Nathan Osman hat die Startzeit im Einzelbenutzermodus im Chat angefordert.
Von dem Zeitpunkt, an dem ich F10in GRUB gedrückt habe, bis zu dem Zeitpunkt, an dem die Eingabeaufforderung angezeigt wird, dauert es 13 Sekunden.
Außerdem habe ich im Chat mit Zanna und Rinzwind gesprochen und beide haben einen Start von 8 Sekunden ab dem Zeitpunkt, an dem der Netzschalter gedrückt wurde. Meine 20 Sekunden sind von GRUB. Wenn ich die POST-Zeit zählen würde, wäre es noch länger!
Update 5
Ubuntu kann meine SSD mit einer maximalen Geschwindigkeit von 550 MB / s lesen ...
Update 4
Daher habe ich die quiet splash $vt_handoffParameter aus dem Startbefehl in GRUB auf meinem Laptop entfernt (denken Sie daran, dass dieser Laptop keine SSD hat) und während der Startsequenz etwas sehr Interessantes bemerkt:
Es hängt 15 Sekunden lang an dieser Leitung:
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
Hier ist ein Bild (von geringer Qualität):
Ich bin mir nicht sicher, welche Bedeutung das hat ...
Update 3
Ich habe den Start eines meiner anderen Computer mit 14.04 zeitlich festgelegt (denken Sie daran, dass dieser Computer keine SSD hat) . Ab dem Zeitpunkt, an dem ich in GRUB die Eingabetaste drücke, bis der Anmeldebildschirm angezeigt wird, dauert es 40 Sekunden.
Nach dem Drücken der Eingabetaste befindet es sich 20 Sekunden lang auf demselben leeren lila Bildschirm. Danach wird die Ubuntu-Animation geladen und es dauert weitere 20 Sekunden, bis sie auf dem Anmeldebildschirm landet.
Ich habe mir die Ausgabe von angesehen dmesg, kann aber nicht genau sagen, wo das Booten beendet wurde. Ich denke, es war nach 25 Sekunden fertig. Hier sind die letzten Zeilen:
[ 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
Wenn ich es richtig interpretiert habe, scheint es ein universelles GRUB-Problem zu sein.
Update 2
Ich konnte bestätigen, dass es sich um ein GRUB-Problem handelt, indem ich die Hintergrundfarbe von GRUB mithilfe der Befehlszeile, auf die ich in GRUB drücke, auf Grün Csetze.
Wenn ich die Eingabetaste drücke, wird ~ 15 Sekunden lang ein leerer grüner Bildschirm angezeigt, bevor die Ubuntu-Boot-Animation geladen wird ...
Aktualisieren
Ich denke, das Problem ist, dass GRUB lange braucht, um das Kernel-Image zu laden.
Frage
Ich habe Ubuntu 16.04 auf meiner Samsung 850 Pro 512 GB SSD installiert und kann nicht verstehen, warum meine Startzeit 20 Sekunden beträgt. (Ab dem Zeitpunkt, an dem ich in GRUB die Eingabetaste drücke). Denken Sie daran, dass die 20, auf die ich mich beziehe, 17 für den Anmeldebildschirm und dann weitere 3 für den Desktop sind.
Auch nicht sicher, ob dies relevant ist oder nicht, aber:
- Ubuntu ist im MBR-Modus installiert, weil ich UEFI verachte.
- Ich habe die proprietären Nvidia-Treiber installiert
Betrachtet man das von erzeugte Bildsystemd-analyze plot > bootimage2 , so hat mein Start anscheinend 3 Sekunden gedauert?
Und beim Anschauen dmesghat mein Start anscheinend 4 Sekunden gedauert. Aber ich habe es mit meiner Stoppuhr eingestellt und es hat 20 Sekunden gedauert! (Ohne POST-Zeit) Denken Sie auch hier daran, dass die 20, auf die ich verweise, 17 für den Anmeldebildschirm und dann weitere 3 für den Desktop sind.)
So läuft die Startsequenz ab:
- POST
- GRUB lädt
- Ich starte meine Stoppuhr, während ich ENTER drücke
- Ich bekomme einen leeren lila Bildschirm für ~ 15 Sekunden
- Ich sehe die Ubuntu-Boot-Animation zwei Sekunden lang
- Ich lande auf dem Anmeldebildschirm
- Ich halte die Stoppuhr an
- Ich gebe mein Passwort ein, drücke die Eingabetaste und starte meine Stoppuhr erneut.
- Nach 3 Sekunden lande ich auf dem Desktop
- Ich halte meine Stoppuhr wieder an.
Hier ist die vollständige Ausgabe von dmesg: http://paste.ubuntu.com/23955108/
Und hier sind die ersten Zeilen aus der Ausgabe von 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
Diese Leute haben das gleiche Problem:
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-temporically-stuck-on-a-purple-screen/
- Und es scheint, dass sogar Leute mit ARCH dieses Problem haben ...
Irgendwelche Ideen?
systemd-analyze blame. Der seltsame Teil ist, dass Grub etwa 10 Sekunden lang auf dem "Laden der anfänglichen RAM-Disk" feststeckte, wenn es aufgrund der Dateigröße einen Sekundenbruchteil dauern sollte. Dann ging die Verzögerung einfach weg. Vielleicht war es ein Kernel-Update? Vielleicht bin plymouthdich mir nicht sicher, ob ich Änderungen vorgenommen habe.