Ein Recovery System wird geboren

Gestern bei Linux am Dienstag : Recovery ISO Images in Grub einbinden.

Ein Recovery System wird geboren

Gestern Abend konnten wir dank Kanos Hilfe in einem wilden Ritt durch Grub, ein Recovery ISO Image für Fedora in unser Testsystem einbauen, so daß es im GRUB Bootmenü permanent auftaucht, aber nicht auf der Systemplatte hinterlegt ist.

Kommt es zum Bootfail, mal von der totalen Zerstörung der Bootpartition abgesehen, kann über Grub das Recovery ISO Image geladen werden. Ein cleverer Updatemechanismus sorgt dafür, daß es zwar per DNF & RPM installiert werden kann, aber nicht präsent ist, wenn das System läuft. So kann es auch nicht durch unvorsichtige Benutzer oder Software gelöscht werden.

„Wie, nicht auf der Systemplatte hinterlegt?“

Es handelt sich nicht um eine bootbare Partition, das hätte man auch machen können, aber das hat einige Nachteile bei den Updates. Es ist eigentlich nur eine Lagerpartition, auf der das ISO Image draufliegt :

 

nichts besonderes zu sehen, nur ein offener Dateimanager mit dem ISO Image

Dazu gehört ein kleiner Eintrag in der /etc/grub.d:

# cat /etc/grub.d/99_RECOVERY
#!/bin/sh
exec tail -n +3 $0
# Copy into /etc/grub2.d and set chmod +x
menuentry „Fedora-RECOVERY“ –class fedora –class gnu-linux –class gnu –class os {
  insmod ext2
  set isofile=“/RECOVERY.iso
  search -sf $isofile
  loopback loop $isofile
  linux (loop)/boot/x86_64/loader/linux root=live:CDLABEL=Fedora-WS-Live-42 rd.live.image verbose iso-scan/  filename=$isofile quiet rhgb
  initrd (loop)/boot/x86_64/loader/initrd
}

An der Stelle herzlichen Dank an Kano von Kanotix. Er hat die Basis für dieses kleine Script bereitgestellt, der Eintrag selbst ist praktisch mit der LiveBootconfig von der Fedora 42 Livedisk identisch, aber nicht gleich 😉

Dieser GRUB Eintrag durchsucht dank search -sf dateiname alle lesbaren Partitionen nach RECOVERY.iso . Dann wird Grub angewiesen das ISO als Basis zu öffnen und den Kernel daraus nebst initramfs zu benutzen. Das ist ein klein bisschen mehr Aufwand, als wenn die ISO schon auf einem USB Stick ist. Funktioniert aber trotzdem erstaunlich gut.

Hat man das Script eingefügt, muß man es nur noch mit chmod +x  /etc/grub.d/99_RECOVERY ausführbar machen und einmal mit grub2-mkconfig -o /boot/grub2/grub.cfg eine neue Grubconfig gebaut werden.

im Grubmenü sieht das dann so aus:

Im Grubbootmenu sieht man den Fedora Recovery Eintrag

Danach bootet einfach das ISO Image normal durch.

Unser Plan für nächste Woche

Da der Boot- und Updatevorgang geklärt ist, Fedorauser können das nämlich bereits im Linux am Dienstag Repo finden, widmen wir uns nächste Woche dann dem Bau des speziellen Liveimages mit all den Tools, die man für ein Recovery so braucht.

ACHTUNG:

Wer das fedora-recovery RPM aus dem Repo testen will, braucht eine min.  3 GB große Partition namens „RECOVERY“. Das richtige Label ist ganz wichtig, weil das RPM darüber die richtige Partition für die Installation findet. Das Filesystem ist dabei in soweit egal, GRUB muß es nur lesen können. Es kommen also min. alle EXT Filesysteme, BTFS und VFAT in Frage.

Selbst wenn Ihr bei der Partition Mist baut, ist das beim Test nicht tragisch, Ihr habt dann einfach nur ein 2,3 GB ISO File unter /usr/share/recovery liegen, das unnötig Platz frisst 😉

Danach bauen wir Scripts um Probleme automatisch zu fixen

In den Wochen danach werden wir versuchen diverse Bootprobleme automatisch zu erkennen und zu fixen.

Am Ende des Projekts könnte ein automatisches Recovery-System stehen, daß normalen Endbenutzern das System wieder herstellt, wenn die es kaputt gemacht haben. Erfahrene Benutzer finden dann dort die Tools, um Ihre etwas heftigeren Probleme selbst zu beheben.

Wo ist jetzt der Vorteil gegenüber einem LIVEImage auf einem USBStick?

Gegenfrage: Wollt Ihr in der Krise erst noch den USB Stick suchen, dann feststellen, daß Ihr gar nicht wisst wo das Bootmenü vom Bios aktiviert wird um dann festzustellen, daß die Tools komplett veraltet sind?

Eher nicht, oder? 🙂 Außerdem wollen wir ja erreichen, daß der Linuxdesktop noch mehr von Normalen Benutzern akzeptiert wird, da muß ein Reparaturtool natürlich auch sehr einfach zu benutzen sein. Damit schlagen wir definitiv ein neues Kapitel im Fedora Desktop auf. Hoffentlich schließen sich da andere Distros mit an.

Übrigens auch für Serverbetreiber wäre das von Vorteil, weil man dann keine „Rescue CDROMS“ mehr in der VM Wechseln müßte, sondern einfach neu booten, ins GRUBMenü gehen und die Rescue starten. Das geht viel einfacher als in der VM erstmal die Bootreihenfolge zu ändern. Denkbar wäre auch eine PXE Bootumgebung, statt einer Partition, dann nimmt der Vorgang weniger Platz weg.

 

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 😀

Linux am Dienstag – Programm für den 24.9.2024

Diesmal bei Linux am Dienstag bootet ein Linux PC den Kernel nicht mehr. Mal sehen, ob wir rausbekommen, was das ist.

Linux am Dienstag – Programm für den 24.9.2024

u.a. im Programm am 24.9.2024, ab 19 Uhr :

    • Livediagnose – PC zeigt nur noch Grub an
    • Sicherheit – D-LINK Produkte mit Backdoor
    • OpenAI – Wer zuviel wissen will, wird gebannt
    • EU – Google muß Milliardenstrafe doch nicht zahlen
    • Crypto Bros – etliche Tumbler vom Netz genommen

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .