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 😀