Fedora Upgrade: F11 -> F12
A yum upgrade this time left me rebooting only to end up with:
No root device found Boot has failed, sleeping forever
An F11 kernel worked fine, so I know most things went right. Numerous searches returned a number of problems like this on Live CDs and USB media. I also noted the change from initrd images produced by mkinitrd, to initramfs images produced by dracut. Figuring it might be some glitch with the latter, I tried booting my system on the F11 kernel and doing a manual RPM install of an F12 kernel. No dice, after installing several of them.
UPDATE 2010-02-03: This issue is tracked at https://bugzilla.redhat.com/show_bug.cgi?id=561510.
At this point I resolved to fix a setup issue with my desktop that increased the chances of data loss in the event of drive failure:Â a nice six-year old stripe across a pair of dissimilar PATA drives
/dev/sda (40GB)
sda1: ext3 /boot
sda2: lvm Volume00 (ext3 slash, ext3 var, and swap)
/dev/sdb (80GB)
sdb1: lvm Volume00 (ext3 slash, ext3 var, and swap)
My root in LV Volume00-slash spanned the two drives and was 100GB with only about 50GB in use. I set out to split off my home data to sdb1, and put a combined root and var filesystem on sda2 from which to boot. I reasoned that by putting my root on a plain old Linux non-LVM partition, dracut should at least find it. This involved a lot of steps as root from a rescue boot with everything unmounted:
Shrink the root filesystem down to data_size < X < size_of_drive-fudge
# e2fsck /dev/mapper/Volume00-slash # resize2fs /dev/mapper/Volume00-slash 64G
Shrink the LVM logical volume down to size_of_filesystem < X < size_of_drive
# lvreduce -L 69G /dev/mapper/Volume00-root
Now I needed to empty sda2 of extents and remove it from the the volume group (I cheat in my description here: I was forced to mount Volume00-slash and Volume00-var and copy the contents of var into my slash volume and then “lvremove Volume00/var” and “lvremove Volume00/swap” to make enough space for the pvmove. I also needed to run vgconvert to make pvmove happy, as this box was still using LVM1 metadata since it dates back to FC1)
# pvmove /dev/sda2 /dev/sdb1 # vgreduce Volume00 /dev/sda2 # pvremove /dev/sda2
An fdisk to delete LVM partition sda2 and recreate it as a plain Linux partition
# fdisk /dev/sda ...delete partition 2... ...new parition 2... Disk /dev/sda: 40.0 GB, 40037760000 bytes 240 heads, 63 sectors/track, 5171 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Disk identifier: 0xa5cba5cb Device Boot     Start        End     Blocks  Id System /dev/sda1  *          1         41     309928+ 83 Linux /dev/sda2             42       5171   38782800  83 Linux
Make a filesystem on sda2
# mkfs.ext3 /dev/sda2
Still in the rescue boot, I mounted the new filesystem and the old Volume00-slash in temporary locations. At this point, I went about doing a “cp -a” of all of the directories I wanted on /dev/sda2, which would become the new / (root). In this case, it was everything but home, which I intended to leave in the logical volume that was now isolated to sdb1.
Still not in the clear, as my initrd/initramfs image still thinks it is trying to boot from an LVM logical volume. I needed to reconstruct the initramfs image using the new mkinitrd replacement, dracut. To do this, we need to change our rescue boot environment so that these tools have the pieces in place that they need.
The first thing to do is to find the major and minor numbers of the device which will hold our root. From the following, we can see that our intended root device /dev/sda2 has major number 8 and minor number 2.
# ls -l /dev/sd* brw-rw---- 1 root disk 8, 0 2010-01-26 08:51 /dev/sda brw-rw---- 1 root disk 8, 1 2010-01-26 13:51 /dev/sda1 brw-rw---- 1 root disk 8, 2 2010-01-26 08:51 /dev/sda2 brw-rw---- 1 root disk 8, 16 2010-01-26 08:51 /dev/sdb brw-rw---- 1 root disk 8, 17 2010-01-26 08:51 /dev/sdb1
Now some work to prepare for dracut. This is the process I followed, and have used successfully, repeatedly, when rebuilding initrd/initramfs images. It essentially mimics the system as it will be when running with the following set of mounts and chroot. Making sure nothing is mounted:
# vgchange -ay
# mkdir /mnt/sysimage
# mount /dev/sda2 /mnt/sysimage
# mount /dev/sda1 /mnt/sysimage/boot
# mknod /dev/root b 8 2 (major minor numbers from above)
# mount -o bind /dev /mnt/sysimage/dev
# chroot /mnt/sysimage
# umount {proc,sys}
# mount -t proc proc /proc
# mount -t sysfs sysfs /sys
# dracut -f -v /boot/initramfs-2.6.31.12-174.2.3.fc12.i686.PAE.img 2.6.31.12-174.2.3.fc12.i686.PAE
# umount {proc,sys,dev}
# exit
Before rebooting, I then had to make sure to change any references in grub.conf and fstab from the old /dev/mapper/Volume00-slash to /dev/sda2. Amazingly it all worked first try. Once the new machine booted, I renamed the old Volume00-slash to Volume00-home, made some adjustments, and mounted it at /home. Voila:
/dev/sda2 on / type ext3 (rw,user_xattr) /dev/sda1 on /boot type ext3 (rw) /dev/mapper/Volume00-home on /home type ext3 (rw)
UPDATE 2010-08-10: Finally bothered to yum update and try four monitors, and am pleased to say this is working again. Xorg and Nvidia required a number of bugfixes (from what I last recalled). The Nouveau driver and Xrandr do not like multiple cards (from what I last recalled).
Leave a comment