• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Kernel Panic: VFS: Unable to mount root fs on hda7

MS Master

Newbie
Hi,

das Problem von oben hat nen Kollege jetzt auf seinem Suse Linux 9.1 Pro.

Er hat sich mittels

Code:
zcat /proc/config.gz > .config

die aktuelle Config des Standard kernles geholt, und dann ein

Code:
make mrproper
make bzImage
make modules
make modules_install

gemacht. Danach hat er das Image nach /boot kopiert, eine initial Ramdisk erzeugt etc. Grub entsprechend konfiguriert, und dann kommt o.g. Fehler bei raus.

Mag sein das ich mich ihre, aber sollte das nicht einen Identischen kernel zum installierten erzeugen :roll:

D.h. es müssten ja alle Dateisystemtreiber geladen werden, nur warum findet er diese dann nicht. Finde ich schon etwas "seltsam".

Hat dafür jemand eine erklärung, oder antwortet mal wieder keiner, weil ich ja ein Microsoft Freak bin, wie ich mir das dauernd anhören muss (auser auf gnulinux.de, da die dort wissen, wofür das MS in meinem namen steht).
 
A

Anonymous

Gast
Dass dir niemand antwortet liegt wohl eher daran, dass sich vor dir noch niemand mit diesen Fragen (zumindest mit der ersten zum Thema Module) beschäftigt hat. Ob es am MS liegt kann ich nicht beurteilen, aber anstatt sich hier missverstanden zu fühlen solltest du uns Unwissende vielleicht einfach aufklären. :wink:

Zu der Fehlermeldung kann ich auch nicht viel sagen. Allerdings gibt es auch wenn die aktuelle config geklont und auf die gleichen Quellen angewandt wurde, noch die Möglichkeit, dass beim Erstellen der Ramdisk was schiefgelaufen ist.

Aber warum sollte jemand einen Kernel kompilieren, der identisch zum aktuellen Kernel ist? Da wurden doch sicher Änderungen gemacht?! z.B. andere Kernelquellen (dann sollte zuvor ein 'make oldconfig' gemacht werden) oder die config verändert.
 
OP
M

MS Master

Newbie
Hi,

danke erst mal für die Antworten.

@abisko00

Das er das aktuelle Kernel "klont" habe ich ihm empfohlen, da er wohl probs mit dem PC hatte, um sicherzugehen, das seine anderen "fehler" erst mal nicht an seiner neuen Kernel Config liegen. Daher sollte er quasi nochmals das gleiche kernel kompilieren, um sicherzugehen, das ansonsten alles ok ist.


@oc2pus

hm, ein mkinitrd wurde aber gemacht....

Muss man wohl nochmals alle namen überprüfen, könnte es daran liegen ?
 

oc2pus

Ultimate Guru
hm, ein mkinitrd wurde aber gemacht....

mit welchen Parametern?
für welchen kernel ? wahrscheinlich für den aktuell laufenden und NICHT für den neu compilierten ...

Wurden alle für das Booten relevanten Dinge fest in den Kernel compiliert, so kann auf eine Initial Ramdisk (initrd) verzichtet werden. Ansonsten ist diese Initial Ramdisk für den neuen Kernel nun zu erstellen (wiederum als Root):
$> cd /boot
$> mkinitrd -k vmlinuz-2.6.0-th1 -i initrd-2.6.0-th1
Wie man sieht, sollte auch die Initial Ramdisk mit einer Versionsnummer versehen werden. Die Optionen "-k" und "-i" müssen hier benutzt werden, da sonst die Initial Ramdisk nicht für den neuen, sondern für den momentan noch laufenden Kernel erstellt würde. Die Module, die in die Initial Ramdisk aufgenommen werden, werden der Datei /etc/sysconfig/kernel entnommen (Variable: INITRD_MODULES). Will man andere Module in die Initial Ramdisk aufnehmen, so können deren Namen per Option "-m" bei mkinitrd angegeben werden. Siehe auch "mkinitrd -h" für eine Hilfe zum Programm.

lies hier, der Bibel für Kernel-Bauer:
http://www-gpi.physik.uni-karlsruhe.de/pub/thomas/kernel26.html
 
OP
M

MS Master

Newbie
@oc2pus

Hm, genau nach der Anleitung wurde es gemacht :wink:

Also du sagst, wenn der fehler kommt, liegt es an einem fehler in der Initial Ramdisk.

Dann sollte der Fehler ja weg sein, wenn man ReiserFS oder ext3 je nachdem, fest in den Kernel einkompiliert, richtig ?
 
OP
M

MS Master

Newbie
Fehler gefunden :D

Die initrd war nicht in grub eingetragen. Somit wurde diese dann auch nicht geladen.
 
Oben