[Debian] 2.6.22: kernel panic, unable to mount root fs (0,0)

[Arnout]

Situatie: Debian Etch geïnstalleerd met de daily build installer (omdat hij anders de 2e SATA schijf niet detecteerde). Dit lukte aardig, moest wel boot parameter "pci=conf1" meegeven anders werkte het niet.

Met de installer een software-RAID1 aangelegd, /boot en swap daarbuiten gelaten. In de RAID1 met LVM een logical volume aangemaakt. De root zit dus in het LVM volume.

Na de installatie gereboot en alles werkte prima (Debian Etch met een 2.6.18-5-686 SMP kernel). Ook Knoppix met een 2.6.19 kernel werkt prima (met eerder genoemde boot parameter of "pci=nommconf")

Omdat ik vanaf 2.4.19 al zelf kernels maak en dit nooit tot problemen leidde zo ook deze keer 2.6.22.6 (vanilla) opgehaald en geconfigureerd. Dit was de eerste keer dat ik SATA schijven in software-RAID1 heb gezet en daarover LVM gebruik, dus ik verwachtte niet dat de config in 1 keer juist zou zijn.

Maar na 2 dagen en tig compiles verder (gelukkig gaat dat snel op een Core 2 Duo 6300) zou ik niet weten wat er fout gaat.

De foutmelding:

Kernel panic: VFS: unable to mount root fs on unknown-block (0,0)

Uitvoer van relevante informatie:
lsmod.txt
lspci.txt
dmesg.txt
kernel_config.txt
menu.lst

Samenvatting hardware: HP DC7700 - Intel Core 2 Duo 1.86 6300 - 1 GB RAM - 2x 250GB SATA - ICH8 chipset.

Ik heb alle LVM/RAID/Filesysteem zaken static in de kernel gecompileerd. Verder heb ik de kernel gebouwd met of zonder de --initrd optie. Dus

# fakeroot make-kpkg --initrd kernel_image

Ik heb verder geen kennis van initrd en vraag me dan ook af of dit genoeg is en of dit het hele probleem niet is. Verder vraag ik me af of initrd wel nodig is als je alles static in de kernel bouwt? En het root fs wat genoemd wordt in de error, is dat het initrd fs of is dat het "echte" root fs (op het LVM volume)?

Het schijnt ook zo te zijn dat tussen de 2.6.18 en de 2.6.22 enkele zaken gewijzigd zijn met betrekking op naamgeving van devices die libata voortbrengt.

Alvast bedankt voor de antwoorden en als ik nog meer uitvoer moet beschikbaar stellen dan hoor ik dat graag.

[Crakie]

Moet je niet gewoon een ramdisk image maken met mkinitramfs? Dat is volgens mij wel nodig bij LVM/RAID; in de kernel inbakken is niet genoeg AFAIK.

[Arnout]

Crakie schreef op zaterdag 15 september 2007 @ 23:07:
Moet je niet gewoon een ramdisk image maken met mkinitramfs? Dat is volgens mij wel nodig bij LVM/RAID; in de kernel inbakken is niet genoeg AFAIK.

Is --initrd als opite niet voldoende bij make-kpkg en moet ik los daarvan nog meer doen onder Debian?

(ik boot dus niet van een RAID/LVM volume, ik heb /boot buiten de RAID set geplaatst op SATA schijf 1)

[ Voor 12% gewijzigd door Arnout op 17-09-2007 07:52 ]

[daft_dutch]

dat moet voldoende zijn
Maar initrd moet wel weten dat die module er in moet.
Waarom gooi je de module niet in de kernel als je toch je eigen kernel compiled

[Verwijderd]

Ik heb laatst met een debian sid machine wat problemen gehad met booten. Wat bleek dat het script /usr/bin/ldd niet geupdate was terwijl dit wel had moeten gebeuren. Check dus even of de /usr/bin/ldd die jij hebt overeenstemd met die uit de debian package van libc6.

misschien handig:

code:

dpkg -S /usr/bin/ldd # check in welk package ldd zit
ar x bladibla.deb # Debian package uitpakken

[Arnout]

De kernel panic is opgelost door de volgende regel in /etc/kernel-img.conf op te nemen:

ramdisk=mkinitramfs-kpkg

De initramfs tools waren al geïnstalleerd onder Etch.

Hierna kreeg ik de melding dat de raid1 module niet gevonden kon worden, deze heb ik als module gebouwd tezamen met de device mapper (LVM) support.

Hierna bootte het systeem een stukje verder, om vervolgens te stoppen met de error:

mount: mounting udev on /dev failed: invalid argument

Na googlen kwam ik erachter dat je dan niet mkinitramfs moet gebruiken, maar yaird.

/etc/kernel-img.conf:

#ramdisk=mkinitramfs-kpkg
ramdisk = /usr/sbin/mkinitrd.yaird

Hierna kreeg ik problemen met evdev, deze uitgecommentarieerd in de yaird configuratie.
Nu komt er bij de boot de melding dat hij sda niet kan vinden.

Ik denk dat ik het maar bij de standaard 2.6.18 kernel houdt, ik heb me blijkbaar verkeken op de moeilijkheid om zelf kernels te maken.

[Verwijderd]

Je begint te moeilijk. Wat je het beste kunt doen is een standaard config pakken (dus make xconfig en dan 'bestand openen' /boot/config). Je gebruikt dan de config van een kernel die werkt en je kan op je gemak alle dingen eruit gooien die je niet wilt gebruiken.

Succes

[Arnout]

Verwijderd schreef op zaterdag 22 september 2007 @ 19:01:
Je begint te moeilijk. Wat je het beste kunt doen is een standaard config pakken (dus make xconfig en dan 'bestand openen' /boot/config). Je gebruikt dan de config van een kernel die werkt en je kan op je gemak alle dingen eruit gooien die je niet wilt gebruiken.

Succes

Dank voor dit duwtje, heb het geprobeerd en het leverde zowaar een kernel op die in ieder geval geen panic gaf. De RAID1 array was wel gebroken en daarom kwam hij in maintenance mode terecht (dit gebeurde niet met 2.6.18) maar dat heb ik eenvoudig kunnen herstellen door de array opnieuw te laten bouwen.

Er zijn wel veel wijzigingen geweest tussen 2.6.18 en 2.6.22, bijv. libata is van plaats veranderd dus dat moest ik nog wel even aanzetten. Bedankt.

De initrd is gebouwd met mkinitramfs en dus niet met yaird, en deze werkte blijkbaar wel goed. De mislukte kernels hadden het over udev, dus ik vermoed dat het udev probleem niet zozeer met mkinitramfs te maken heeft maar meer met bepaalde 'vergeten' kernel opties/modules.

---

Edit: ik zit nog eens naar mijn eerder geposte kernel configuratie te kijken en ik zie dat CONFIG_TMPFS niet gezet is, dit is noodzakelijk voor udev, net zoals CONFIG_HOTPLUG en CONFIG_PROC_FS. Dit even ter aanvulling mocht je ook problemen hebben met udev support.

[ Voor 26% gewijzigd door Arnout op 24-09-2007 09:13 ]

[Arnout]

Ter afsluiting: de originele TS werd dus veroorzaakt door de volgende 2 problemen:

1. udev werkte niet doordat ik bepaalde kernel opties miste (zie bovenstaande post)
2. je MOET gebruikmaken van initrd (initramfs!) en van modules voor sowieso RAID, LVM en SATA, deze mogen niet statisch gecompileerd zijn!

mijn geladen modules zien er nu zo uit (rest is statisch):

debian:/usr/src# lsmod
Module                  Size  Used by
dm_mod                 56448  5
raid1                  23680  1
md_mod                 78548  2 raid1
ide_generic             1216  0 [permanent]
generic                 4868  0 [permanent]
ide_core              106960  2 ide_generic,generic
ata_piix               17476  4
libata                122804  1 ata_piix

debian:/usr/src# uname -a
Linux debian 2.6.23-rc7 #1 SMP Mon Sep 24 21:22:08 CEST 2007 i686 GNU/Linux

[vanaalten]

Arnout schreef op dinsdag 25 september 2007 @ 09:15:
je MOET gebruikmaken van initrd (initramfs!) en van modules voor sowieso RAID, LVM en SATA, deze mogen niet statisch gecompileerd zijn!

Hmmm, ik weet niet of ik je helemaal goed begrijp, maar voor alleen SATA heb je niet perse initrd/modules nodig. Ik heb in elk geval SATA support statisch er in zitten, een kernel zonder initrd. RAID en LVM heb ik verder geen ervaring mee.