Grub2 (Fedora 40) braucht lange (~8s) bis LUKS2 Passwort-Prompt

[Mickey Cohen]

Hallo,

Vorbemerkung: der Titel ist falsch, tatsächlich ist es wohl nicht Grub2 alleine, sondern wohl auch das UEFI, das solange braucht (beide jeweils ca. 4 sekunden).


ursprungspost:
ich habe hier einen laptop mit UEFI, grub2 und fedora 40 (mit LUKS2 verschlüsselt).

• partitionstabelle ist natürlich GPT. Bootmodus ist "UEFI", "CSM" hat der laptop garnicht.
• der bootloader (Grub2) und der kernel (vmlinuz) liegen auf der unverschlüsselten partition "/boot".
• die root-partition "/" ist auf einer mit LUKS2 verschlüsselten ext4-partition (ohne lvm).
• zudem gibt es noch eine verschlüsselte datenpartition, ebenfalls ext4 (ohne lvm).
• secure boot ist aktiviert (dekativieren hilft nichts)
• notebook: Lenovo IdeaPad 5 Pro 16 ARH7, Ryzen 6600HS, pcie 4.0 nvme-SSD

mein problem ist:

ab dem zeitpunkt, in dem das erste mal das GRUB-menü zu sehen ist (bei fedora hat man da als mögliche bootoptionen immer die wahl zwischen den aktuellen und letzten kernelversionen) und dem zeitpunkt, in dem der LUKS2-passwort-prompt erscheint, vergehen 8 sekunden (wobei der grub-timeout von 1s bereits abgezogen ist).

journalctl startet bei sekunde 0. bei sekunde 4 der "journalct-zeit" erscheint der passwort-prompt. das finde ich ist gerade noch ok.

mit stoppuhr (handy gemessen) sind es aber 8 sekunden (grub-timeout von 1s bereits abgezogen), von dem zeitpunkt an, an dem ich grub das erste mal sehe bis zu dem zeitpunkt, in dem das passworteingabefeld erscheint.

das heisst es bleiben dann immer noch 4 sekunden verteilt auf den zeitraum, in den die "übergabe" von grub2 auf den kernel und der beginn des timestampings durch journalctl beginnt. das finde ich etwas lange...


Erfolglose Lösungsversuche:

1. ich habe bereits ausprobiert, in der datei

/etc/default/grub

die zeile

GRUB_CMDLINE_LINUX="rhgb quiet"

auf

GRUB_CMDLINE_LINUX="quiet"
bzw
GRUB_CMDLINE_LINUX=""

zu ändern (also den grafischen bootloader zu deaktivieren) (natürlich anschließend sudo grub2-mkconfig -o /boot/grub2/grub.cfg angewendet), mit dem ergebnis, dass es die promptzeit sogar nochmal verlängert.*

*was mMn. genau passiert ist folgendes:
grub promptet mir die passworteingabe nach ca. 8s auch dann, wenn ich rhgb deaktiviere. allerdings wird der prompt dann "überschrieben" und weitere meldungen werden angezeit. erst nach ca. 20 sekunden sehe ich den prompt dann wieder und kann ihn "beschreiben".
wenn ich rhgb aktiviere, dann bekomme ich den prompt auch nach 8s angezeigt (und zwar "gestylt", weil grafisch dank rhgb möglich). allerdings bleibt er dann wegen rhgb im "vordergrund", während die anderen meldungen, die bei deaktiviertem rhgb den prompt "überlagern" im hintergrund ablaufen.


2. "Fastboot" im UEFI gibt es nicht mehr, hat auch nichts geholfen, als die funktion noch verfügbar war.

3. Im UEFI ist sowohl boot from USB als auch WLAN deaktiviert.

4. Secure Boot deaktivieren hat auch nichts gebracht

5. fsck in der fstab deaktivieren

(also nochmal zur klarstellung:
problem ist nicht die zeit vom drücken des einschaltknopfes bis zum erscheinen von grub.
problem ist auch nicht die zeit ab eingabe des LUKS2-passwortes)

Vielen Dank für eure hilfe

 

[Yaakoss]

Die Parameter die in GRUB_CMDLINE_LINUX übergeben werden sind keine Grub-Parameter sondern eigentlich Kernel, bzw. User-Space-Parameter.
Bist du sicher, dass der Kernel nicht in der unverschlüsselten /boot-Partition liegt?
Es klingt nämlich eher danach, dass es der Kernel ist, welcher nach dem Luks-Passwort fragt.


LG
Patricia

 

[Mickey Cohen]

ups, da hast du recht, der kernel liegt tatsächlich auf der unverschlüsselten /boot partition. das hatte ich falsch in erinnerung.

 

[Yaakoss]

Wie gesagt, ich denke es ist da bereits der Kernel der nach dem Passwort fragt. Zuerst wird ja der Kernel und das Initramfs geladen und abgearbeitet. Je nach Distribution werden da einige Sachen zuerst abgearbeitet, bevor das eigentliche Root-System eingehangen wird und der Bootvorgang abgeschlossen wird.

Ich kenne Fedora so ziemlich gar nicht, daher kann ich aber kaum beurteilen ob die 8 sek langsam sind, wenn es um die Eingabe geht. Zumindest da man für die Eingabe des Paswortes sicherlich auch noch so einiges an Zeit benötigt.

 

[Mickey Cohen]

die eingabe des passwortes ist natürlich in den 8 sekunden nicht enthalten. es dauert 8 sekunden, bis ich überhaupt das feld zu passworteingabe sehe.

also ich habe es jetzt noch einmal genauer angesehen.

journalctl startet bei sekunde 0. bei sekunde 4 der "journalct-zeit" erscheint der passwort-prompt. das finde ich ist gerade noch ok.

mit stoppuhr (handy gemessen) sind es aber 8 sekunden (grub-timeout von 1s bereits abgezogen), von dem zeitpunkt an, an dem ich grub das erste mal sehe bis zu dem zeitpunkt, in dem das passworteingabefeld erscheint.

das heisst es bleiben dann immer noch 4 sekunden verteilt auf den zeitraum, in den die "übergabe" von grub2 auf den kernel und der beginn des timestampings durch journalctl beginnt. das finde ich etwas lange...

 

[Yaakoss]

Viele Grub-Module und Grub selbst sind sehr platzsparend programmiert und der Code ist universell einsetzbar ohne sich auf CPU-Funktionen zu verlassen. Das kann dadurch unter Umständen langsamer sein. Gutes Beispiel ist z.B. das öffnen der LUKS2-Verschlüsselung durch Grub (Grub kann das und gepatcht sogar Luks2 mit argon2)
Evtl. kannst die Geschwindigkeit hier etwas optimiert werden, wenn der Kernel anders gepackt wird In Arch kannst du in der mkinitcpio.conf angeben wie der Kernel gepackt wird und je nach dem bringt es die eine oder andere Sekunde (zumindest wenn UKI verwendet wird)Evtl. da ansetzen. Vielleicht Systemd-boot oder anderen Bootmanager verwenden? Je nach UEFI kannst du ja sogar direkt den Kernel booten ohne Grub oder ähnliches . (Geht bei meinem Lenovo-Notebook nicht)

 

[Mickey Cohen]

ist es möglich, den LUKS2-passwort-prompt, den der (unverschlüsselte) kernel beim booten ausgibt, zeitlich irgendwie nach vorne zu verlagern?

die idee dahinter ist: fürs eingeben des passwortes brauche ich sowieso ein paar sekunden (so ca. 5s). in dieser zeit kann der kernel andere sachen laden/initialisieren.

Ergänzung (24. Mai 2024)

nein nicht wirklich also die meiste zeit, geht dann fürs starten der services drauf und das kann, bei verschlüsselt root, erst beginnen nach dem du mit luks fertig bist

ansonsten kommt, der passwort prompt, durchs initrams, eigtl schon so früh wie es geht. schneller, ginge dann nur mit keyfiles (yubi stick wo man nur ein knopf drückt oder dergleichen). du sparst die zeit zum tippen, und bei ausreich komplexer passphrase brauchst du auch kein brute force schutz die 2 sekunden rechenzeit die luks normal ins passphrase investiert kann entfallen wenn die passphrase 128 bit oder mehr entropie aufweist

wenn du verschlüsselung wichtig brauchst dann muss es die paar sekunden, einfach wert sein. woe oft startest du neu das sich hier, mikro optimierung lohnt?

(ausnahmsweise ein zitat, weil ich einen anderen thread zitiere. ich hoffe das ist in ordnung)

ich bin ein bisschen durcheinander gekommen, deshalb bitte hier in diesem thread hier weitermachen. sry...

wieso geht es mit den von dir angesprochenen keyfiles (yubikey) dann schneller? mein problem ist ja die zeit BIS zum passwort-prompt (also bis das eingabefeld erscheint). ob das passwort nun eines ist, das ich selbst erst eintippen muss oder ein keyfile ist, kann ja auf die zeit BIS zur passwortabfrage keinen einfluss haben?

 

[kieleich]

wieso geht es mit den von dir angesprochenen keyfiles (yubikey) dann schneller?

du musst nichts eintippen das macht der usb key für dich

und, der kann so ein komplex passphrase erzeugen, das luks sich die 2s rechenzeit anti-bruteforce sparen kann

setzt voraus das du den key slot so angelegt hast das kein bruteforce schutz besteht

spart 2 sekunden plus die zeit die du sonst zum selber eintippen brauchst

an der restlichen zeit bis vor nach der abfrage ändert sich nichts


ps: du sprichst vun unverschlüsseltem /boot daher gehe ich mal davon aus, das Grub Crypto nicht aktiviert ist. Grub ist QUÄÄÄLEND LAAAANGSAAAAM mit crypto. /boot verschlüsseln ist barer unsinn.

 

[Mickey Cohen]

ah, also der bruteforceschutz wird ausgeführt bevor ich das passwort eingebe soll? ok, so macht das wieder sinn...

 

[kieleich]

nein

du tippst das passwort ein

dann passiert ... eine weile nichts während luks sekundenlang herum rechnen tut

ohne bruteforce schuttz: du tippst das passwort ein und es geht "sofort" weiter

mit bruteforce schutz ist passwörter durchprobieren sehr teuer

ohne bruteforce schutz muss das password viel komplexer sein (sehr hohe entropie)

entropie wird bei XKCD gut erklärt - 44 bits sind, für festplatten verschlüsselung, ohne bruteforce schutz, jedoch zu wenig

yubikey (und andere solche lösungen) werden da mit 128 256 oder noch mehr bits um sich werfen aber auf der tastatur kannst du so ein komplex passphrase kaum eintippen und 16 wörter tippen dauert auch wieder lange

 

[Mickey Cohen]

aber es geht doch nicht um die zeit ab der passwortabfrage. die ist voll in ordnung.

es geht um die zeit, bis der kernel überhaupt nach irgendeinem passwort frägt:

ich schalte das gerät ein -> muss 8 sekunden warten -> tippe mein passwort ein

mit einem keyfile würde das so ablaufen:

ich schalte das gerät ein -> 8 sekunden vergehen -> der kernel benutzt das keyfile um die entschlüsselung zu starten.


diese 8 sekunden müssen entweder weniger werden oder sinnvoll genutzt werden können (und diese sinnvolle nutzung wäre eine manuelle passworteingabe).

also etwa so:

ich schalte das gerät ein -> ich muss ein paar (wenige! 2, 3, 4) sekunden warten bis das UEFI/der bootloader durch sind -> ich tippe das passwort ein, während der kernel bereits kernelsachen macht.


ich habe im anhang mal folgende ausgaben beigefügt, vll. kann ja mal wer nen blick drauf werfen, ich kann das leider nicht interpretieren:
journalctl -b 0 (bis zu dem zeitpunkt, in dem der prompt erscheint, ab dann habe ich es abgeschnitten)
systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain
systemd-plot
Partitionsübersicht

außerdem habe ich bereits versucht, fsck in der fstab zu deaktivieren, hat auch nichts gebracht.

 

[Marco01_809]

Probier mal systemd-analyze blame in deinem gebooteten Linux. Das zeigt dir für den letzten Boot an welcher Service/Device am längsten den Boot aufgehalten hat. Dann mit systemd-analyze critical-chain kann man die Abhängigkeiten als Baum sehen. Je nachdem welchen Bootloader man verwendet kann es dir auch anzeigen wie lange die Firmware/UEFI und der Bootloader gebraucht haben.

Weiter würde ich mir auch mit dmesg oder journalctl -k den boot log des kernels anschauen und überprüfen ob es irgendwo große Zeitsprünge gibt. Wenn deine Disk unlocked wird gibt es in diesem Log auch eine Meldung mit cryptsetup oder dm-crypt. dmesg zählt die Sekunden ab dem Zeitpunkt wo der Kernel ausgeführt wird. An dem Zeitstempel des unlocks könnte man auch festmachen, ob Firmware/Bootloader den Boot verzögern.

EDIT: Da bist du mir schon zuvor gekommen, ich schaue die Logs mal an, moment

ist es möglich, den LUKS2-passwort-prompt, den der (unverschlüsselte) kernel beim booten ausgibt, zeitlich irgendwie nach vorne zu verlagern?

die idee dahinter ist: fürs eingeben des passwortes brauche ich sowieso ein paar sekunden (so ca. 5s). in dieser zeit kann der kernel andere sachen laden/initialisieren.

Nein, das geht nicht. Der Kernel macht schon gar nicht so viel bevor er die Kontrolle an das init Programm übergibt. Generell läuft der Bootvorgang von Linux auf einem x86 PC so ab:

• firmware: UEFI tut sein ding
• loader: Bootloader wird ausgeführt (i.d.R Grub2)
  • Lokalisiert die /boot partition
  • Liest kernel und initramfs von der Partition <-- Kann dauern bei sehr langsamer Disk
  • Dekomprimiert beide in den RAM <-- Kann dauern bei langsamer CPU
• kernel: Kernel wird ausgeführt, grundlegende Initialisierung der Hardware, etc. <-- dmesg fängt an Zeit zu zählen
• initrd: init Programm aus dem initramfs wird ausgeführt (i.d.R. systemd)
  • Versucht alles aus deiner /etc/fstab zu mounten, stellt fest dass eine partition verschlüsselt ist
  • Fragt nach Passwort und unlocked die Partition
  • Root-Dateisystem gemountet
  • switch_root vom initramfs auf das root-Dateisystem, initramfs wird verworfen
• userspace: init Programm aus deinem root-Dateisystem wird ausgeführt (i.d.R. erneut systemd)
  • Start aller Dienste, Netzwerke, etc. bis zum graphischen Login-Screen

Das initramfs ist ein Archiv (wie eine zip) mit einem minimalen Abbild deines Betriebssystems; es ist nur das allernötigste drin um den Rechner zu booten (kernel module und firmware für die wichtigsten geräte, init programm, kopie einiger dateien aus /etc, Reparaturwerkzeuge wie fsck). Kernel und initramfs sind das einzige was unverschlüsselt rumliegt. Das ganze ist eigentlich schon auf das nötigste reduziert und bevor das root-Dateisystem nicht verfügbar ist kann man nicht mehr so viel machen.

 

[Mickey Cohen]

@Marco01_809

da hat sich mein edit wohl mit deinem post überschnitten

ich finde einfach, dass das nicht sein kann, dass das 8 sekunden dauert, bei einem gerät mit ryzen 5 6600hs, 16 gb lpddr5-6400 und nvme pcie4.0 ssd.

wenn ich mir oben den systemd-analyze plot ansehe, heisst es doch wieder, dass alleine für den uefi- und den grub-part jeweils gut 4s draufgehen, das kann doch nicht sein?

edit:
hier noch meine partitionsübersicht:

 

[Marco01_809]

ich habe im anhang mal folgende ausgaben beigefügt, vll. kann ja mal wer nen blick drauf werfen, ich kann das leider nicht interpretieren:

Startup finished in 4.603s (firmware) + 4.656s (loader) + 861ms (kernel) + 20.254s (initrd) + 7.209s (userspace) = 37.585s

Da haben wirs schon. UEFI braucht 4.6s bis es endlich grub anschmeißt. Grub braucht 4.6s um Kernel und initramfs zu lesen+dekomprimieren. Kernel braucht nur 0.8s bis es init anwirft. Ich habe die Namen mal in meiner Ablaufbeschreibung oben in Fett ergänzt.

Aus dem plot kann man dann entehmen dass das initramfs etwa 0.6s braucht um festzustellen dass es dich nach dem Disk Passwort fragen muss (systemd-ask-password-plymouth.service). Da plymouth grafisch ist muss zunächst die GPU initialisiert werden; laut plot beginnt etwa 2s später drm-card1-card1\x2deDP\x2d1-amdgpu_bl1.device und dauert dann geschlagene 16s bevor der Boot-Vorgang weitergeht. Jetzt bin ich aber überfragt ob du schon innerhalb der 2s dein Passwort eingegeben hast und amdgpu_bl1.device nur irgendeinen zusätzlichen Kram initialisiert oder ob es tatsächlich so lange dauert bis die grafische Ausgabe erscheint.

Grub ist kein besonders schlanker Bootloader und viele Distributionen bewegen sich in die Richtung in Zukunft systemd-boot für UEFI zu benutzen, welches schlanker und schneller daherkommt. Das ist heute schon nutzbar, evt. willst du dir das anschauen. In der Regel muss man hierzu aber Secure Boot deaktiviert oder seine eigene Secure Boot Keys im UEFI installieren. Das liegt daran dass bei systemd-boot das initramfs mit signiert wird, welches aber dynamisch auf deinem Rechner generiert wird, je nach deiner Hardware+Konfiguration. Und wenn man am Bootloader rumspielt läuft man natürlich bei jedem Fehler Gefahr dass der PC hinterher nicht mehr bootet und man das OS umständlich von einem Live Stick recovern oder neu installieren muss.

Du könntest auch mal schauen ob du plymouth entfernen kannst; dann hast du beim booten und der Passwort-Eingabe noch keine grafische Ausgabe (1. Bild) sondern nur eine Eingabe im Text-Mode (2. Bild). Der Vorteil ist dass die GPU erst viel später initialisiert werden muss, da der Text-Mode "von Haus aus" durch das UEFI bereitgestellt wird.

 

[Mickey Cohen]

ok, danke erstmal.

also ich habe bereits versucht, ohne den boot-parameter "rhgb" zu booten. (das sollte den grafischen boot deaktivieren und damit auch plymouth). das hat jedenfalls die zeit bis zur passwortabfrage nicht verkürzt (sie oebn, eingangspost).

=> immerhin weiß ich jetzt, dass das problem also DOCH bei UEFI und GRUB2 liegt.

gut, bei grub muss man noch den timeout von 1s abziehen, dann sind wir immer noch bei 3 sekunden mehr, als laut internetrecherche so allgemein üblich sein sollte (~500ms).

deshalb hier mal noch die grub.cfg als .txt

 

[Marco01_809]

4.6s für UEFI cold boot sind nicht soo schlecht. Natürlich nicht optimal für ein mobiles Laptop aber UEFI Bootzeiten sind einfach Glück und man hat da wenig Einfluss drauf. Man kann nur alle Funktionen die man nicht braucht im UEFI deaktivieren, die anderen Boot-Optionen deaktivieren (deine SSD sollte ganz oben sein) und ggf. Updaten.

Beim Bootloader lässt sich mehr machen.
Zunächst kann man den Kompressionsalgorithmus vom initramfs image ändern. Bei Fedora ist hier dracut zuständig. In der dracut.conf gibt es eine option compress=, die kann man auf lz4 ändern welches besonders schnell dekomprimiert. Sollte bei deiner modernen CPU aber eigentlich keine 3s ausmachen. Nach anpassen der Konfiguration dracut --regenerate-all als root ausführen um das initramfs image neu zu generieren.

Es gibt auch die Möglichkeit GRUB Debug Messages ausgeben zu lassen. Damit sollte sich die Ursache für die lange Bootzeit finden oder zumindest eingrenzen lassen.

Ferner kann man auf einen Bootloader wie Grub ganz verzichten. Hierzu unterstützt Linux EFISTUB-Booting. Dabei werden Kernel+Initramfs in in ein .efi Programm gepackt, welches dann auf die EFI Partition gelegt und als Boot-Eintrag registriert wird. Das UEFI startet dann unmittelbar direkt in den Kernel. Die ganze /boot Partition ist überhaupt nicht mehr notwendig. In der Regel wird dies aber mit systemd-boot kombiniert was ein schöneres Menü hat wenn man nach einem fehlgeschlagenen Update mal einen alten Kernel booten muss. Aber zwingend braucht man es nicht. Wie gesagt aber nur was für erfahrenere Nutzer die Lust auf Basteln haben.

 

[Mickey Cohen]

habe jetzt mal systemd-boot eingerichtet und bin positiv überrascht: ~4s schneller bis zum passwort-prompt

falls jemand mal via google oder sonst auf diesen thread stößt:

Diese Anleitung hat bei Fedora 40 geklappt.

Folgende Schritte dieser Anleitung sind nicht notwendig und kann man sich sparen:

- der "Umzug" des mountpoints /boot/efi auf /efi
(beachte, dass in den kommandos, die in der Anleitung folgen, dann in analoger anwendung eben nicht /efi sondern /boot/efi zu verwenden ist)

- der befehl
sudo dnf reinstall kernel-core
am schluss ist ebenfalls nicht notwendig.


Auch neue Kernel, die mit "sudo dnf update" kommen, werden automatisch eingespielt.

Was ich aber noch nicht sagen kann und noch beobachten muss ist, ob auch alte kernel dann wieder gelöscht werden, nicht dass sich die EFI-Systempartition zumüllt.

 

[foofoobar]

GRUB_CMDLINE_LINUX="rhgb quiet"

auf

GRUB_CMDLINE_LINUX="quiet"
bzw
GRUB_CMDLINE_LINUX=""

Probier mal nur "nosplash".