Hallo,

gestern kam über pacman das Update auf Kernel 2.6.22.2, danach bootet das System so:
....
List of all partitions:
no filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unkown-block(0,0)
Ist ein nForce 250 Board, die Festplatte hängt am P-ATA. Irgendwelche Vorschläge?

Ich lad grad das Don't Panic Base ISO und versuch damit das System zu retten (alter Kernel). Fallback-Kernel geht natürlich auch nicht 🙁

Wieso ist es eigentlich bei Arch nicht so, dass der letzte funktionierende Kernel aufgehoben wird und als Bootoption zur Verfügung steht? Würde mir im Moment sehr helfen. Ja, ich weiß, selber machen ...
Welcher Kernel war denn vorher drauf? Eigentlich gibt es bei Minor-Updates keine Probleme.
Der ganz normale 2.6.22.1, ohne irgendwelche Friemeleien. Hat mich ja auch gewundert, im PKGBUILD hat sich praktisch nichts geändert außer den Versionsnummern.
Gab es bei Update Fehlermeldungen? (->pacman.log) Welches root-fs verwendest Du? Hilft es evtl. nochmal mkinitcpio -p kernel26 auszuführen? Nutzt Du pata oder ide?
Bei den Fehlermeldungen bin ich mir nicht 100%ig sicher, bilde mir ein das nicht. Muß ich heute Abend mal schauen, hocke grad auf Arbeit.

Root-FS ist Ext3. Sollte also kein Problem sein.

P-ATA oder IDE weiß ich jetzt auch nicht. Manuell konfiguriert hab ich da wie gesagt nichts. Ich schau nach, heute Abend.

Ich hab vorhin mal das Changelog für Kernel 2.6.22.2 überflogen und eigentlich nichts gefunden, was dieses Problem betreffen könnte. Mir wäre nur wohler, wenn sich noch jemand melden würde, der das gleiche Problem hat :lol:
Ich habe es auf vier Rechnern aktualisiert und keine Probleme; darunter auch einer mit NForce4.
also ich hatte das problem auch, dachte erst, dass es an meinem vm-player läge. ich habe sogar mal ein blankes system genommen und abgedated, der selbe fehler.

ich benutze eine ide-platte über usb. filesystem ist auch ext3.

bei mir ist das aber eigentlich kein problem, die bootbare usb-platte soll nur eine notlösung für einen virtuellen server darstellen, deswegen habe ich einfach alle kernelpakte in die ignorlist gesetzt.

damit wären wir dann schon 2 mit dem problem*g*

stumpi
Ich habe allerdings eine SATA II - Platte,
aber kein Problem bei update des Kernels-

Gruss
Manfred
Bei mir tritt das Problem auch auf, aber ich habe gerade die pacman.log durchgesehen und eine Anmerkung zu Intel-Chipsätzen (hab ich) bemerkt:

If you get a kernel panic below and are using an Intel chipset, append 'earlymodules=piix' to the kernel commandline" -k 2.6.22-ck -c /etc/mkinitcpio.conf -g /boot/kernel26ck.img

Ich probiere dann jetzt mal mein Glück ...
danlei schrieb If you get a kernel panic below and are using an Intel chipset, append 'earlymodules=piix' to the kernel commandline" -k 2.6.22-ck -c /etc/mkinitcpio.conf -g /boot/kernel26ck.img
Diese Meldung kommt aber schon "ewig".
Ich kann (zum Glück) keinerlei Probleme sowohl auf AMD als auch auf Intel-Maschinen
vermelden.
Hat schon mal jemand ein Diff über die .config der beiden Kernel gemacht?
Allerdings (wie Pierre schon sagte) ist das ja nur ein Minor-Kernelupdate.
danlei schrieb If you get a kernel panic below and are using an Intel chipset, append 'earlymodules=piix' to the kernel commandline" -k 2.6.22-ck -c /etc/mkinitcpio.conf -g /boot/kernel26ck.img
Hab ich heut früh schon probiert, bringt nix.
GerBra schrieb Diese Meldung kommt aber schon "ewig".
Ich kann (zum Glück) keinerlei Probleme sowohl auf AMD als auch auf Intel-Maschinen
vermelden.
Hat schon mal jemand ein Diff über die .config der beiden Kernel gemacht?
Allerdings (wie Pierre schon sagte) ist das ja nur ein Minor-Kernelupdate.
Tja, hat leider auch nicht funktioniert; weder beim normalen, noch beim ck-Kernel. Jetzt muss ich erst mal meine Installations-CD suchen und wieder rausfinden, wie man mkinitcpio gebacken bekommt. Bei der Umstellung damals musste ichs zwar auch machen, hab aber alles wieder vergessen. Hoffentlich find ich die CD, sonst muss ich mir extra irgend ein System zum Runterladen installieren.

Ich liebe Montage ...

EDIT

@Usul

Hast Du schon probiert, mkinitcpio laufen zu lassen? Ich muss mirs wieder raussuchen; jedenfalls mit der Installations-CD booten, chrooten und dann ...
Ne, ich häng hier auf Arbeit fest. Hab mir heute früh noch schnell die aktuelle Arch-CD (Base) geladen und werd das System heute Abend reparieren. Wäre natürlich sehr froh, wenn das Problem bis dahin hier schon eingegrenzt wäre, ansonsten bügel ich heute erstmal 'nen alten Kernel drauf.

Auf jeden Fall bau ich mir eine Rücksicherung in Grub ein, ein Kernel, der von den Updates nicht angefasst wird.
Ich hab mal mit ner alten Installations-CD in mein System gebootet, den ck-Kernel gedowngradet und gebootet, dann
# mkinitcpio -g /boot/kernel26.img -k 2.6.22-ARCH
ausgeführt und den normalen Kernel gebootet: funktioniert. EDIT: Geiches jetzt auch beim ck-Kernel.
So, mit Base als Boot-CD konnte ich in meine bestehende Installation hineinbooten. Hier das Logfile des fraglichen Updates:
[2007-08-12 19:57] synchronizing package lists
[2007-08-12 19:57] starting full system upgrade
[2007-08-12 20:09] upgraded dhcpcd (3.1.3-2 -> 3.1.4-1)
[2007-08-12 20:09] upgraded gparted (0.3.3-5 -> 0.3.3-6)
[2007-08-12 20:09] >>>
[2007-08-12 20:09] >>> If you use the LILO bootloader, you should run 'lilo' before rebooting.
[2007-08-12 20:09] >>>
[2007-08-12 20:09] >>> Updating module dependencies. Please wait ...
[2007-08-12 20:09] >>> MKINITCPIO SETUP
[2007-08-12 20:09] >>> ----------------
[2007-08-12 20:09] >>> If you use LVM2, Encrypted root or software RAID,
[2007-08-12 20:09] >>> Ensure you enable support in /etc/mkinitcpio.conf .
[2007-08-12 20:09] >>> More information about mkinitcpio setup can be found here:
[2007-08-12 20:09] >>> http://wiki.archlinux.org/index.php/Mkinitcpio
[2007-08-12 20:09] 
[2007-08-12 20:09] >>> Generating initial ramdisk, using mkinitcpio.  Please wait...
[2007-08-12 20:09] ==> Building image "default"
[2007-08-12 20:09] ==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
[2007-08-12 20:09] :: Begin build
[2007-08-12 20:09] :: Parsing hook [base]
[2007-08-12 20:10] :: Parsing hook [udev]
[2007-08-12 20:10] :: Parsing hook [autodetect]
[2007-08-12 20:10] :: Parsing hook [pata]
[2007-08-12 20:10] :: Parsing hook [scsi]
[2007-08-12 20:10] :: Parsing hook [sata]
[2007-08-12 20:10] :: Parsing hook [usbinput]
[2007-08-12 20:10] :: Parsing hook [keymap]
[2007-08-12 20:10] :: Parsing hook [filesystems]
[2007-08-12 20:10] :: Generating module dependencies
[2007-08-12 20:10] :: Generating image '/boot/kernel26.img'...SUCCESS
[2007-08-12 20:10] ==> SUCCESS
[2007-08-12 20:10] ==> Building image "fallback"
[2007-08-12 20:10] ==> Running command: /sbin/mkinitcpio -k 2.6.22-ARCH -c /etc/mkinitcpio.d/kernel26-fallback.conf -g /boot/kernel26-fallback.img
[2007-08-12 20:10] :: Begin build
[2007-08-12 20:10] :: Parsing hook [base]
[2007-08-12 20:10] :: Parsing hook [udev]
[2007-08-12 20:10] :: Parsing hook [ide]
[2007-08-12 20:10] :: Parsing hook [pata]
[2007-08-12 20:10] :: Parsing hook [scsi]
[2007-08-12 20:10] :: Parsing hook [sata]
[2007-08-12 20:10] :: Parsing hook [usbinput]
[2007-08-12 20:10] :: Parsing hook [raid]
[2007-08-12 20:10] :: Parsing hook [filesystems]
[2007-08-12 20:10] :: Generating module dependencies
[2007-08-12 20:10] :: Generating image '/boot/kernel26-fallback.img'...SUCCESS
[2007-08-12 20:10] ==> SUCCESS
[2007-08-12 20:10] upgraded kernel26 (2.6.22.1-4 -> 2.6.22.2-1)
[2007-08-12 20:10] >> You can safely ignore any "cannot open shared object" errors you see above
[2007-08-12 20:10] upgraded ncurses (5.6-1 -> 5.6-2)
Sind also keine Auffälligkeiten zu beobachten.

Ich werd jetzt mal ein bisschen mit mkinitcpio herumspielen.
Na nun brat mir doch einer 'nen Storch! Nach einem simplen mkinitcpio -p kernel26 wie von Pierre vorgeschlagen fährt die Kiste wieder sauber hoch! Bleibt die Frage, warum das nicht gestern genauso lief, beim automatischen Aufruf durch pacman? Die Aufrufparameter im Logfile von Pacman entsprachen jedenfalls denen, die auch mkinitcpio dann aufgeführt hat.

Wie auch immer, ich bau mir jetzt mal einen Backupeintrag in Grub ...
Ich kann das leider nicht nachvollziehen, was da schiefgelaufen ist. Ob es evtl. mit http://bugs.archlinux.org/task/7807 zusammenhängt?

Falls jemand das gleiche Problem hat: Bitte pacman.log und die defekte /boot/kernel26.img sichern und evtl. hier anhängen. Das könnte für die Fehlersuche hilfreich sein.