Wenn Grub nicht mehr bootet

Manchmal haben Bugs eine Geschichte und die Geschichte dieses Grubbugs wird heute erzählt werden.

Wenn Grub nicht mehr bootet

Damit der Eintrag nicht zu lang wird, gibt es nur die Highlights. Nehmt einfach an, daß da noch viel mehr in Spiel war 😉

Vor ein paar Jahren stellte ich auf meinem Fedora Surface Tablet fest, daß trotz dessen, daß neue Kernels installiert wurden, diese nicht im Bootmenü angezeigt wurden bzw. der gewählte Bootkernel nicht benutzt wurde, dafür waren uralte Einträge da drin bzw. nahm er immer den ersten Kernel.

Weil es eine recht neue Installation und das Gerät ein UEFI Bios hatte, wurde eine EFI Partition angelegt und eingebunden, ganz so, wie das sein muß. Auf dieser EFI Partition wird vom OS, hier Fedora, ein passender Ordner angelegt und u.a. der BootShim hingelegt:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 6523 3. Okt 2020 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Wie man sehen kann, liegt hier eine grub.cfg und eine grubenv , diverse Backups durch RPM und mich rum. Die gleichen Dateien findet man unter /boot/grub2/ auch nochmal, dort gehören Sie aber eigentlich auch hin.

Damals passierte folgendes

GRUBBY schrieb die Änderungen der Bootreihenfolge nach /boot/grub2/grubenv , aber GRUB lud die grubenv von /boot/efi/EFI/fedora/grubenv. Das ist die Quintessenz einer langen Investigation.

Die ganze Geschichte war etwas komplizierter, wie man in Bug #1625124 sehen kann.

Die Lösung war damals einfach: eine der Dateien mußt zur Anderen verlinkt werden.

ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv 

Damit waren beide immer in Sync und das von GRUB selbst geschaffene Problem, zwei verschiedene Orte zu benutzen, behoben. Jahrelang blieb der Fix bestehen und das mittlerweile auf Fedora 39 aktualisierte Tablet bootete immer korrekt.. bis diesen Montag 🙁 Da bootete es nicht mehr.

Stattdessen kam nur die GRUB-Shell. Alles reinstallieren vom GRUB-Bootloader, Konfig neu bauen half nichts.Ergo war das ein Fall für Linux am Dienstag, bei dem wir ganz praktisch das Problem besprochen, analysiert, gescheitert und dann final erfolgreich waren \o/

Was war passiert?

Am Wochenende waren Updates eingespielt worden, auch von Kernels und Grub. Was keiner dem Benutzer und damit dem Patch erzählt hat war der Umstand, daß das GRUB Team den 6 Jahre alten Problemfall behoben hat:

[root@surface fedora]# ls -la /boot/efi/EFI/fedora/
insgesamt 17654
drwx------. 3 root root 2048 20. Sep 18:03 .
drwx------. 4 root root 2048 19. Jul 2023 ..
-rwx------. 1 root root 112 19. Mär 2024 BOOTIA32.CSV
-rwx------. 1 root root 110 19. Mär 2024 BOOTX64.CSV
drwx------. 2 root root 2048 4. Apr 19:36 fonts
-rwx------. 1 root root 2960704 12. Apr 01:00 gcdia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 gcdx64.efi
-rwx------. 1 root root 159 20. Sep 18:03 grub.cfg
-rwx------. 1 root root 6699 3. Okt 2020 grub.cfg.bak
-rwx------. 1 root root 7414 6. Nov 2022 grub.cfg.rpmsave
-rwx------. 1 root root 1024 3. Okt 2020 grubenv.bak
-rwx------. 1 root root 1024 4. Apr 19:08 grubenv.rpmsave
-rwx------. 1 root root 2960704 12. Apr 01:00 grubia32.efi
-rwx------. 1 root root 3972416 12. Apr 01:00 grubx64.efi
-rwx------. 1 root root 673992 19. Mär 2024 mmia32.efi
-rwx------. 1 root root 848080 19. Mär 2024 mmx64.efi
-rwx------. 1 root root 949424 19. Mär 2024 shim.efi
-rwx------. 1 root root 747681 19. Mär 2024 shimia32.efi
-rwx------. 1 root root 949424 19. Mär 2024 shimx64.efi

Achtet mal auf die Größe der grub.cfg : 159 Bytes

Das steht drin:

# cat /boot/efi/EFI/fedora/grub.cfg
search –no-floppy –root-dev-only –fs-uuid –set=dev 0669a2db-8ba9-4054-a629-cd7cf2eb12c8
set prefix=($dev)/grub2
export $prefix
configfile $prefix/grub.cfg

Man hat also endlich nur noch einen Ort für die Grub.cfg nämlich /boot/grub2/grub.cfg . Die im EFI Ordner ist jetzt nur noch ein Wrapper, der die eigentliche grub.cfg einbindet, so muß man nur noch eine erzeugen und bleibt rückwärtskompatibel, außer, man hatte das Problem selbst bereits gelöst, dann landete man in der GRUB-Shell, weil …

Wenn die GRUB-Config gebaut wird, wird zuerst der kurze Wrapper /boot/efi/EFI/fedora/grub.cfg erzeugt, DANN erst die /boot/grub2/grub.cfg geschrieben.

Wenn aber /boot/grub2/grub.cfg ein LINK auf /boot/efi/EFI/fedora/grub.cfg ist, dann wird die kurze Fassung durch die Hauptkonfig ersetzt und nagelt dabei den Prefix für das Bootdevice weg. Als Folge kann Grub die Bootpartition nicht mehr finden und bootet nicht mehr.

Lösung:

rm -f /boot/grub2/grub.cfg /boot/grub2/grubenv
grub2-mkconfig > /boot/grub2/grub.cfg
grub2-install –force –target=x86_64-efi /dev/nvme0n1 ( in meinem Fall)

Danach war /boot/efi/EFI/fedora/grub.cfg wieder normal und das System hat endlich wieder gebootet.

Dank nochmal an alle die gestern Abend bei Linux am Dienstag geholfen haben, das war knifflig, aber genau dafür machen wir diese Videokonferenz: Linux basteln 😀

Wie man von einer nachgerüsteten NVME SSD bootet

Meine langjährige Linux-Notlösung ging letzte Woche eine innige Verbindung zwischen Mainboard und Netzteil ein, das führte leider zu neuer PC-Hardware, wovon Ihr jetzt allerdings profitiert 😉

Wie man von einer nachgerüsteten NVME SSD bootet

Hier eine Impression der neuen permanenten Verbindung zwischen Mainboard und Netzteil:

ATX 12V Leitung ins Mainboard

Nur mit Gewalt konnten Buchse und Stecker getrennt werden. Eine Inspektion ergab dann, daß drei Spannungswandler, die befinden sich unter dem Kühlkörper links im Bild, ein bisschen zu warm geworden sind.

Hinweis: Für alle Linux am Dienstag Teilnehmer, abweichend zum gestrigen Textchat, gibt es bei den Anweisungen für die UUIDs noch eine kleine Erweiterung wo man die ersetzen muß.

Der neue RYZEN 5600X

Weil ich mir gleich was vernünftiges kaufen wollte, kam ein ASROCK B550µ Pro4 und ein RYZEN 5600X in den Warenkorb, noch NVME SSD (Samsung 1TB), RAM und Netzteil dazu gepackt und beim Großhändler sammeln lassen.

Das Board kannte ich einem früheren Einkauf und entsprechend wußte ich, daß diese Hardware mit Linux  laufen würde. Laufen ist in dem Fall übrigens glatte Untertreibung, Rennen wäre treffender, weil die NVME SSD in dem Setup 7 GB/s lesend schafft 😀

Da ich den PC für die Arbeit brauchte, war ein funktionierendes System an Tag 1 erst einmal wichtiger, als von der NVME SSD booten zu können, also wurde die HW nur zusammen gesteckt und die alte SATA SSD gebootet. Lief sofort ohne zu murren. Der Arbeitstag neigte sich dem Ende zu, also war es Zeit die SATA SSD auf die NVME SSD zu clonen und die Umstellung zu machen.

Nun ist mein Fedora System von 2014 und dessen Bootconfig weiß noch nichts von NVME. Also muß man das erst nachrüsten und ein Initramfs bauen, daß auch passende NVME Treiber hat. Dummerweise wusste ich das nicht, als die ich die SSD geclont habe 🙁 Ergebnis: „Geil, bootet von NVME .. ähhhhhh!?!?!“ Weil der Bootprozess vor dem Entschlüsseln der LUKS Paritionen einfach stehen blieb.

Zwei Möglichkeiten

Entweder VOR dem Clonen das neue Initramfs bauen, was deutlich einfacher ist, oder nochmal von der alten SSD Booten, Initramfs neubauen und die erzeugten Files von Hand rüberkopieren.

So, oder so, sieht der richtige Weg so aus:

  1. NVME-Treiber hinzufügen

    echo „add_drivers+= \“ nvme \““ > /etc/dracut.conf.d/nvme.conf
    # initramfs für aktiven Kernel neubauen
    dracut -f
  2. Disk Clonen

booten von einem Livestick
sudo su
dd if=/dev/quelle of=/dev/nvme0n1 bs=64M status=progress

Bei einer 1 TB SSD dauert das so 21-23 Minuten, da die SATA Geräte auf den meisten PCs mit 6 Gb/s angebunden sind, was ein theoretisches Maximum von 512 MB/s erlauben würde, aber 480 MB/s sind realistischer 😉

Wenn man die alte Platte nicht mehr benutzen will ist hier Schluß, die Platte muß dann aber auch gleich vom PC entfernt oder neu formatiert werden. Wieso, wird gleich klar werden.

Oder Ihr wollt mal wissen, was der Onkel Doktor machen müßte um die neue NVME SSD parallel zur alten SATA SSD booten zu können 🙂 Wir haben die Platte geclont und damit auch alle UUIDs zur identifizierung von Partitionen und Containern. UUIDs zeichnen sich durch eine gewisse EINMALIGKEIT aus, sprich, doppelte UUIDs produzieren lustige Fehler beim Bootprozess 😀

Gestern beim Linux am Dienstag kam die Frage auf, wieso ich nach dem Clonen nicht einfach die SATA SSD platt gemacht habe: Redundanz. Fällt die NVME SSD aus, habe ich noch ein System, das garantiert bootet.

Wie man die UUIDs von LUKS und EXTx ändert

Der Einfachheit

halber nehmen wir das „Gnome-Laufwerke“ Tool zur Hand um die alten UUIDs zuermitteln, da wir da visuell sehen können, ob das auch die richtige Partition ist. Man kann das auch in der Konsole ablesen, aber das kann leicht zu Verwechselungen führen:

$ lsblk -t -f
NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
nvme0n1 0 512 0 512 512 0 none 1023 128 0B 
├─nvme0n1p1 0 512 0 512 512 0 none 1023 128 0B ext4 1.0 Boot 4d2061ec-d538-4c88-aeb7-3fb0f3f4cd07 234,6M 46% /boot
├─nvme0n1p2 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 9d2595b2-a35c-48c1-a839-bb54c1a96597 
│ └─luks-9d2595b2-a35c-48c1-a839-bb54c1a96597 0 512 0 512 512 0 128 128 0B ext4 1.0 9d2595b2-a35c-48c1-a839-bb54c1a96597 659,9G 22% /
└─nvme0n1p3 0 512 0 512 512 0 none 1023 128 0B crypto_LUKS 1 ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 
  └─luks-ed009ed3-118c-465d-9b89-9b2a4f5cc3f3 0 512 0 512 512 0 128 128 0B swap 1 46da0d80-21fb-45b7-8567-ba047de66cb6 [SWAP]

Einfacher ist das über das GNOME Laufwerke Tool:

LUKS

Filesystem in eine LUKS Container

Schritt 1 wäre jetzt auch erst einmal neue UUIDs zu erzeugen, was unter Fedora leicht mit dem Befehl „uuidgen“ gemacht werden kann. Andere Distro haben den Befehl nur als „uuid“ im Angebot.

WARNUNG:
Die hier gezeigten Anweisungen können in den falschen Händen Schaden an Ihrem System anrichten, deswegen erfolgt alles, was Sie jetzt machen auf eigene Gefahr!

WICHTIG: Bei Verwendung von LUKS darauf achten, daß die LUKS-Partition und die darin enthaltene Partition die gleiche UUID haben!

HINWEIS: der Befehl „replace“ wird von MYSQL/MARIADB zur Verfügung gestellt! Man kann die Anpassungen auch mit einem Texteditor machen, sollte man aber zwecks Reduzierung von Fehlerqellen nicht machen.

Alternativ könnte man sed -e „s/ALTE UUID/NEUE UUID/g“ < file >file.1; mv file.1 file machen, aber dann läuft man Gefahr die Rechte und Besitzer zu ändern.

Alles was wir jetzt machen, findet auf einer LIVE DISK statt, also im ungebooteten Zustand. Die Filesysteme sind alle EXT4, für abweichende Filesystem müßt Ihr Euch selbst was ausdenken 😉

Los geht’s :

A) Die Bootpartition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p1
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p1 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

*f) Partionen wieder abmelden

*) Das Abmelden ist natürlich optional, wenn Ihr mehrere Ersetzungen machen müßte, dann können die natürlich gemountet bleiben 😉

B) jede andere Partition

Jenachdem wieviele man hat, kann man das auch alles zusammen machen!

Wichtig: Jede Partition hat ihre eigene UUID, doppelte darf es nicht geben!

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) tune2fs /dev/nvme0n1p2 -U „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Das waren die Filesysteme, kommen wir zu den LUKS Containern. Wer kein Luks hat, der ist jetzt natürlich fertig 🙂

Bei LUKS Partitionen ist das Vorgehen im Prinzip das Gleiche, nur die Befehle sind andere, weil LUKS kein Filesystem ist, aber eins zur Verfügung stellt nach dem Aufschliessen.

C) Für jede LUKS Partition

a) mit „Laufwerke“ das Gerät identifizieren: z.B. /dev/nvme0n1p2
b) ALTE UUID ermitteln ( wegkopieren in Texteditor ! )
c) cryptsetup luksUUID /dev/nvme0n1p2 –uuid „NEUE UUID“
d) BOOT + SYSTEM Partion der NVME anmelden
e) UUIDs ersetzen:
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/grub2/grub*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/boot/loader/entries/*
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/fstab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/crypttab
replace „ALTE UUID“ „NEUE UUID“ — pfad/zu/System/etc/default/grub

f) Partionen wieder abmelden

Damit wären wir durch und so schlimm war es dann ja auch wieder nicht 🙂

Update: Es wurden Bilder zum Gnome-Laufwerke Tool eingebaut, powered by FlameShot – Ihrem Screenshottool

Pinephone: Fedora Minimal Image z.Z. nicht updaten

Seit einigen Tagen gibt es ein Problem mit dem Pinephone Fedora Minimalimage. Wenn es auf den letzten Stand aktualisiert wird, bootet das Pinephone nicht mehr.

UPDATE: Wer ab 7.4. ca. 20:00 Uhr MESZ updated, der kann wieder ohne Hemmungen updaten. Ich hab das Problem für Euch untersucht und gelöst bekommen 😉 Es war so ein !*ARGS*! Moment 😉 hat jeder mal 😀

Pinephone: Fedora Minimal Image z.Z. nicht updaten

Wenn Ihr noch nicht aktualisiert habt, dann tragt das hier in die /etc/dnf/dnf.conf ein:

exclude=megi-kernel pp-uboot

Danach kann man erst einmal wieder updaten. Falls es für Euch schon zu spät ist, habt Ihr drei Möglichkeiten:

    1. Solange das Pine noch keinen Reboot gemacht hat, könnt Ihr einfach die Pakete downgraden:dnf downgrade megi-kernel-5.12.0-3und dann nehmt Ihr die Pakete oben von weiteren Updates einfach aus.
    2. Das Minimal Image einfach neu installieren, updaten, dann Schritt 1 oben machen und dann megi-kernel von den Updates ausnehmen.
    3. Fedora Workstation Image auf die SDCard schreiben, das booten.
      Ein Terminal aufmachen.
      mount /dev/mmcblk2p2 /mnt/
      chroot /mnt/
      dnf downgrade megi-kernel-5.12.0-3
      exit
      umount /mnt
      reboot

Wobei man natürlich auf dem Workstation Image erstmal das WLAN aktivieren muß, sonst kann man die Pakete nicht laden 😉 Je nach dem wieviel Zeit vergangen ist seit ich den Artikel für Euch geschrieben haben und Ihre das Problem lösen wollte, könnte ein Downgrade nicht mehr nötig sein, sondern ein Update stattdessen die bessere Idee sein.

Da das Problem derzeit im Team besprochen wird, sollte bald ein megi-kernel Paket existieren, daß das Problem löst und die neue gewünschte Funktion hat, die das Ungemach überhaupt erst ausgelöst habt 😉

In jedem Fall ist ein Workstation Image ( ftp://pine.warpspeed.dk/nightly/pinephone/minimal-2021-04-05-test.img.xz ) auf einer SDCard im Pinephone keine so schlechte Idee, weil man dann schnell solche Fehler beheben kann und trotzdem von der EMMC bootet kann, weil es das hier gibt:

Ein ständiges Wechseln der SDCard ist so nämlich nicht mehr nötig. Der Dank geht auch hier an Megi, es war seine ( hoffentlich richtiges Pronomen ) Idee.