Fedora 30&31 Bootumstellung führt zu Startproblem

Eigentlich wollte ich was von Endlosschleifen sagen, aber das trifft es nicht, auch wenn eine Schleife als Folge möglich ist. Neulich habe ich auf Fedora 30 Updaten müssen, dabei gab es eine Reihe von Pannen, bei deren Lösung Ihr ab sofort hier nachschlagen könnt.

Die Umstellung auf BLS

Schuld ist die BLS Umstellung in Grub, die zu einigen Verwirrungen und Irrungen geführt hat. Natürlich hat das Suchen mal wieder deutlich mehr Zeit in Anspruch genommen, als das Beheben des resultierenden Problems. Wer rechnet schon mit einer bis Dato unbekannten Bootmichtodschleife? Zugegeben, in meinem Spezialfall war es mehr Tod als Schleife, aber ohne viel Fantasie kann man auch eine Schleife damit bauen.

Die BootLoader Specification kurz BLS kann man an einem passenden Eintrag in der /etc/defult/grub erkennen:

# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT=“gfxterm“
GRUB_ENABLE_BLSCFG=true

Ich hab ein bisschen was weggelassen, damit es leserlicher wird. Wenn BLS aktiv ist, habt Ihr die Booteinträge nicht mehr in der grub2.cfg stehen, sondern hier:

# ls -la /boot/loader/entries/
insgesamt 16
4 -rw-r–r–. 1 root root 379 28. Nov 00:19 7e390913b33b4e5ba8f960a9ba97aeee-0-rescue.conf
4 -rw-r–r–. 1 root root 249 22. Nov 00:15 7e390913b33b4e5ba8f960a9ba97aeee-5.3.12-200.fc30.x86_64.conf
4 -rw-r–r–. 1 root root 249 26. Nov 00:28 7e390913b33b4e5ba8f960a9ba97aeee-5.3.13-200.fc30.x86_64.conf
4 -rw-r–r–. 1 root root 249 2. Dez 17:22 7e390913b33b4e5ba8f960a9ba97aeee-5.3.14-200.fc30.x86_64.conf

Diese Änderung unterstütze ich voll und ganz, da muß man keine unnötigen rebuilds der grub.cfg machen. Einfach neues File rein, oder altes raus. Fertig. Soweit, so gut.

Die Probleme zeigen sich jetzt bei diesem Punkt: „/etc/grub.d/08_fallback_counting“  Da wird mitgezählt, ob wir einen funktionierenden Boot hatten, oder nicht. Wenn der Rechner z.b. beim Boot nicht hochkommt, wird automatisch ein anderer Kernel benutzt, als zuletzt zum Booten eingestellt war. Im Idealfall behebt sich ein Bootproblem somit von allein.

An sich wäre das ok, wenn genau dieser Algorithmus auch sauber funktionieren würde, tut er aber nicht.

Prämisse: Der Rechner bootet nicht durch, Ihr wählt im Kernelmenü einen anderen Kernel aus.

Wenn man den 08-Fallbackcode liest, stellt man fest, daß im Fall der Erkennung des „nicht sauber gebootet“ Zustands, die Auswahl des Kernels, die man selbst gemacht hat, mit dem Defaultwert 1 überschrieben wird. „1“ meint hier den Kernel-Index 1, also den Kernel an Position 2 in der Liste!

insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "\${boot_counter}" -a "\${boot_success}" = "0" ]; then
   # if countdown has ended, choose to boot rollback deployment,
   # i.e. default=1 on OSTree-based systems.
   if [ "\${boot_counter}" = "0" -o "\${boot_counter}" = "-1" ]; then
      set default=1
      set boot_counter=-1
      # otherwise decrement boot_counter
   else
      decrement boot_counter
   fi
   save_env boot_counter
fi

Und bei der „set default=1“ Zeile liegt das Problem, denn was da Index 1 ist als Kernel, ist nicht definiert.

Das Fallbackproblem ist auch dann wirksam, wenn man kein BLS aktiv hat. In diesem Fall läßt es sich besser nachvollziehen, deswegen setzen ich das jetzt mal voraus. Die grub.cfg könnte dann so aussehen:

### BEGIN /etc/grub.d/08_fallback_counting ###
insmod increment
# Check if boot_counter exists and boot_success=0 to activate this behaviour.
if [ -n "${boot_counter}" -a "${boot_success}" = "0" ]; then
  # if countdown has ended, choose to boot rollback deployment,
  # i.e. default=1 on OSTree-based systems.
  if  [ "${boot_counter}" = "0" -o "${boot_counter}" = "-1" ]; then
    set default=1
    set boot_counter=-1
  # otherwise decrement boot_counter
  else
    decrement boot_counter
  fi
  save_env boot_counter
fi
### END /etc/grub.d/08_fallback_counting ###

BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (5.3.14-200.fc30.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.3.14-200.fc30.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}
menuentry 'Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.3.13-200.fc30.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}
menuentry 'Fedora (5.0.17-200.fc29.x86_64) 30 (Thirty)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-5.0.17-200.fc29.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
...
}

Das ergibt :

Kernel-Index=0 => „5.3.14-200.fc30.x86_64“
Kernel-Index=1 => „5.3.13-200.fc30.x86_64“
Kernel-Index=2 => „5.0.17-200.fc29.x86_64“

Merke, in dem Fallback steht 1 als Fallbackoption drin.

Das Xen Problem

Wenn jetzt die neueren Kernels von Fc30 nicht bootet, weil die z.b. in einer XenUmgebung laufen, wo ein alter pyGrub Bootloader am werkeln ist, dann funktioniert der Boot nicht. d.b. der nächste Boot funktioniert auch nicht, weil die Fallbackoption auf einen Kernel zurückgreift, der auch nicht funktioniert.

Wenn man jetzt in der grubenv den Kernel-Index=2 ausgesucht hat, z.b. so „saved_entry=Fedora (5.0.17-200.fc29.x86_64) 30 (Thirty)„, dann wird dies wie oben beschrieben ignoriert, weil der FallBackcode nach dem Defaultkernelcode in der Grub.cfg kommt.

Ihr könnt auch tausendmal auswählen, daß Ihr den Kernel haben wollt, ist egal, wird auch überschrieben.

Die Lösung

Da hilft nur eine Aktion: „set default=2“ in die grub.cfg schreiben. Das wird natürlich beim nächsten Kernelinstall übergenagelt, aber a) könnt Ihr das auch in der /etc/grub.d/08-…. anpassen, dann bleibt es erhalten und b) in obiger Prämisse rebootet Ihr eh nicht 😉 hauptsache das System kommt überhaupt hoch.

Jetzt muß keiner glauben, daß das Problem unbekannt wäre, es gibt Bugreports dazu von Fedora 30 Tage 1 an. Weil das Problem für Xen als Bugreport bekannt war, wurde die Upgraderoutine so umgeschrieben, daß BLS deaktiviert ist, wenn Xen als Host gefunden wird. Das alleine schützt aber nicht vor dem Fallbackproblem.

Grubby

Das nächste Problem: grubby. Grubby ist das kleine Shelltool, daß die Grubenv erzeugt, wenn z.b. sagt, welchen Kernel man als Default haben will, Ihr erinnert euch: Grubby: wie man wieder einen Default Kernel setzen kann.

Tja leider ist Grubby wohl nicht ganz mitgekommen und schreibt BLS Kernelinformationen in die grubenv, auch wenn BLS abgeschaltet ist. Da könnt Ihr nur von Hand eingreifen und die grubenv manuell beheben. Aber achtet auf die 1024 Zeichenlänge der grubenv, die muß erhalten bleiben!

Kleines Update:

Wenn man jetzt so danach googelt, findet man jede Menge Hinweise, daß bei dem Upgradeprozess etwas schief gehen wird. Ich komme mehr und mehr zu dem Schluß, daß es eine ganz schlecht geplante Aktion war.

Anstelle von Grubby für den Kerneleintrag zubenutzen, kann man auch folgendes machen:

grub2-editenv /boot/grub2/grubenv set „saved_entry=Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)“

Natürlich mit dem Kerneleintrag den Ihr wollt 😉

Wie kommt man an diese Bezeichnung?

grep ^menuentry /boot/grub2/grub.cfg | cut -d „‚“ -f2

kommt dies bei raus:

Fedora (5.3.15-200.fc30.x86_64) 30 (Thirty)
Fedora (5.3.14-200.fc30.x86_64) 30 (Thirty)
Fedora (5.3.13-200.fc30.x86_64) 30 (Thirty)
Fedora (0-rescue-9aa92939e4c644e6aa3e09cc4c2311e8) 30 (Thirty)

Jetzt braucht Ihr den Titel nur noch zu kopieren und an den grub2-editenv zu übergeben.

Update: Fedora 29 bootet nicht nach Upgrade

Kleines Follow-Up auf Warnung: Libreswan kann Ihren Bootprozess stören. Nachdem der Rechner gestern wieder lief, wie man im Beitrag auch nachlesen kann, dachte ich mir, probier das System mal mit allen wichtigen Sachen aus. Keine Fehler, die nicht zu erwarten gewesen wären. Mehrfaches Rebooten lief auch ohne Probleme durch, bis… ja, bis heute morgen.

„Der Morgen danach“ Ein Roman von B.Soffski

Der Reihe nach: Wir verließen unseren Helden, als er sich zur Nachtruhe zurückzog und den Rechner ausschaltete. Ja, ausschaltete. Die Art von Ausschalten, die Veränderungen an so einem Computer unmöglich macht. Die Art, wo das Wort stromlos drin vorkommt. Wir erinnern uns, daß der Computer vor diesem Ausschalten 3x neu gestartet wurde, nur um zu sehen, ob das mit dem Reboot auch wirklich klappt.

„Der Vormittag kam, sah und ihm klappten alle Regentropfen runter!“

Anders ausgedrückt, dieses Fedora 29 bootet schon wieder nicht. Es blieb „wieder“ beim NetworkManagereinsatz hängen 🙁 Das kann einfach nicht wahr sein, der hat doch gestern 3x neu gebootet, wie kann das sein?

„Karma is a Bitch“ ein Buch von L.Eben

Na gut. „Challenge accepted“ Eine gewisse Wut im Bauch ist ja nicht wirklich falsch bei so was, es spornt den Wüterich zu Leistungen an. Was machen? Das gleiche wie Gestern? Einen Versuch ist es wert, aber diesmal nicht in eine Rootshell booten, sondern in Runlevel 1 auch bekannt als Emergency.target von Systemd. Ja, also an sich eine gute Idee, NUR GEHTS NICHT! Was für eine verf******* S******* ist das denn?

Ok, also dem Kernel wieder erzählt „1 init=/bin/bash“, Netzwerk gestartet, dnf update und siehe, wieder ein Update. Aber total irrelevant. Das wars also nicht. /var/log/messages und systemd-journal gesichtet, nichts. Der Bootvorgang ging bis NetworkManager, aber das wars dann. Nicht mal mehr ein Crash, der etwas erklären könnte. Nada!

Auf Verdacht wurde dann „dnf reinstall NetworkManager* systemd*“ durchgeführt und “ systemd.debug-level=1 “ an die Kernelzeile angefügt, damit eine Rootshell bereitsteht, wenn man sie braucht ( ALT+F9 )  und was soll ich sagen, der Rechner bootete wieder in GDM. Was fürn Sch….. was ist das denn? Man kann nicht mehr in den Desktop einloggen ?!?!?! Root-Konsole mit ALT+F3 ( F9 hatte ich im Moment vergessen ), will mit Root einloggen und … sofortiger Logout. Und dann stehst Du da!

F9! Stimmt, einloggen nicht nötig, bin ja schon drin, also ab ins Logfile und ..

The Execution of /usr/lib/systemd/systemd resulted in „Permission denied!“

Äh.. den habe ich doch gerade erst frisch reinstalliert und wieso wird der beim Konsolenlogin aufgerufen?Wird er gar nicht, weil /bin/sh konnte man auch nicht mehr starten, gleicher Fehler „Permission denied!“  … und wenn Du jetzt F*** sagst, sag auch gleich SELINUX! NNNNNNEEEEEEEIIIIIINNNNNNNNNNNN!!!!!!!!!!!!! Nicht schon wieder SELinux! Ich fange an es zu hassen !

Einen Reboot mit dem Kernelparameter „enforcing=0“ später, fährt das System hoch, als wenn nie was gewesen wäre!

Aber was ist jetzt schon wieder mit SELinux und wieso hat das System denn überhaupt nach dem Upgrade gestartet? Das dürfte es doch gar nicht. Antwort: SELinux  ist halt auch nur eine von Menschen gemachte Software 😉

„Die Auflösung“ Ein Film von D.Itrich

Das Problem nahm seinen Lauf im Jahre 2018. Damals gab es ein Problem unter F27 mit den SEL Policies. Nach einem Update der SEL Policypacks startete das System nicht mehr, aber mit der Version davon lief es noch. Also trägt der Linuxer natürlich nach dem Downgrade den Updateinhibiter für das Paket ein und weil alles ein Jahr lang läuft, vergißt man es. Dann kommt das Systemupgrade auf F28 und es läuft auch mit der alten Policy, was blöd ist, weil man so beim Update auf F29 gar nicht mehr an diese Sperre denkt 🙂

Update sperre für die Pakete raus und „dnf update -y“ ausgeführt. Eine Ewigkeit später, weil gleich mal umgelabelt wird, dann die Probe: reboot !  Scheiße, geht!

Ob die Geschichte diesmal zu ende ist, oder ob morgen neuer Ärger auf mich wartet, könnt Ihr leider erst morgen lesen 😉

Linux – Wenn das Bios die NVMe-SSD nicht bootet

Von dem Problem habe ich nur durch Dritte erfahren, konnte es aber leicht lösen.  Stellt Euch mal vor Ihr kauft Euch eine NVMe SSD  und Euer Bios kann die nicht booten, was macht Ihr dann  ?

Das Problem

Es soll Motherboards geben, die zwar einen passenden Port für die NVMe SSD haben, aber leider vergessen haben, daß man ja auch davon booten können müßte. Wenn man jetzt nur so eine NVMe SSD hat, ist man sprichwörtlich gearscht. Falls man nicht vor hat, seinen Rechner per USB Stick zu booten und von der LiveDisk mit der SSD zu spielen, wird das eine sehr frustrierende Neuanschaffung.

Die Idee

Aber halt! Wenn man das System von einem USB Stick booten kann, könnte man dann nicht auch NUR davon booten ohne die Livedisk zu starten ?

Die Lösung

Na ja, vom Prinzip her schon, aber USB-Stick, das muß doch besser gehen. Ja geht es, aber ihr braucht dafür eine normale SSD oder HD, die kann aber ganz winzig sein, Hauptsache 512 MB passen drauf!

Bei der Installation Eures OSes wählt man für /, Swap und /home die neue NVMe SSD aus. Normal partitionieren und formatieren, soweit nichts besonderes.

Die /boot Partition kicken wir jetzt aber nicht auf die NVMe sondern die alte/kleine SSD. Dort wird auch der Bootloader installiert. Linux ist es nämlich völlig egal, wo die Partionen liegen, Hauptsache der Bootloader kann es finden und das kann er ja dann. Problem gelöst.

Sein System auf die neue NVMe umstellen, ohne neu zu installieren

Wie man eine defekte Bootpartition fixen kann, hatte ich schon mal thematisiert, daher setzte ich das Wissen jetzt bei Euch voraus. Wie man unschwer erkennen kann, habe ich hier den Booteintrag in Grub vor mir :

menuentry 'Fedora (4.14.4-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.13.8-100.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd2,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1 221608f2-5914-4619-9ef7-6dfddf233fd4
 else
 search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
 fi
 linux /vmlinuz-4.14.4-200.fc26.x86_64 root=/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa ro rd.driver.blacklist=nouveau modprobe.blacklist=nouveau vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 modprobe.blacklist=nouveau LANG=de_DE.UTF-8
 initrd /initramfs-4.14.4-200.fc26.x86_64.img
}

Ok, meine Systempartition ist vollverschlüsselt, daher habe ich da die LUKS-ID stehen. Auf einem „normalen“ System könnte das so aussehen :

menuentry 'Fedora (4.14.6-200.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.7.10-100.fc23.x86_64-advanced-dca7eea1-687e-476a-a9a0-c41ef0329113' {
 load_video
 set gfxpayload=keep
 insmod gzio
 insmod part_msdos
 insmod ext2
 set root='hd0,msdos1'
 if [ x$feature_platform_search_hint = xy ]; then
 search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' dca7eea1-687e-476a-a9a0-c41ef0329113
 else
 search --no-floppy --fs-uuid --set=root dca7eea1-687e-476a-a9a0-c41ef0329113
 fi
 linux /boot/vmlinuz-4.14.6-200.fc26.x86_64 root=UUID=dca7eea1-687e-476a-a9a0-c41ef0329113 ro rhgb quiet audit=0 LANG=de_DE.UTF-8
 initrd /boot/initramfs-4.14.6-200.fc26.x86_64.img
}

Alles was man machen muß, ist die UUID der Partition zu ändern und schon bootet das System als System von der anderen SSD. Wie bekommt man die jetzt, nachdem man die NVMe SSD partitioniert und formatiert hat ?

UUID ermitteln

# blkid
/dev/xvda1: UUID=“dca7eea1-687e-476a-a9a0-c41ef0329113″ TYPE=“ext4″ PARTUUID=“000af34a-01″
/dev/xvda2: UUID=“262b5659-4c18-4d8b-89e9-d9ba932e77c0″ TYPE=“swap“ PARTUUID=“000af34a-02″
/dev/xvdb: UUID=“65d31ff9-53c9-4e0b-8a52-0a16622c82d9″ TYPE=“ext4″

Mit dem gleichen Befehl bekommt man auch die LUKS ID mitgeteilt, so man denn eine verschlüsselte Luks-Partition hat:

/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID=“46da0d80-21fb-45b7-8567-ba047de66cb6″ TYPE=“swap“
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID=“e62edbbe-a1ae-4242-bca5-1249d6f2df67″ TYPE=“ext4″

(Zwischenfrage aus dem Publikum: Wieso verschlüsselst Du auch SWAP ?  Antwort: Weil in dem ausgelagerten Speicher Klartext steht und man sich andernfalls eine Sicherheitslücke ins Haus holt. )

Natürlich muß man sein System noch ein bisschen pimpen, damit es später nicht wieder von der alten Systempartition auf der „alten SSD“ booten, nur weil der Kernel neu erstellt wurde 😀 Folgende Punkte sind zu manipulieren:

/etc/fstab
/etc/mtab
/etc/default/grup

Also alle alten UUID/LUKS-IDs durch die neuen ersetzen. Das ist ein ganz schöner Schock, wenn man seine neue SSD im Betrieb hat und dann ein paar Tage später der Rechner wieder auf einem alten Stand ist 😀