Wartezeit auf '0'
Und was ist, wenn es mal einen "kaputten" Kernel gibt, der nicht startet?
Dann musst du per Live-System und chroot das wieder zurecht biegen.
Besser ist es, z.B. 2 Sekunden zu setzen, dann könntest du immer noch per Tastendruck eingreifen.
Der erste Eintrag muss nicht der aktuelle sein. Poste bitte mal
Codeuname -aEs sollte ein 6.18.5-1-default erscheinen.
Tut es auch, wie im weiter oben gezeigten Bildschirmfoto zu sehen ist. da war es noch der Vorgänger). Aber die vorgeschlagene Ausgabe ergibt
> uname -a
Linux linux.fritz.box 6.18.5-1-default #1 SMP PREEMPT_DYNAMIC Mon Jan 12 07:24:59 UTC 2026 (c0cb237) x86_64 x86_64 x86_64 GNU/Linux
Und was ist, wenn es mal einen "kaputten" Kernel gibt, der nicht startet?
Dann musst du per Live-System und chroot das wieder zurecht biegen.
Besser ist es, z.B. 2 Sekunden zu setzen, dann könntest du immer noch per Tastendruck eingreifen.
Gute Anregung! Werd ich nochmal ändern. Danke
Nun müsste man nur noch die Systemmeldungen, die während des Boot-Vorgangs kurz aufblitzen, verhindern.
Bedeutet und wie lange?
Was du aber machen kannst, ist alle plymouth Pakete deinstallieren, dann kommt nach dem Grub zwar keine schönen Bilder mehr, aber es spart Zeit.
Hab ich hier gemacht und bei mir kommen nur die Kernel Meldungen bis zur Anmeldung. Die verbrauchen aber keine zeit.
Bedeutet und wie lange?
Was du aber machen kannst, ist alle plymouth Pakete deinstallieren, dann kommt nach dem Grub zwar keine schönen Bilder mehr, aber es spart Zeit.
Hab ich hier gemacht und bei mir kommen nur die Kernel Meldungen bis zur Anmeldung. Die verbrauchen aber keine zeit.
Bootloader Optionen:
Habe zusätzlich die Python-Pakete entfernt, was aber keinen wesentlichen Zeitgewinn brachte,
Zunächst erscheint für ca. 20 - 30 s ein leerer Bildschirm, anschließend einige Zeilen mit Einstellungen des Grub- Menüs im Text-Modus.
Ich tipp mal drauf, dass das EFI in diesen 20-30 Sekunden die RAM Riegel auf Fehler checkt. "POST" des RAMs, bzw. je nach Motherboard unterschiedlicher Featurename, aber deaktivierbar. GRUB, bzw. die systemd logs bekommen diese Startverzögerung technisch bedingt nicht mit, weil noch nicht am laufen. Dieses Feature ist i.d.R. immer angestellt ab Werk, bisher bei unter 16 gig RAM fällt es kaum auf, aber bei 32 oder 64 gig oder mehr schlägt das aber auf einmal mit 2-4 Minuten drauf.
Ich tipp mal drauf, dass das EFI in diesen 20-30 Sekunden die RAM Riegel auf Fehler checkt. "POST" des RAMs, bzw. je nach Motherboard unterschiedlicher Featurename, aber deaktivierbar. GRUB, bzw. die systemd logs bekommen diese Startverzögerung technisch bedingt nicht mit, weil noch nicht am laufen. Dieses Feature ist i.d.R. immer angestellt ab Werk, bisher bei unter 16 gig RAM fällt es kaum auf, aber bei 32 oder 64 gig oder mehr schlägt das aber auf einmal mit 2-4 Minuten drauf.
Habe nur 16 GB RAM aber dafür meine 1 TB M2.SSD gegen eine mit 4 TB getauscht. Vielleicht hängt's damit zusammen?
