# [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.

```
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8.1)
```

Hier ein "Screenshot": https://shschmid.dyndns.ch/owncloud/public.php?service=files&t=ee9c6307c746a05cb7f6849939729c05

Wenn ich jetzt bei der Kernel-Version einen grösseren Sprung gemacht oder etwas an der Konfig verändert hätte dann könnte ich das ja noch verstehen aber so ist das ganze schon ziemlich merkwürdig. Hoffentlich hat einer von euch eine Idee wie es dazu kommen kann denn mir fehlt gerade jegliche Inspiration.

Zur Info, das System Bootet ab einem externen Hardware-RAID das über folgende SCSI PCI-X Karte an den Rechner angeschlossen ist:

```
# lspci -s 02:08.0 -v

02:08.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 08)

        Subsystem: LSI Logic / Symbios Logic Device 1060

        Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 16

        I/O ports at 2400 [size=256]

        Memory at dd320000 (64-bit, non-prefetchable) [size=128K]

        Memory at dd300000 (64-bit, non-prefetchable) [size=128K]

        [virtual] Expansion ROM at c0000000 [disabled] [size=4M]

        Capabilities: [50] Power Management version 2

        Capabilities: [58] MSI: Enable- Count=1/1 Maskable- 64bit+

        Capabilities: [68] PCI-X non-bridge device

        Kernel driver in use: mptspi
```

```
# parted -l

Modell: transtec T6100S16R1-E (scsi)

Festplatte  /dev/sda:  1999GB

Sektorgröße (logisch/physisch): 512B/512B

Partitionstabelle: msdos

Disk Flags: 

Nummer  Anfang  Ende    Größe   Typ      Dateisystem  Flags

 1      1049kB  1999GB  1999GB  primary  ext4         boot
```

Last edited by schmidicom on Wed Apr 02, 2014 7:02 am; edited 1 time in total

----------

## 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.  :Wink: 

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.

----------

## ulenrich

 *schmidicom wrote:*   

> @ChrisJumper
> 
> Bis jetzt dachte ich immer man könnte sich auf "make oldconfig" verlassen 

 

Darauf muss man sich verlassen können. Es ist ein Bug, wenn es nicht geht. Bitte mal einen "diff" der beiden config Dateien zeigen!

PS: Es wäre nur ein nicht gültiger Bug (für kernel.org), wenn out-of-mainline Kernel.org Tree patches verwendet wurden. Bei Gentoo-sources ist dies der Fall: Bfq! Dann ist es "nur" ein Downstream Gentoo Bug.

----------

## arfe

 *schmidicom wrote:*   

> 
> 
> @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.

 

Nein, ist klar. Dann sieh Dir mal Deine Fragen hier an. Sehr auffällig ist, dass Du Fragen stellst, Du durch lesen einiger manual pages, Dir selbst beantworten könntest.

Und ich bleibe dabei: Ohne die Information welche Schritte Du unternommen hast, wird das hier ein Ratespiel bleiben!

Zu 99,99% bin ich mir sicher, dass der Fehler bei Dir liegt und nicht bei einem Bug.

----------

## SkaaliaN

Muss man solche Sandkastendiskussionen eigentlich immer im öffentlichen Forum führen?   :Rolling Eyes: 

Für sowas kann man, wenn man es fürs Ego braucht, auch die PM nutzen!   :Twisted Evil: 

----------

## 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.  :Wink: 

Hier das von dir gewünschte diff nach dem importieren der alten Konfiguration:

```
lota01 ~ # cd /usr/src/

lota01 src # cp linux-3.13.5/.config linux-3.13.7/

lota01 src # cd linux-3.13.7

lota01 linux-3.13.7 # make oldconfig

  HOSTCC  scripts/basic/fixdep

  HOSTCC  scripts/kconfig/conf.o

  HOSTCC  scripts/kconfig/zconf.tab.o

  HOSTLD  scripts/kconfig/conf

scripts/kconfig/conf --oldconfig Kconfig

#

# configuration written to .config

#

lota01 linux-3.13.7 # cd ..

lota01 src # diff linux-3.13.5/.config linux-3.13.7/.config

3c3

< # Linux/x86 3.13.5 Kernel Configuration

---

> # Linux/x86 3.13.7 Kernel Configuration

lota01 src #
```

Wie man sehen kann ändert "make oldconfig" lediglich die Zeile mit der Kernelversion und sonst nichts.

Zu mehr bin ich heute wegen Zeitmangel schlicht nicht gekommen aber morgen sieht es hoffentlich besser aus, nur scheint inzwischen schon Kernel 3.14 als stable raus gekommen zu sein wodurch sich nun die Frage stellt ob es der Aufwand mit 3.13.7 überhaupt noch Wert ist.

@metal1ty

Vermutlich wäre es besser gewesen diesen beleidigenden Unterton mitsamt Verfasser zu ignorieren aber manchmal muss es eben einfach raus.Last edited by schmidicom on Mon Mar 31, 2014 5:48 pm; edited 1 time in total

----------

## ChrisJumper

```
lota01 linux-3.13.7 # make oldconfig

  HOSTCC  scripts/basic/fixdep

  HOSTCC  scripts/kconfig/conf.o

  HOSTCC  scripts/kconfig/zconf.tab.o

  HOSTLD  scripts/kconfig/conf

scripts/kconfig/conf --oldconfig Kconfig

#

# configuration written to .config

#

lota01 linux-3.13.7 # cd .. 
```

Ah-Ha! Jetzt kann ich mir vorstellen warum ich da mal Probleme hatte. Vielleicht hatte ich den Symlink anders gesetzt oder war nicht im richtigen Verzeichnis. Sofern das make oldconfig wirklich nach  ./.config geschrieben wird. Also eventuell rufe ich so ein Skript aus versehen schon mal aus dem alten Verzeichnis auf.

arfe Hinweis ist schon berechtigt. Aber ich für meinen teil habe einfach nicht so viel Zeit alles nachzulesen und mich damit vertraut zu machen. Aber genau dafür ist doch ein Forum da, damit man wenn es Unstimmigkeiten gibt man in der Community nachfragen kann.

Ganz extrem betrachtet braucht auch niemand Mathematik lernen, könnte sich ja jeder selber errechnen und Beibringen wenn er lediglich mit dem definierten Zahlenraum und Addition/Subtraktion beginnt. Mit einer Gemeinschaft und dem Parallelen Arbeiten am Living-Standard geht es halt schneller. Irgendjemand muss das Wissen ja auch leben oder eine Dokumentation schreiben.

Den Diff-Hinweis werde ich mir merken und das Problem mal genauer beobachten, wenn es bei mir wieder auftritt.

Nebenbei: Hast du den Treiber für die SCSI Karte fest eingebaut oder als Modul?

Grüße, und einen schöneren Dienstag. :)

Off Topic Aber passt wohl auch zum Thema:

Ich habe einen DVB-S Karten Treiber der den Wert der Kernel-Version nicht aus /usr/src/linux ausliest, sondern wohl aus der uname Ausgabe oder vielleicht dem Proc-System. Nachher schaue ich mir das Script mal an. Wirklich raus gefunden wie ich da den neuen Kernel ohne zwei mal Booten setzen kann, habe ich noch nicht. Wenn ich das Modul kompiliere muss ich immer ein mal den Rechner neu gestartet haben und neu kompilieren, damit das make && make install für den neuen Kernel gebaut wird.

----------

## 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.

----------

## arfe

 *schmidicom wrote:*   

> Vermutlich wäre es besser gewesen diesen beleidigenden Unterton mitsamt Verfasser zu ignorieren aber manchmal muss es eben einfach raus.

 

Vermutlich sollte man Dich mal besser ignorieren. Hier war niemand beleidigend. Mit Deinen Informationen, die uns nicht mitgeteilt hast, kann man

nur die Glaskugel beschäftigen. Von daher sollte man Dir gar nicht erst helfen, wenn Du solche Frechheiten unterstellst.

Im übrigens, mein make oldconfig von 3.13.7 auf 3.14 war problemlos. 

Sonst noch Fragen?

----------

## 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.

----------

## arfe

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

```
Z.B:

linux   /boot/vmlinuz-3.12.8 root=/dev/sdb1 rootfstype=ext4
```

----------

## 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.Last edited by schmidicom on Fri Apr 04, 2014 2:56 pm; edited 3 times in total

----------

## firefly

 *schmidicom wrote:*   

> 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=e8af58790fc5ce081935e7faa3adff6d

 

ODer du verwendest GPT als partitionschema. Dann kannst du mit root=PARTUUID=<UUID der partition> die root partition angeben und ist dann unabhängig der reihenfolge der initialisierung.

Siehe auch: https://bbs.archlinux.org/viewtopic.php?pid=1287333

----------

## 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.

----------

## l3u

 *schmidicom wrote:*   

> 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.

 

Naja, solche Links macht ja udev, und udev ist ja (wie der Name „userspace devfs“ ja schon sagt) astrein eine Userspace- und keine Kernelsache. Da müsste man einiges in den Kernel packen (was die meisten Leute nicht brauchen), um das auf Kernel-Ebene zu machen. Ist in etwa vergleichbar mit dem Mounten eines aktuellen RAID-Verbunds als root. Dafür nimmt man ja auch ein initramfs (was ja nettwerweise erstaunlich simpel herzustellen und in den Kernel einzubinden ist, siehe http://wiki.gentoo.org/wiki/Custom_Initramfs :-)

----------

## 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.

----------

## 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. *schmidicom wrote:*   

> 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 ...

 Was spricht gegen diese Lösung? So fahre ich schon immer. Ich folge dem Motto: Nur das zum Booten zwingend notwendige fest im Kernel, alles andere als Modul. Deine Lösung passt genau in diese Strategie.

Die Vorgehensweise hat den Vorteil dass bei Problemen man das Modul entladen und (ggf. mit anderen Parametern) neu laden kann. Wenn das Modul fest im Kernel ist, geht es nicht.

Das Ursprüngliche Problem bekommt man damit erst wenn man zwei Controller hat die den selben Treiber nutzen.

----------

## l3u

 *schmidicom wrote:*   

> 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.

 

Du musst einfach nur das initramfs in den Kernel einbinden:

```
General setup  --->

     [*] Initial RAM filesystem and RAM disk (initramfs/initrd) support

     (/usr/src/initramfs.cpio.gz) Initramfs source file(s)
```

(hier mit /usr/src/initramfs.cpio.gz als initramfs). Das, was da drin ist, wird dann zunächst geladen (also eben als temporäres root), dann kannst du da machen, was du willst/brauchst. Und natürlich vorher auch reinpacken, was du willst. Du musst nur darauf achten, dass alles statisch gelinkt ist, oder alle Bibliotheken mit drin sind. Das eigentliche root-Dateisystem wird erst benutzt, wenn du in /usr/src/initramfs/init bei

```
exec switch_root /mnt/root /sbin/init
```

ankommst.

----------

## 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.

----------

## l3u

Und? Ist doch gut! Ein initramfs baut man ja nicht zehn mal am Tag, oder? Das richtet man ja für Gewöhnlich ein Mal ein und gut … also zumindest hab ich das so mit meinem initramfs gemacht, das das RAID-1-root-Dateisystem für meinen Server mountet. Und wenn man was ändert, dann muss man es doch eh neu packen!

----------

## schmidicom

Nur wozu selber Packen wenn der Kernel das auch automatisch kann sobald man anstelle einer Datei ein Verzeichnis angibt?

----------

## py-ro

Und wer er beim experimentieren eine initrd einbaut die nicht bootet, kommt er nimmer ins System, wenn er den alten Kernel nicht mehr hat.

Außer in speziellen Fällen hat das eigentlich nur Nachteile.

----------

## l3u

Was weiß ich, ich hab’s halt so gemacht, wie’s in dem Howto steht … und es funktioniert …

Aber wenn man mit einem initramfs rumexperimentiert, dann _sollte_ man einen bootbaren Backup-Kernel haben. Oder zumindest GRML auf einem USB-Stick oder sowas ;-)

----------

