Ein Server startet nicht mehr, es kommen „apparmor“-Fehlermeldungen und der Hinweis „give root password“, um in den „maintenance“ mode zu kommen.
Manchmal reichte es, das „root“-Passwort einzugeben, dann „exit“ einzugeben und das System startete durch.
Nicht so hier.
Sehr ärgerlich.
Also habe ich einmal recherchiert, wie eigentlich das Zusammenspiel von „apparmor“ und „systemd“ ist.
Meine These ist schon seit langem, daß „systemd“ dem „stabilen“ Linux-System früher oder später das Kreuz bricht. Deshalb bin ich ein Verfechter von „systemd-freien“ Distributionen. Meine Kritikpunkte sind immer die gleichen: Systemstart und System-Herunterfahren unter „systemd“ ist schwierig zu debuggen.
Linux-Server müssen absolut stabil laufen. Die „letzten“ Features interessieren mich nicht. Den Kunden interessieren sie auch nicht, für den müssen die laufenden Wartungskosten niedrig sein.
Der Kunde ist sauer: Der Server steht.
Nach einer ersten Diagnose scheint es nicht – oder nicht unmittelbar – an „systemd“ zu liegen, sondern an der Numerierung der Laufwerke. Es gibt ein Problem mit „sda3“. Der Server hat eine interne Festplatte und eine USB-Festplatte, die beide ein „RAID“ bilden. Und offenbar gibt es ein Problem bei der Numerierung der Laufwerke. Einmal ist „sda“ das interne Laufwerk und einmal das USB-Laufwerke.
Fakt ist, „sda3“ gibt es nicht, aber „sdb3“ – und das soll laut „fstab“ als „/boot“ eingebunden werden.
Evtl. wurde nur noch mit „UUID“ getestet und in einem neueren Kernel (etwas andere kann ich mir noch nicht vorstellen) die Numerierungssystematik geändert.
Nach fünf Neustarts ging es dann – „sda3“ war wieder „sda3“.
Mehr zur eigentlichen Ursache evtl. später, wenn der Kunde die Diagnostik bezahlen möchte.