I was in the process of moving logical volume extents onto an raid 10 array assembled with mdadmin. One of the logical volumes moved was the root directory (debian testing system) which was previously on a single physical volume. The system is now unbootable. The error message reported in grub rescue is lvmid/ex....lognuuid/another long uuid not found.

I am guessing that the two disks not found are the two currently in the raid 10 array on which the root directory now resides. I am also guessing that this is because the array in not being assembled before the root local volume.

When I boot with the installer media and go into rescue mode, I can not boot the root directory. However, if I first choose the option to assemble an array, and then chroot into the root directory I succeed. I've tried everything I could think of over the past 24 hours. Including various combinations of changing /etc/mdadm/mdadm.conf, update-initramfs -u.

I even tried undoing pvmove, but couldn't because of an lvmetad.socket error. Something must be missing in the chroot rescue environment needed to go this route.

The fact that if I manually assemble the array prior to chrooting, I can get a working system indicates either that the array is not being assembled at all, or not in time (and hence not at all).

Can anyone suggest a fix I could try? I am guessing there is something I can do to get the system functional, but I'm at a loss as to how to proceed.


Work around solution:

1) Install a minimal Linux system on a small logical volume.

2) Make select this system in BIOS boot options

3) The new grub2 installation found the existing system and offered it as a boot option which I then selected.

4) I then ran the following command returning the system to its prior state (without having to resort to backups):

pvmove -n rootpartition /dev/arraydevice 

This moved any logical volume extents associated with the root partition to anywhere else in my lvm pool. I then rebooted the system to confirm the fix. I'll probably leave the backup installation as a failsafe in the event of some other slick move.

Now the fact that this worked (steps 1-3) suggests that the system could be configured to boot from the raid pv, but I didn't have time to find the cause. The original question stands in case someone knows how to navigate the pitfalls of transferring an existing Debian root into a raid pv.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.