[SOLVED] Bootloader drops to dracut shell after FC17 upgrade

[AndyW]

After a long struggle with the install DVD and Anaconda (posted elsewhere in this forum) I gave up and upgraded from FC16 to FC17 using yum. After a few issues I can boot up OK except that if I select the FC17 kernel (3.4.4-5.fc17) the bootloader gives me warnings about

unable to open '$devnode'

and

Unable to process initqueue
/dev/mapper/VolGroup00-LogVol00 does not exist

before dropping to the dracut prompt. (Screenshot attached as .PNG.)

I am using LVM and have /, /usr, /var and /usr/local on separate LVs, though this has not caused major problems before. I can boot to the FC16 kernel (3.3.7-1.fc16) without problem, though I do get a kernel panic when I shut down.

Dracut is 018-78.git20120622.fc17 - this is the only package version for this, though there are quite a lot of FC16 and FC17 duplicate packages elsewhere. I had to rebuild initramfs a few times and edit grub.cfg to get even this far - the upgrade seems to leave a few things out. This is the relevant part of grub.cfg

        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        insmod lvm
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root a2a7bbe2-e3ea-4982-847e-c4ae9f51ed77
        echo 'Loading Fedora (3.4.4-5.fc17.x86_64)'
        linux   /vmlinuz-3.4.4-5.fc17.x86_64 root=/dev/mapper/VolGroup00-LogVol00 ro quiet SYSFONT=latarcyrheb-sun16 rhgb KEYTABLE=uk rd.luks=0 LANG=en_US.UTF-8

        echo 'Loading initial ramdisk ...'
        initrd /initramfs-3.4.4-5.fc17.x86_64.img

It is as if the bootloader can't see LVM volumes under FC17 - though it clearly can in FC16.

Any ideas or suggestions?
Andrew

[Skull One]

Originally Posted by AndyW

I am using LVM and have /, /usr, /var and /usr/local on separate LVs, though this has not caused major problems before. I can boot to the FC16 kernel (3.3.7-1.fc16) without problem, though I do get a kernel panic when I shut down.

I suspect the problem being from the separate /usr:
http://freedesktop.org/wiki/Software...-usr-is-broken
If you find a way to boot (probably by some modification of the initramfs), I will be very happy to read it.
Good luck!

[AndyW]

It looks like the problem was due to /usr-move with /usr being on a separate LV, possibly together with changes in the latest versions of dracut and udev. I found a lot of forum postings and bugreps concerning these and relating to similar issues, but nothing absolutely definitive. My 3.3.7-1.fc16 initramfs from before /usr-move would boot OK. This would have been built using late FC16 package versions end-May/early June - I don't know exactly which. The same kernel initramfs built after /usr-move wouldn't boot, but as I think this was also after dracut and udev had been upgraded in the FC17 yum upgrade I can't be certain what is the cause; I don't recall now the exact order but I don't think I rebuilt initramfs until after the FC17 upgrade.

Anyway, what worked for me was the procedure here:- http://rich0gentoo.wordpress.com/201...dracut-module/. This Red Hat bugrep has a patch for what looks like a similar problem, but I couldn't get it to work https://bugzilla.redhat.com/show_bug.cgi?id=830447#c4. The scripts in the Gentoo blog post follow exactly the same structure as other standard dracut modules on my system. I don't know enough about dracut, udev, lvm etc. to know exactly what it is doing, but I am happy for it to be explained to me by someone.

As well as booting 3.3.7-1.fc16 I was also able to complete FC17 upgrade (did a lot of enforced tidying up) and get 3.4.4-5.fc17 to boot after rebuilding initramfs. Upgrade to 3.4.6-2.fc17 subsequent to installation of the new dracut module went cleanly and didn't require any manual intervention.

Hope this may be of use to someone.

Andrew