After PreUpgrade (F8=>F9): "Booting Has Failed"

[Hlingler]

Hello Fedora-Land:

Trying to get things upgraded in time for F10 release, I tried PreUpgrade on one of my F8 installs. All seemed to go well until it came time to reboot into F9. Then the melt-down:

[...]
vgchange     Wiping internal VG cache
Trying to resume from /dev/VolGroup00/LogVol01
Unable to access resume device (/dev/VolGroup00/LogVol01)
Creating root device.
Mounting root filesystem.
mount: error mounting /dev/root on /sysroot as ext3: No such file or directory
Setting up other filesystems.
Setting up new root fs
setuproot: moving /dev failed: No such file or directory
no fstab.sys, mounting internal defaults
setuproot: error mounting /proc: No such file or directory
setuproot: error mounting /sys: No such file or directory
Mount failed for selinuxfs on /selinux: No such file or directory
Switching to new root and running init.
unmounting old /dev
unmounting old /proc
unmounting old /sys
switchroot: mount failed: No such file or directory
Booting has failed.

I can still boot (into text-mode only) with the remaining F8 kernel, but obviously this won't do. I'd like to try to fix this issue rather than scrap the whole OS. I searched but found little on PreUpgrade, and nothing of help on the above messages.

Any suggestions/ideas/help on how to fix this ?

Thanks and Regards,
V

[stoat]

Hello Hlingler,

My aversion to Logical Volume Management is well documented in the record. But I have experienced failure to access the resume device before even with standard partitions. It had to do with me changing something about the swap partition. I forget, but it was probably its label or something like that. Anyway, it knocked the slats out of booting. I fixed it by teaching myself how to edit the initial ramdisk file and changed the name of the resume device in there. Other people have just used mkinitrd to generate a new initial ramdisk (easier). A kernel update probably fixes such things too for the same reason.

I feel like that /dev/VolGroup00/LogVol01 is the swap. Maybe the logical volume name in the pre-upgraded volume group and the initial ramdisk are different now, and it's doing what it always does when that happens. I found some support for this idea on the Internet with this search phrase: "Unable to access resume device (/dev/VolGroup00/LogVol01)". It's happened before, but I stopped reading after the first few when I remembered my own resume device encounter.

Can you do your LVM voodoo incantation things to find out the answer to that question about the swap and the logical volume names? The inital ramdisk is looking for /dev/VolGroup00/LogVol01. You can probably do it in the old kernel.

P.S.: Turns out I remembered my experience about the "Unable to access resume device" thing wrongly. My own earlier posts about this matter indicate that it did not stop the system from booting.

[Hlingler]

Hi stoat:

And many thanks for responding. And I'm beginning to share the aversion to LVM. I can say for sure that /dev/VolGroup00/LogVol01 is (and always was on this install) SWAP. I'm not sure what you're referring to: "LVM voodoo incantation thing" - most of my tricks are nothing more than smoke and mirrors.
I'll try disassembling both initrd images and compare the init files. And a kernel update I think is available, so I'll try that too.

Thanks Again,
V

[Hlingler]

Still working on this, and still not fixed.

I have two kernels installed at this point: 2.6.26.6-49.fc8 (which boots successfully, and no GUI/X11, but...), and 2.6.27.5-37.fc9, which fails as before. I've tried to make a new initrd file with mkinitrd, with same results. I have tried dis-assembling the initrd file and editing the init file, the only effect being failure on mount of system LVM instead of SWAP. Would very much like to find some fix/work-around before attempting on other F8 installs. Any other suggestions as to how to fix?

Thanks,
V