staging.inyokaproject.org

Hej,

ich betreibe hier einen stand-alone grub. Soweit so gut, allerdings beobachte ich hin und wieder, daß bis zum grub Menü unterschiedlich viel Zeit vertreicht.

• Mal erscheint das Menü "unmittelbar" nachdem das Hintergrundbild geladen wurde.

• Ein andermal aber dauert es zwischen Bild und Menü gefühlt dann "Minuten".

Gibt es eine Möglichkeit, diesen Umstand in einem Protokoll (o.ä.) nachzuvollziehen?

Gruß black tencate

black_tencate schrieb:

Gibt es eine Möglichkeit, diesen Umstand in einem Protokoll (o.ä.) nachzuvollziehen?

Hast du mal den Bootvorgang sichtbar gemacht?

Das hier angesehen: die Meldungen des Kernel-Ringpuffers?

Hej Berlin_1946,

Berlin_1946 schrieb:

Hast du mal den Bootvorgang sichtbar gemacht?

wenn Du mir sagst, wie? (das ist ja gerade die Frage)

Das hier angesehen: die Meldungen des Kernel-Ringpuffers?

Irgendwelche O/S (kernel) sind doch zu dem Zeitpunkt noch gar nicht im Spiel, außer natürlich core.img von GRUB selber.

Gruß black tencate

black_tencate schrieb:

wenn Du mir sagst, wie? (das ist ja gerade die Frage)

Ja, war mir nicht so genau klar gewesen, was genau mit "Verhalten zwischen POST und grub Menü" gemeint war. 😢
Aus dem Link: die Meldungen des Kernel-Ringpuffers

sudo dmesg -T| more

Und bei jedem Booten:

Plymouth (Abschnitt „Plymouth-beim-Bootvorgang-deaktivieren“)

black_tencate schrieb:

[…] Gibt es eine Möglichkeit, diesen Umstand in einem Protokoll (o.ä.) nachzuvollziehen?

Das Problem betrifft die Startphase vor dem Start des Kernels. Es ist daher nicht zu erwarten, das in den vom Betriebssystem geführten Log-Dateien etwas davon auftaucht.

Grundsätzlich könnte in einem von der Firmware geführten Log etwas dazu vermerkt sein, jedoch führt nicht jede Rechnerfirmware überhaupt so ein Ereignisprotokoll.

Im vorliegenden Fall sollte als erstes die Stützbatterie (Knopfzelle) der Hardware-Rechneruhr überprüft werden. Wenn diese erschöpft ist, verliert der Rechner seine Konfiguration und die Firmware muss dann wieder den Werkszustand einstellen.

Hej kB,

kB schrieb:

...jedoch führt nicht jede Rechnerfirmware überhaupt so ein Ereignisprotokoll.

diese hier jedenfalls nicht

Im vorliegenden Fall sollte als erstes die Stützbatterie (Knopfzelle) der Hardware-Rechneruhr überprüft werden. Wenn diese erschöpft ist, verliert der Rechner seine Konfiguration und die Firmware muss dann wieder den Werkszustand einstellen.

das ist wohl nicht der Fall, denn an den spezifischen Einstellungen ändert sich nichts.

Ein vergleichbares Verhalten (allerdings nicht zwischen Bild und Menü) kann ich hier provozieren: Wenn beim Start ein zusätzliches device mit Bootloader angesteckt ist, Sucht das UEFI danach und generiert auch einen Eintrag im NVRAM. Das dauert natürlich.

Vielleicht hier mal, was "chatGPT" dazu sagt: (sorry, aber ich mache mir nicht die Mühe, den wohlformatierten output heir umzuformatieren)

Frage: ich betreibe GRUB 'stand-alone'. Dabei fällt auf, daß hin und wieder eine Verzögerung eintritt zwischen dem Laden des Hintergrundbildes und des eigentlichen grub Menüs. Was kann die Ursache dafür sein?

Antwort: Wenn du GRUB stand-alone betreibst (also z. B. von einem USB-Stick oder ohne ein vollständiges Linux-System im Hintergrund), und es kommt zu Verzögerungen zwischen dem Laden des Hintergrundbildes und der Anzeige des Menüs, dann gibt es eine Reihe möglicher Ursachen, die du untersuchen kannst. 🧩 Mögliche Ursachen für die Verzögerung zwischen Bild und Menü 1. Langsamer Zugriff auf das Dateisystem

GRUB lädt das Hintergrundbild von einem Speichergerät (z. B. USB-Stick oder Festplatte). Wenn der Zugriff auf die Partition oder das Dateisystem (FAT32, ext4 etc.) langsam oder instabil ist, kann das Laden des Bildes schnell gehen, aber die restliche Konfigurationsverarbeitung sich verzögern.

✅ Prüfen:

Ist das Gerät langsam (z. B. älterer USB-Stick)?

Ist das Dateisystem fragmentiert oder beschädigt?

2. Grafikmodus-Initialisierung dauert länger

Wenn du ein Hintergrundbild verwendest, muss GRUB einen grafischen Modus aktivieren (meist über gfxmode). Die Umschaltung in diesen Modus und ggf. das Laden von Fonts kann zu Verzögerungen führen – besonders auf manchen UEFI-Systemen oder älteren Grafikkarten.

✅ Prüfen:

Testweise GRUB_GFXMODE=text setzen → siehst du dann das Menü schneller?

In der grub.cfg: aufwendige Grafikeinstellungen entfernen/testen.

3. Fonts oder andere Ressourcen werden nach dem Bild geladen

Ein typischer Ablauf in grub.cfg (manuell oder per grub-mkconfig erzeugt) sieht etwa so aus:

set gfxmode=1024x768 insmod gfxterm insmod png set background_image=/boot/grub/themes/mytheme/background.png loadfont /boot/grub/fonts/unicode.pf2 terminal_output gfxterm

Wenn background_image vor dem Laden des Fonts oder vor dem Setzen des Terminals geladen wird, kann es zu einem kurzen Hänger kommen, da GRUB intern umschalten muss.

✅ Lösung:

Stelle sicher, dass die Font- und Terminal-Initialisierung vor dem Bild erfolgt.

4. Hardwarebedingt: UEFI vs. BIOS

GRUB verhält sich unter UEFI oft etwas anders als unter BIOS/Legacy. Einige UEFI-Implementierungen haben Probleme mit z. B. schnellen Umschaltungen zwischen Text- und Grafikmodus.

✅ Test:

Starte GRUB mit terminal_output console → wird es dadurch sofort sichtbar?

Verwende GRUB nur im Textmodus, um die Unterschiede zu messen.

5. GRUB Themes / Komplexe Menüs

Wenn du ein Theme verwendest (z. B. via /boot/grub/themes/...), dann kann das Rendern des Themes oder die Konfiguration (Menüeinträge, Icons etc.) spürbar länger dauern – vor allem bei großen Konfigurationen.

✅ Prüfen:

Testweise GRUB_THEME deaktivieren und simples Menü verwenden.

Hintergrundbild nur direkt per background_image setzen, ohne vollständiges Theme.

🔧 Debugging-Tipps 📝 GRUB-Debug-Ausgaben aktivieren (sofern Text sichtbar):

In grub.cfg (oder direkt in der Shell):

set debug=all

Damit zeigt GRUB beim Laden mehr über die Schritte an – auch, wo es möglicherweise hängt. 🚀 Empfehlung zum Eingrenzen:

Textmodus testen:

set terminal_output=console

→ Wenn das Menü dann sofort erscheint, liegt es an der Grafikinitialisierung.

Font und terminal_output vor dem Bild setzen.

Langsames Medium ausschließen (z. B. USB → SSD vergleichen).

Theming deaktivieren/testweise vereinfachen.

Wenn du mir deine grub.cfg (oder den relevanten Teil) zeigst, kann ich dir genau sagen, wo Optimierungspotenzial ist.

Da sind einige Dinge, die ich überprüfen/ändern kann, allerdings ist chatGPT nicht auf "hin und wieder" eingegangen. Ich tippe auch mal, eine möglich Fragmentierung 'ändert' sich nicht von selbst.

Zu Tipp 4. z.B. kann ich sagen, es ist kein Unterschied, jedenfalls kein ins Auge springender festzustellen.

Gruß black tencate