I spent some time today converting one of my machines to use lvm2 mirroring rather than lvm2 on top of md raid1. There is a problem however. Whenever I convert the root fs to a mirrored volume, the system is unable to boot. Mounting /dev/root always fails with -EBUSY. I hacked up my initrd to drop to a shell and determined that the problem is that nash is creating /dev/root with the wrong device numbers. Instead of picking the device number for the mirror device, mkrootdev picks one of the mirrored halves (one of the "mimage" devices). For instance, after converting the rootfs to a mirrored device: brw-rw---- 1 root disk 253, 3 2009-07-19 11:20 rootvg64-root brw-rw---- 1 root disk 253, 1 2009-07-19 11:58 rootvg64-root_mimage_0 brw-rw---- 1 root disk 253, 2 2009-07-19 11:58 rootvg64-root_mimage_1 brw-rw---- 1 root disk 253, 0 2009-07-19 11:58 rootvg64-root_mlog The "mimage" devices refer to each mirrored copy. I believe what's happening is that mkrootdev is able to read from the mimage devices. It then determines that they have the correct UUID and doesn't stop to consider that they're not the "correct" device. There are probably a couple of different ways to work around this: 1) skip the "mimage" devices somehow when scanning (not sure how you'd test for them though) 2) scan in reverse order (that's not very reliable though) This machine has: nash-6.0.71-6.fc10.x86_64 Let me know if you need other info. It's fairly easy to reproduce given a root on lvm setup (and enough disks to set up a mirrored rootfs). ...I looked through the rawhide nash changelog and nothing stood out at me as something that would fix this.
I've found a little more info about this. If you use the root=UUID=foo000bad... syntax on the kernel command line then this problem seems to occur. Using an explicit devicename there works around it. My suspicion is that nash can't tell the difference between the mirrored device and the mirrored components of the device (both end up as dm-* devices under /dev and they're both readable). It picks the first one it finds when scanning for the UUID. With an explicit device name, it knows to search for just that device and then works correctly. I'm not sure what the best solution is -- it seems like nash should skip scanning components of mirrored devices, but I'm not sure of the best way to make it detect them.
(In reply to comment #1) > I've found a little more info about this. If you use the root=UUID=foo000bad... > syntax on the kernel command line then this problem seems to occur. Using an > explicit devicename there works around it. > > My suspicion is that nash can't tell the difference between the mirrored device > and the mirrored components of the device (both end up as dm-* devices under > /dev and they're both readable). It picks the first one it finds when scanning > for the UUID. With an explicit device name, it knows to search for just that > device and then works correctly. > > I'm not sure what the best solution is -- it seems like nash should skip > scanning components of mirrored devices, but I'm not sure of the best way to > make it detect them. Setting up an lvm mirror is not a supported configuration. This cannot be done in anaconda, since you did this manually, needing to edit grub.conf and /etc/fstab manually to specify the root device there properly comes with the package deal of manually deviating from the supported setups. Note btw that the best way to refer to / on an LV is using root=/dev/mapper/VolGroupName-LogicalVolumeName And this is what anaconda does by default when you let anaconda create a (non mirrored) LV for /.
Fair enough, but I'll make one correction. Rather than stating that this can't be done in anaconda, it's probably more correct to just state that anaconda doesn't currently support such a configuration. There's no reason why anaconda *couldn't* do this. It's a pity that the anaconda and mkinitrd maintainers have no interest in supporting this configuration since it's a useful one.