Garuda Linux UEFI Booteintrag nach Bios-Update verschwunden

[AvenDexx]

Hallo zusammen.

Ich habe vor einigen Tagen das UEFI meine Gigabyte Aorus B550 pro ac von F13 auf F15c geupdatet und seitdem das Problem, dass ich im UEFI meine SSD mit installiertem Garuda KDE nicht mehr als Boot-Medium angezeigt bekomme und somit nicht auswählen kann.

Vorweg die Ausgangslage meines Rechners. Es handelt sich um kein Dualboot-System. Garuda KDE wurde auf einer separaten SSD installiert, ohne dass ein anderer Datenträger im System angeschlossen war. Linux und Windows wissen also quasi nichts voneinander. Nach der Installation wurden alle anderen Laufwerke wieder angeschlossen und dann im UEFI die Bootreihenfolge eingerichtet. Grauda zuerst, dann Windows. Wollte ich also Windows starten, musste ich beim Rechnerstart per F12 die manuelle Bootauswahl aufrufen, um es dort auszuwählen.

Nach dem Bios-Update auf Version F15c ist der Eintrag meiner SSD verschwunden. Ich kann ohne Trick mein Garuda nicht mehr starten. Das geht nur, wenn ich meinen, mit Ventoy versehenen, Stick beim Booten auswähle, dort mein Garuda-Live Medium starte und mir dann dort im GRUB die lokalen Bootpartitionen anzeigen lasse. Hier ist mein auf SSD installiertes Garuda aufgeführt und die Auswahl führt dann auch zu einem reibungslosen Start des Systems, womit ich dann wie gewohnt arbeiten kann.

Unter Garuda habe ich geschaut, ob die Bootpartition auch also solche markiert ist und dass ist der Fall.

Da ich doch noch ein relativ ahnungsloser Linux-User bin, stehe ich nun vor einem kleinen, aber nervigen Problem, dass ich alleine nicht gelöst bekomme und hoffe hier auch mögliche Hilfe.

Wie bekomme ich es hin, dass mir meine Garuda-SSD im UEFI wieder angezeigt wird, damit ich vom Datenträger meiner Wahl booten kann, ohne den Umweg über den Ventoy-Stick gehen zu müssen?

Ich weiß nicht, welche Infos ihr aus meiner Garuda-Installation noch benötigt. Wenn da welche fehlen sollten, dann schreibt es mir, aber bitte dann auch direkt mit der Erklärung, wie ich an die Infos komme, denn wie gesagt, ich bin da doch noch relativ ahnungslos.

Danke und Gruß
Aven

 

[der Unzensierte]

keinein

was denn nun?

 

[AvenDexx]

Es sollte natürlich "kein" heißen, so wie es auch aus dem Zusammenhang des restlichen Absatzes hervorgeht.

 

[0x8100]

erstelle den booteintrag neu -> https://wiki.archlinux.org/title/EFISTUB#efibootmgr
die uuid bekommst du z.b. mit cfdisk oder fdisk -x raus:

 

[AvenDexx]

@0x8100
Ok, ich habe es mir mal angeschaut, steige da aber nicht so wirklich durch.

Die richtige UUID habe ich vermutlich gefunden. Doch bin ich mir nun absolut nicht sicher, welche Auswahl ich aus dem Tutorial nutzen soll. "To create a boot entry with efibootmgr that will load the kernel" oder "create a boot entry with efibootmgr and hibernation on swap partition" und wie wirkt sich das auf den vorhandenen GRUB aus, sofern es überhaupt Auswirkungen hat.

Was ist bei dem Befehl "efibootmgr --disk /dev/sdX --part Y" mit "Y" gemeint. Ja, Partition, aber was muss ich da genau eingeben? Wäre das bei mir "efibootmgr --disk /dev/sdc --part1"?

Ich bin da also Linux-Laie durchaus etwas überfordert, weshalb eine etwas ausführlichere Erklärung schon nützlich wäre.

Edit:
Wenn ich "cfdisk /dev/sdc1" starte, bekomme ich direkt die Meldung "Das Gerät enthält bereits eine vfat-signatur. Sie wird durch einen Schreibbefehl entfernt." Was hat das zu bedeuten?

 

[0x8100]

anscheinend hast du keine swap-partition, nur die efi und die root-partition. also trifft die erste variante zu. in dem fall müsste das dann bei so aussehen:

efibootmgr --disk /dev/sdc --part1 --create --label "Garuda" --loader /vmlinuz-linux --unicode 'root=PARTUUID=F30F1527-BA9C-784B-A950-9DBCB0216F42 rw initrd=\initramfs-linux.img' --verbose

du solltest vorher schauen, ob es auf der efi-partition auch die dateien "vmlinuz-linux" und "initramfs-linux.img" gibt. da garuda auf arch basiert, gehe ich mal davon aus.

 

[AvenDexx]

@0x8100

Im Verzeichnis /boot/ gibt es die Dateien "vmlinuz-linux-zen" und "initrams-linux-zen.img". Also die von dir genannten Dateien mit dem Anhängsel "-zen". Ebenso die Dateien "initrams-linux-zen-fallback.img" und "amd-ucode.img".

Mir ist auch aufgefallen, dass es in /boot/efi/EFI/Garuda die Datei "grubx64.efi" gibt. Ist das für den Vorgang auch wichtig?

Edit:
Müsste ich den Befehl, durch den anderen Namen der Dateien, noch wie folgt ändern?:

efibootmgr --disk /dev/sdc --part1 --create --label "Garuda" --loader /vmlinuz-linux-zen --unicode 'root=PARTUUID=F30F1527-BA9C-784B-A950-9DBCB0216F42 rw initrd=\initramfs-linux-zen.img' --verbose

 

[0x8100]

das kommando mit den geänderten dateinamen sollte so passen. du kannst da auch nichts kaputt machen. im schlimmsten fall funktioniert der neue booteintrag nicht und du löscht ihn wieder mit efibootmgr.

 

[AvenDexx]

Ok, ich versuche es mal. Sollte es nicht klappen, komme ich bezüglich des efibootmgr nochmal auf dich zurück. Vorab schon mal Danke für die Hilfe.

Edit:
Ging schneller als erwartet. Ich musste noch ein "sudo" für den Befehl setzen und eine Leerstelle zwischen "Part" und "1", danach klappte es dann. Allerdings brachte es keine Veränderung.

Im UEFI wird meine SSD mit Garuda noch immer nicht angezeigt und ich muss es über den Umweg mit Ventoy und dem Live-Image starten. Das klappt auch weiterhin, als wenn nie etwas gewesen wäre.

Hast du eventuell noch eine andere Idee?

 

[mkossmann]

Vielleicht als ersten Schritt ein "efibootmg -v" um zu sehen was vorhanden ist

 

[AvenDexx]

@mkossmann
Da ist ein Eintrag vorhanden. Wenn mich nicht alles täuscht, ist der erste, ganz oben, der auf die "bootx64.efi verweist. Der Zweite ist mein USB-Stick mit Ventoy.

 

[Tanzmusikus]

Bei meinem Pop!_OS war das Problem ein unterschiedliche UUID von /etc/fstab und Bootpartition.

Wenn es das nicht ist, bliebe m.W.n. noch den NVRAM zu löschen bzw. händisch nicht benutzte Einträge mittels EFI-Shell ... oder das TPM im UEFI zu resetten (Achtung! Bei verschlüsselter Partition nicht resetten!).
https://privat.albicker.org/blog/2018-08-25-uefi-eintraege-loeschen.html
https://wiki.ubuntuusers.de/EFI_Problembehebung/

Hast Du mal mittels SuperGrubDisk probiert, ob das System noch startet?
Also falls Du GRUB nutzen solltest. Edit3: Oder wie startest Du das Linux mit Ventoy?

Grüße

Edit1:
Benenne mal die BOOTX64.EFI in BOOTX64.EFI._ um.
Damit wird diese deaktiviert ... und hoffentlich ist dann über ein sudo update-grub wieder ein funktionsfähiger EFI-Eintrag vorhanden.

Edit2:
Ntutzt das immer noch nichts, dann baue die Garuda-SSD mal aus, starte das System & baue die SSD wieder ein.
Dies wäre momentan mein Favorit an Ideen ... und ist i.d.R. schnell & ohne Datenverlust durchzuführen.

 

[AvenDexx]

@Tanzmusikus

Zu deinem Edit 3:
Ich starte Ventoy, dort wähle ich mein Garuda Live Image aus, dieses startet einen eigenen Grub und von dort kann ich mir alle UEFI Einträge anzeigen lassen. Dort wird dann auch mein bereits installiertes Garuda angezeigt und ich kann es von da starten. Danach komme ich dann auch in den bekannten Grub meiner installierten Garuda Version und kann dann Beispielsweise auch Snapshots oder Fallback-Optionen auswählen, etc. Es ist dann so, als wenn er den Rechner direkt von der Garuda SSD gestartet hätte.

Edit 1 und 2 werde ich mal testen.

 

[Tanzmusikus]

Es ist dann so, als wenn er den Rechner direkt von der Garuda SSD gestartet hätte.

Fast!
Für Bearbeitung der EFI und ein paar Dateien auf der Garuda-Partition wird das wohl funktionieren, ...

aber falls Du z.B. eine Aktualisierung des GRUB machen möchtest, dann müsstest Du chroot nutzen, um Dich direkt mit der Garuda-Partition zu verbinden.

Grüße

 

[AvenDexx]

Ok, also die Datei umzubenennen und Grub zu aktualisieren hat leider nicht geholfen. Ebenso hat das Ein- und Ausbauen der SSD nichts gebracht.

Was mir aber gerade noch einfällt und möglicherweise eine interessante Info sein könnte:
Da ich Windows 11 nutze, ist im UEFI CSM Support deaktiviert. Aktiviere ich es, wird mir meine Garuda SSD wieder angezeigt. Leider ist es keine Option CSM aktiviert zu lassen, da es sonst zu Problemen mit Windows 11 kommt.

Bei deinen Ausführungen zu chroot kann ich dir nicht ganz folgen. Garuda selbst hat ein Tool, um den Grub zu bearbeiten und zu aktualisieren. Dieses Tool funktioniert soweit auch und das auch über die Bootmethode von Ventoy und dem Garuda Live Image. Es klappte zum Beispiel einwandfrei, das Hintergrundbild zu ändern. Ich kann daher nicht ganz nachvollziehen, was genau du da meinst. Dafür fehlt mir dann doch etwas Hintergrundwissen.

 

[Tanzmusikus]

Hattest Du bei Windows den Hibernation-Mode oder/und Schnellstart zum Herunterfahren benutzt.
Wenn ja, dann: Starte Windows ... und beende es mit "Herunterfahren" (nicht "Ruhezustand").

Schnellstart (ebenso Ruhezustand) kannst Du wie folgt deaktivieren:
https://www.heise.de/tipps-tricks/Windows-10-Schnellstart-deaktivieren-aktivieren-4000088.html

---

Chrooten brauchst Du, wenn Du direkten Zugriff (von innen) auf das Linux haben möchtest.
Damit lassen sich z.B. Kernel oder GRUB aktualisieren, anpassen oder entfernen.
Auch andere systemnahe Aktionen sind dann möglich.

Eine weitere Möglichkeit ist die SuperGrubDisk. Damit umgehst Du den vorhanden GRUB.
Bist dann später aber wirklich im Linux-System & kannst Dich mit Deinem Benutzernamen & Passwort anmelden.

Grüße

 

[AvenDexx]

Nein, den Schnellstart oder Hibernation-Mode nutze ich gar nicht. Habe ich auch noch nie. Das ist eines der ersten Sachen, die ich nach der Installation von Windows deaktiviere.

Zu deinen weiteren Ausführungen sag ich schon einmal Danke für die Info, aber ich verstehe nicht, wie mir das helfen könnte. Mit dem Grub habe ich ja prinzipiell keine Probleme. Mit Hilfe des Live-Datenträgers kann ich meine richtige SSD inkl. Grub ja starten. Das Problem ist "lediglich", dass mir meine Garuda SSD im UEFI nicht mehr angezeigt wird. Ich komme also gar nicht erst zu dem Punkt, mein Garuda direkt starten zu lassen.

Oder verstehe ich da noch immer etwas grundlegend falsch?

 

[Tanzmusikus]

Nein. Ich hatte nur alle meine Ideen geschrieben, die erstmal in alle Richtungen gingen.
Außerdem waren mir die genauen Details zur Boot-Kette noch nicht ganz klar.

Ist Secure Boot im UEFI deaktiviert, wenn der UEFI only-Mode aktiv ist?
Irgendwas liegt im Argen, wenn GRUB mit CSM angezeigt wird, aber nicht im UEFI only-Mode.

Das UEFI lies ja den NVRAM, um die dort abgelegten EFI-Starteinträge starten zu können.
Mir fehlt auch die vollständige Ausgabe von sudo efibootmgr -v

Bitte kopiere dies direkt aus dem Terminal (bitte keinen beschnittenen Screenshot!) ... oder skaliere das Terminal-Fenster so, dass alle Zeichen ordentlich sichtbar sind.

Persönliche Zeichen wie z.B. BenutzerName dürfen weggelassen, ersetzt oder nachträglich überdeckt werden.

Grüße

Edit:
Im UEFI-Mode soll bei Arch Systemd-Boot zum Tragen kommen (wie auch bei meinem Pop!_OS).
Nur im BIOS bzw. Legacy-Mode kann GRUB verwendet werden.

 

[AvenDexx]

Secureboot ist, genau wie vor dem Update, Eingeschaltet, aber deaktiviert. So klappte das mit Windows 11 problemlos und Garuda habe ich dann später einfach installiert, ohne Änderungen am UEFI vorzunehmen.

In Beitrag 11 hatte ich einen Screenshot von sudo efibootmgr -v gepostet. Den ersten Eintrag hatte ich aus Platzgründen ausgeschnitten, da es sich ja eh um das Laufwerk von Windows handelt. Habe aber einen neuen Screenshot gemacht und hier angehängt. Da müsste nun alles zu sehen sein.

Noch kurz zur Info: SanDisk ist der USB-Stick, das Andere sind meine internen Laufwerke.

Edit bezüglich deiner Ergänzung:
Ok, das weiß ich nicht. Ich weiß nur, dass beim Start von Garuda immer der GRUB angezeigt wurde. 😕

Edit 2:
Was mir gerade mal so auffällt, unter Boot0004 wird am Ende auf die Bootx64.efi verwiesen. Wenn ich mein Garuda aber über den Trick mit Ventoy starte, wird dort allerdings die grubx64.efi angezeigt. Hat das eventuell was zu sagen?

 

[@mo]

Zeige doch bitte Mal aus dem laufenden System und/oder aus einem Live System heraus folgende Terminalausgaben.

sudo parted -l ## -l = kleines L
sudo efibootmgr -v

Beides als Text oder Code (Copy und Paste) und vollständig (wie bereits vom Kollegen erbeten).Keinen Screenshot!

Was mich stutzig macht, sind deine Anmerkungen zu CSM. Das lässt verschiedene Bootmodi vermuten. Kann sein, dass das BIOS Update da was verschlimmbessert hat.