Auf der NAS nutze ich Ubuntu Server 16.04 LTS, ausgestattet mit 8 GB Ram
und einer 256 GB PCIe SSD, die eine ebenfalls 8 GB große SWAP-Partition
besitzt.
Nach Hinzufügen des Eintrags GRUB_CMDLINE_LINUX_DEFAULT="quiet splash
resume=/dev/nvme0n1p3" in die Konfigurationsdatei von grub kann ich den
Rechner mit 'systemctl hibernate' in den Ruhezustand versetzen. Das
'Wiedererwecken' funktioniert problemlos, der Rechner läuft an der
Stelle weiter an der ich ihn beendete.
Allerdings dauert das 'Wiederanfahren' mit 35 s recht lange, ich hätte
erwartet, daß der Rechner innerhalb weniger Sekunden zur Verfügung
steht?
Außerdem wird der gesamte normale Startvorgang durchlaufen: Logo des
Motherboard-Herstellers, Aufruf des grub-Startmenüs usw. Ist das normal?
(da es die Server-Version ist, ist keine GUI installiert und ein
"richtiges" Ein-/Ausschalten dauert der Startvorgang 40 s, nur
unwesentlich länger als die Hibernate-Funktion).
Markus schrieb:> Außerdem wird der gesamte normale Startvorgang durchlaufen: Logo des> Motherboard-Herstellers, Aufruf des grub-Startmenüs usw. Ist das normal?
Das ist normal. Der Rechner startet wie üblich in den Kernel und erst
dann findet die Wiederherstellung statt.
Heutige Linuxe starten von SSD meist derart schnell, dass Hibernation
nur lohnt, wenn man laufende Aktivitäten einfrieren statt abschiessen
will.
Markus schrieb:> Außerdem wird der gesamte normale Startvorgang durchlaufen: Logo des> Motherboard-Herstellers, Aufruf des grub-Startmenüs usw. Ist das normal?
Ja, klar. Aus Sicht des BIOS ist der Rechner ja ganz normal
runtergefahren. Der macht beim Einschalten das, was er da immer tut.
Erst der Linux-Kernel weiß dann, dass er ein Resume machen muss.
Wenn es schnell gehen soll, nimm Suspend-to-RAM. Dann wird der Rechner
zwar nicht vollständig ausgeschaltet, aber er ist sehr schnell wieder da
(bei meinem Laptop in 1s).
> (da es die Server-Version ist, ist keine GUI installiert und ein> "richtiges" Ein-/Ausschalten dauert der Startvorgang 40 s, nur> unwesentlich länger als die Hibernate-Funktion).
40 Sekunden finde ich bei einem modernen Rechner mit SSD schon eher
viel. Mein PC ist auch mit GUI schneller gebootet.
Markus schrieb:> ist keine GUI installiert und ein> "richtiges" Ein-/Ausschalten dauert der Startvorgang 40 s, nur> unwesentlich länger als die Hibernate-Funktion).
da stimmt doch etwas nicht. Linux ohne gui sollte in weniger als 10s
bereit sein.
Wo braucht er denn so lange?
systemd-analyze
Startup finished in 1.963s (kernel) + 5.063s (userspace) = 7.026s
Peter II schrieb:> Wo braucht er denn so lange?
Wahrscheinlich im BIOS und dessen Hardware-Init. Obige VM hat praktisch
keine Verzögerung durch das BIOS. In den 14s sind ausserdem noch 3s
grub-Timeout drin.
Aus irgendeinem Grund verweilt der Rechner schon 10 s bei der
Darstellung des Bios-Logos bevor überhaupt das eigentliche Booten
beginnt.
3s Timeout beim grub-Menü habe ich hier auch eingestellt.
systemd-analyze kannte ich nicht, probiere ich heute abend aus. Immerhin
werden bislang keine Fehler während des Startvorgangs ausgegeben (bei
Herausnehmen der Optionen 'quiet splash').
Wie verteilen sich denn die 35s auf BIOS, Grub, Kernel-Startup und den
Rest?
Bei meine Arbeitslaptop (mit SSD, BIOS und Grub) muss ich bis zu 30s
warten, bis überhaupt der Grub gestartet wird (keine Ahnung, was das
BIOS so lange macht). Der eigentliche Bootvorgang danach bis zum
grafischen Login-Bildschirm dauert etwa 15s. Da bringt auch eine
Umstellung auf Hibernate prozentual nicht viel.
Mein privater Laptop hingegen braucht vom Einschalten bis zum
grafischen Login-Bildschirm 11s (mit SSD, UEFI und ohne Grub). Das ist
so kurz, dass ich mir ebenfalls keine Gedanken über Hibernate mache.
(selbst wenn ich während des Bios-Logos wie bekloppt die ENTF-Taste zum
Aufruf des BIOS drücke, dauert es die 10 s bis ich ins BIOS reinkomme.
Äußerst nervig...)
Markus schrieb:> Aus irgendeinem Grund verweilt der Rechner schon 10 s bei der> Darstellung des Bios-Logos bevor überhaupt das eigentliche Booten> beginnt.
Im BIOS kann man oft einstellen, ob es die Startmeldungen anzeigen soll.
Ist per Voreinstellung heute aus ästhetischen Gründen oft ausgeschaltet.
Im Linux leider oft auch, auch in Server-Distro.
Peter II schrieb:> da stimmt doch etwas nicht. Linux ohne gui sollte in weniger als 10s> bereit sein.>> Wo braucht er denn so lange?>> systemd-analyze> Startup finished in 1.963s (kernel) + 5.063s (userspace) = 7.026s
Das zählt aber erst ab der Stelle, wo der Kernel dran kommt. Davor muss
erstmal das BIOS Dinge tun, wie z.B.:
Markus schrieb:> Logo des Motherboard-Herstellers
und dann gibt's noch den grub-Timeout.
im Bios gibt es oft Optionen zum schnellen bootet. Ram-Test, USB-Legacy
Support, Boot on Lan usw. Wenn man das alle passende konfiguriert darf
das Bios noch ein paar Sekunden brauchen.
Server-Boards brauchen aber oft länger, als consumer Board.
Rolf M. schrieb:> Das zählt aber erst ab der Stelle, wo der Kernel dran kommt. Davor muss> erstmal das BIOS Dinge tun, wie z.B.:
ja und nein. Bei UEFI kann man System auch die Zeiten vom UEFI erfragen
(konnte ich selber aber noch nie sehen)
https://wiki.archlinux.org/index.php/Improving_performance/Boot_process> Tip: If you boot via UEFI and use a boot loader which implements> systemd's Boot Loader Interface (which currently systemd-boot and> GRUB do), systemd-analyze can additionally show you how much time> was spent in the EFI firmware and the boot loader itself.
- die apt-daily.service wird nicht bei jedem Start ausgeführt, da der
Rechner heute morgen aus ausgeschaltetem und heute nachmittag aus dem
Hibernate-Zustand hochfuhr, scheint dieser Service jedoch mehr als nur
einmal täglich gestartet zu werden (?)
- die Zeit, die auf die firmware (hier: 20.861s) entfällt kann auch mal
bei ca. 8s liegen. Zunächst nahm ich an, daß das mit der Art des
Ausschaltens zusammenhängt (Hibernate, poweroff, reboot usw.), aber
einen wirklichen Zusammenhang kann ich nicht erkennen.
- im Bios ist eingestellt, daß der Rechner nur von der SSD booten soll,
sofern kein externes USB-Gerät aufzufinden ist (was normalerweise nicht
der Fall ist).
- die 4.071s des 'loaders' beinhalten vermutlich die 3s Warten im
grub-Menü ?
Markus schrieb:> ntp habe ich entfernt und durch timesyncd ersetzt, eine wesentliche> Verbesserung trat aber nicht ein:
ob ntp noch startet oder nicht spielt doch keine Rolle, man kann doch
trotzdem mit dem System arbeiten.
Die meiste Zeit geht im Bios (UEFI) drauf, dort musst du schauen wo es
klemmt.
Peter II schrieb:> Die meiste Zeit geht im Bios (UEFI) drauf, dort musst du schauen wo es> klemmt.
- 'Memory detection and training' während des Bootvorgangs ist auf
'enable fast-boot' gesetzt
- allgemeine 'Fast Boot'-Option ist aktiviert
- alle Intel-Dinge bis auf 'Virtualization Technology for Directed I/O'
sind deaktiviert (Intel Platform Trust Technology, Bios Guard
Technology) ebenso 'Secure Boot' und das 'Platform Power Management'
- neueste Bios-Firmware (08/2017) ist aufgespielt
Viel mehr fällt mir gar nicht ein... Übrigens handelt es sich um ein
Motherboard von Gigabyte, GA-B250M-DS3H.
Markus schrieb:> Viel mehr fällt mir gar nicht ein... Übrigens handelt es sich um ein> Motherboard von Gigabyte, GA-B250M-DS3H.
ich habe auch haufenweise Gigabyte Board verbaut, keines braucht so
lange zu bootet. (max. 10 Sekunden bis Windows oben ist)
Steckt noch andere Hardware drin?
Schalte mal das Logo ab und schau wo er so lange hängt.
Peter II schrieb:> Schalte mal das Logo ab
Bei abgeschaltetem Logo startet er mit einem 'Minimal-Logo' und siehe
da, es handelt sich um AMI-Bios. Wußte gar nicht, daß es die noch gibt
;-)
systemd-analyze schmeißt nach wie vor ca. 20s für den firmware-Teil und
38s insgesamt heraus.
> und schau wo er so lange hängt.
Wie kann ich das herausfinden? Dieses American Megatrends-Minimal-Logo
wird angezeigt, ansonsten nichts bis zum grub-menu, anschließend die
normalen Linux-Meldungen.
- Die Festplatten sind im Bios deaktiviert, so daß nur noch die SSD
detektiert und von ihr gestartet wird.
- PS/2 Anschlüsse sind ebenfalls deaktiviert
- Speichertest wie oben beschrieben auch aus
- nur noch USB ist voll aktiviert, allerdings sind keine Geräte
angeschlossen
Hilft jedoch alles nichts:
Startup finished in 19.746s (firmware) + 3.989s (loader) + 2.681s
(kernel) + 14.316s (userspace) = 40.732s
Anstelle 'hibernate' habe ich im per cron-job regelmäßig abzuarbeitenden
autosuspend-script 'suspend' eingestellt, das funktioniert und der
Rechner ist innerhalb von 1-2 Sekunden zurück. Wie die meisten Anwender
benötige ich 'Richtig starten' im Alltag eher selten, aber bei solchen
Sachen schwingt bei mir immer ein "irgendetwas ist nicht richtig
konfiguriert oder kaputt, hoffentlich zerschießt es den Rechner nicht
früher oder später" mit.
Scheint normal zu sein. Bei mir (Mint 17.3, Yoga 2 Pro) dauert das
Aufwecken aus dem Hibernate Größenordnungen (>30s, weiß es nicht mehr)
länger als ein einfacher Reboot.
Reboot: Bios 9s, 4s bis zum Login, dann nochmal 3s bis zur GUI (Gnome).
Ich habe daher den ganzen Hibernate Kram deaktiviert. Taugt nichts.
Gruß
Andreas
Markus schrieb:> Hilft jedoch alles nichts:
mache mal ein Bios-Update und Reset auf Default. Es ist nicht normal das
er 20 Sekunden im Bios verbringt.
Ziehe auch mal die SSD ab, nicht das er mit der ein Problem hat. Dann
sollte recht schnell zumindest der Fehler kommen das er nicht booten
kann.
Peter II schrieb:> mache mal ein Bios-Update und Reset auf Default. Es ist nicht normal das> er 20 Sekunden im Bios verbringt.
Hängt vom Gerät ab. Beim Laptop wärs viel, beim Server wenig.
A. K. schrieb:> Hängt vom Gerät ab.
Ein GA-B250M-DS3H ist weder ein Laptop noch ein Server board.
so ein aktuelles Board hatte ich noch nicht von Gigabyte aber bis zur
4.Core-Gerneration (100 Serie) gabs nirgend so lange boot Zeiten.
Peter II schrieb:> Ein GA-B250M-DS3H ist weder ein Laptop noch ein Server board.
Nein, der Computer ist kein Server im eigentlichen Sinne, ich nutze ihn
als NAS (ist ja teuer genug...). Es handelt sich um folgenden Aufbau:
http://www.technikaffe.de/anleitung-399-nas_advanced_3.0_mit_kaby_lake_4_thread_pentium_6x_sata_und_m.2
(entgegen dem Bauvorschlag nutze ich eine PCIe SSD, ansonsten sind die
Komponenten 1:1 wie in dem Artikel).
Heute abend geht es weiter ....
Kann ein fehlerhafter Eintrag im efibootmgr oder in grub für die
Verzögerung verantwortlich sein? Wobei ich im NVRAM noch nie manuelle
Änderungen durchgeführt habe.
Markus schrieb:> - im Bios ist eingestellt, daß der Rechner nur von der SSD booten soll,> sofern kein externes USB-Gerät aufzufinden ist (was normalerweise nicht> der Fall ist).
Dass bedeutet das BIOS muss seinen USB-Stack komplett hochfahren, und
auf jedem USB-Port nach einem bootbaren Medium suchen.
Schalte das Booten von USB mal ab.
Markus schrieb:> Kann ein fehlerhafter Eintrag im efibootmgr oder in grub für die> Verzögerung verantwortlich sein?
durchaus möglich, deswegen mal die SSD abklemmen und schau ob er dann
auch lange braucht.
UEFI-Geraffel komplett rauswerfen: Alles auf Legacy, manchmal
verklausuliert als OS- Auswahl zu finden (Auswahl Win7 oder 8-10 z.B.).
Und auch, wenn das Board keinen FDD-Anschluss hat: Kontrollieren, ob
nicht irgendwo ein FDD als Bootdevice eingetragen ist - alles schon
gesehen.
Jupp schrieb:> UEFI-Geraffel komplett rauswerfen: Alles auf Legacy,
nur kann man dann nicht mehr von NVE bootet, wenn er eine PCI-SSD hat
wird er hoffentlich NVE habe. Auch das bootet von GPT geht nicht immer.
UEFI ist nicht langsamer als Legacy, also dummer Vorschlag.
UEFI ist mittlerweile ausreichend ausgereift, man muss nicht mehr an
alten Dingen festhalten.
Peter II schrieb:> UEFI ist mittlerweile ausreichend ausgereift, man muss nicht mehr an> alten Dingen festhalten.
ROFL...Das ist blanke Theorie, die praktische Umsetzung sieht ganz
anders aus.
> UEFI ist nicht langsamer als Legacy
Nur, wenn es richtig gemacht ist, s.o.
> also dummer Vorschlag.
Und das von dir? LOL.
Jupp schrieb:> UEFI-Geraffel komplett rauswerfen:
Nachtrag:
Wenn man es genau nimmt, geht das überhaupt nicht. Denn bei Legacy wird
nur eine Legacy-Modul im UEFI geladen. Damit braucht man sogar noch mehr
zeit.
- USB im Bios komplett deaktiviert: keine Änderung
- überflüssige Booteinträge von ehemaliger Debian-Distro im UEFI mit
'efibootmgr' entfert: keine Änderung
- in grub in der Datei /etc/default/grub den Eintrag
GRUB_DISABLE_OS_PROBER=true hinzugefügt: keine Änderung
- bei abgeklemmten Festplatten und abgeklemmter SSD erfolgt der Aufruf
des Bios ungefähr 7 Sekunden nach Einschalten (ganz grob mit dem
Smartphone gemessen, können auch 6 oder 8s sein. Das würde ich als
normal ansehen.)
Soll wohl so sein. Trotzdem vielen Dank für die Ratschläge!
Markus schrieb:> Soll wohl so sein. Trotzdem vielen Dank für die Ratschläge!
ich würde mal eine Mail an Gigabyte schreiben, hatte auch schon mal ein
Problem und habe Zeitnah eine sinnvolle Antwort bekommen.
To whom it may concern:
Der Gigabyte-Support hat den Brückentag für eine Antwort auf meine
Anfrage genutzt:
"Linux und Co werden von uns nicht geprüft und auch nicht Supportet.
Klemmen Sie alle Laufwerke ab und schauen wie lange das System mit Bios
Einstellungen Default benötigt um zu melden das keine Laufwerle gefunden
wurden.
Danach den Controller auf Raid setzen (Ohne Laufwerke) und erneut
testen.
Dann mit OS Platte, dann mit angeschlossenen Raid Platten./"
Meiner Meinung nach ist die Antwort nur bedingt hilfreich, weil ich mir
nicht vorstellen kann, daß das lange Verweilen etwas mit dem
installierten Betriebssystem zu tun hat.
Markus schrieb:> Meiner Meinung nach ist die Antwort nur bedingt hilfreich, weil ich mir> nicht vorstellen kann, daß das lange Verweilen etwas mit dem> installierten Betriebssystem zu tun hat.
Das BIOS muss zumindest ein paar Sektoren jeder Platte/SSD lesen, damit
eventuelles RAID korrekt erkannt werden kann und ob überhaupt was
bootbares drauf ist. Daher verkürzt sich die Startzeit etwas bei weniger
angeklemmten Platten. Ähnliches dürfte übrigens für USB gelten.
Gut ausgebaute Server Mainboards können zum Booten mehrere Minuten
brauchen...
