[solved] "Unable to mount root" trotz gleicher Kernelkonfig

[schmidicom]

Ich habe bei einem etwas älteren Server ein Kernelupdate von 3.13.5 zu 3.13.7 gemacht (an der Konfig hat sich nichts geändert) und jetzt wird mir der wohl berühmteste Kernelpanic um die Ohren gehauen den es gibt.

[ChrisJumper]

Der alte Kernel bootet aber noch oder? Ich würde alles einzeln zusammen setzen.

Angefangen von einem make clean und neu kompilieren und kopieren auf /boot, sync und aushängen. Bis zu einem neuen Kernel ohne alte .config die dann noch einmal neu eingerichtet wird. Zumindest hat mir das letzte mit der Neueinrichtung immer geholfen bei dem Problem. Gefühlt stieg die Fehleranfälligkeit dafür im letzten Jahr, auch wenn die Kernel nur kleine Sprünge verzeichnet hatten. Also das ein make oldconfig aus migrierten Konfigurationsdateien nicht mehr geklappt hat.

Edit: Aber ich hänge auch noch bei einem 3.10.x Kernel, wird mal wieder Zeit für ein Update bei mir..

[arfe]

Es stellt sich die Frage welche Schritte er unternommen hat, um den neuen Kernel zu kompilieren...
Mit seinen Informationen kann man erst Mal gar nichts wissen welchen Fehler schmidicom gemacht hat.

[ChrisJumper]

Das stimmt. Aber er hat geschrieben an der Konfig hat sich nichts geändert was, die Wahrscheinlichkeit nahe legt das er sie einfach in das neue Verzeichnis kopierte und dann kompilierte. Oder vielleicht noch make oldconfig aufrief. Genau das selbe Problem hatte ich dann auch. Sowohl ohne als auch mit make oldconfig. Aus empirischer Erkenntnis heraus habe ich diesen Ratschlag gegeben. Da half nur eine Konfiguration nach einer "leeren" .config Datei und von vorne anzufangen.

[arfe]

Er kann den alten Kernel noch mal laden und folgendes machen:

zcat /proc/config.gz > .config

dann er hat seine alte Kernel Config wieder.

[schmidicom]

@ChrisJumper
Bis jetzt dachte ich immer man könnte sich auf "make oldconfig" verlassen aber wenn du damit schon schlechte Erfahrungen gemacht hast dann werde ich mal versuchen den neuen Kernel aus dem Gedächtnis heraus neu zu konfigurieren, was nicht sonderlich schwer für mich ist da ich inzwischen mit fast jeder Option per du bin.
Aber da der Server in der Firma steht und jetzt Wochenende ist muss dieses Vorhaben bis Montag warten.

@arfe
Diesen Unterton in deinen Kommentaren kannst du dir echt sparen. Ich bin erfahren genug um zu wissen das man eine alte Kernelkonfiguration normalerweise vorher mit "make oldconfig" importiert und erst dann den Kernel baut.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[ulenrich]

[arfe]

[SkaaliaN]

Muss man solche Sandkastendiskussionen eigentlich immer im öffentlichen Forum führen?
Für sowas kann man, wenn man es fürs Ego braucht, auch die PM nutzen!
_________________
c'ya !
skaalian

[schmidicom]

@ulenrich
Sorry das ich mich erst jetzt melde aber das ist wieder mal so ein typischer Montag wie man ihn kennt aber nicht unbedingt lieben muss.
Hier das von dir gewünschte diff nach dem importieren der alten Konfiguration:

[ChrisJumper]

[schmidicom]

Der SCSI-Treiber (CONFIG_FUSION_SPI) ist sowohl beim Vorgänger (3.13.5) als auch beim Nachfolger (3.13.7) fest mit drin. Ich kann mir das ganze, wie du selbst auch schon angemerkt hast, nur so erklären das beim Wechsel von 3.13.5 zu 3.13.7 irgendwo eine Abhängigkeit dazugekommen ist die von "make oldconfig" nicht sauber erkannt wurde oder das der Treiber für die SCSI-Karte eventuell einen Fehler drin hat.

Aber egal morgen steht die Konfiguration von Kernel 3.14 an und bei einem solchen Wechsel benutze ich nie "make oldconfig" sondern mache alles aus dem Gedächtnis neu.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[arfe]

[schmidicom]

So inzwischen kenne ich nun den Grund für diesen Fehler, hier die Details:

Der Server hat ja neben der SCSI-Karte selbstverständlich auch einen eigenen SATA-Controller auf dem Mainboard und für beide Geräte war das passende Modul fest im Kernel mit drin. Was bis vor kurzem auch nie ein Problem war da der Kernel immer die Initialisierungsreihenfolge übernahm welche im BIOS eingestellt wurde. Aber irgendwo zwischen 3.13.5 und 3.13.7 muss etwas passiert sein was dazu führte das die Reihefolge sich geändert hat wodurch sda1 (ext4) und sdb1 (btrfs) die Plätze tauschten und der Kernel nicht mehr in der Lage war die angegebene Partition zu mounten.

Als kurzfristige Lösung habe ich den Treiber für den onboard SATA-Controller als Modul hinterlegt wodurch die SCSI-Karte in jedem Fall zuerst zur Verfügung steht und deren Datenträger als sdaX daher kommen, aber langfristig werde ich mir was anderes ausdenken müssen. Wirklich schade das der Kernel ohne ein entsprechendes initrd nicht mit solchen Angaben wie "root=/dev/disk/by-label/XYZ" umgehen kann, das würde einiges einfacher machen.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[arfe]

D.h. auch richtig rootfstype und root und nicht nur root!

[schmidicom]

Zur allgemeinen Info die endgültige Lösung [1] für mein Problem steht nun auch in den Startlöchern aber getestet wird das erst beim nächsten Kernelupdate.

[1] Habe mir ein kleines BusyBox-Script zugelegt das über ein initrd geladen werden soll und wenn alles nach Plan läuft kann ich damit die root Partition über eine UUID mounten.
Falls sich das ding einer ansehen will hier der Link dazu: https://shschmid.dyndns.ch/owncloud/public.php?service=files&t=7703cc4f5f81ffeaf2ed9db31eb44df0

EDIT: URL hat sich geändert.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[firefly]

[schmidicom]

Stimmt das mit der GPT wäre eigentlich eine noch viel bessere Lösung, dann kann ich auch weiterhin einen Kernel ohne initrd benutzen. Allerdings werde ich für diese Umstellung eine etwas längere Ausfallzeit einplanen müssen, mal sehen wann ich das machen kann.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[l3u]

[bell]

Es gibt auch die Möglichkeit eine Initramfs fest in den Kernel einzukompilieren. So als Hinweis. Udev in der initramfs benötigst Du nicht. Der busybox-mdev tut es auch. Wird zB. in der Genkernels-Initramfs verwendet.

[schmidicom]

@l3u
So ganz einverstanden bin ich damit jetzt aber auch nicht.
Die Funktion ein Device anhand eines bestimmten Identifikationsmerkmal selbständig zu ermitteln ist im Kernel ja bereits enthalten denn sonst würde bei einer GPT der Kernelparamter "root=PARTUUID=<your partition UUID>" ja nicht funktionieren. Also glaube ich wäre es für die Kernel-Entwickler kaum allzu schwer diese Funktion so zu erweitern das sie auch mit der UUID oder sogar dem LABEL einer normalen Partition funktionieren würde.

Aber egal, die verlinkte Anleitung für ein initrd ist ziemlich interessant. Es fehlt eigentlich nur noch der Hinweis wie man den Kernel dazu bringt dieses initrd als temporäres root zu laden. In der Doku vom Kernel seht was von "root=/dev/ram0 rw" aber in meiner kleinen Testumgebung hat das bis jetzt noch nicht funktioniert.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW

[py-ro]

Wenn der Kernel eine Initrd übergeben bekommt, ist das immer sein root sofern dazu verwendbar.

Der Unterschied zwischen PARTUUID und UUID/LABEL ist, dass diese Information trivial erlangbar ist, bzw. automatisch beim parsen der Partitionstabelle anfällt. Die UUID/LABEL stehen aber im Filesystem und das je nach Filesystem auch noch an verschiedenen Stellen. Da dies genauso gut im Userspace umgesetzt werden kann, werden die Kernel Entwickler diesen Code nicht in den Kernel aufnehmen.

Bye
Py

[bell]

Mal ein Schritt zurück.

[l3u]

[py-ro]

@l3u schlechter Tipp

Das hängt lediglich die initramfs direkt an das Kernel Image dran, für jede Änderung muss er das dann neu erzeugen.