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.
:
Bearbeitet durch User
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.
1 | # systemd-analyze |
2 | Startup finished in 485ms (kernel) + 1.052s (initrd) + 2.521s (userspace) = 4.059s |
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Hallo, systemd-analyze lieferte folgende Angaben:
1 | Startup finished in 20.861s (firmware) + 3.982s (loader) + 3.213s (kernel) + 13.550s (userspace) = 41.608s |
Die Ausgabe von systemd-analyze blame lautete:
1 | 8.512s ntp.service |
2 | 7.199s apt-daily.service |
3 | 3.319s networking.service |
4 | 2.342s webmin.service |
5 | 778ms apt-daily-upgrade.service |
6 | 549ms postfix.service |
7 | 515ms lvm2-monitor.service |
8 | 440ms dev-nvme0n1p2.device |
9 | 357ms nmbd.service |
ntp habe ich entfernt und durch timesyncd ersetzt, eine wesentliche Verbesserung trat aber nicht ein:
1 | Startup finished in 20.873s (firmware) + 4.071s (loader) + 2.741s (kernel) + 7.467s (userspace) = 35.153s |
- 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.
Was ist außer der SSD noch am Board abgeschlossen? Ziehe mal alle USB Geräte ab und schau ob es dann schneller geht.
- 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.
:
Bearbeitet durch User
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...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.