Fixing unbootable installation on LVM root from Desktop LiveCD

I just did an installation from the 10.10 Desktop LiveCD, making the root volume an LVM LV.

Apparently this is not supported; I managed it by taking these steps before starting the GUI installer app:

• installing the lvm2 package on the running system
• creating an LVM-type partition on the system hard drive
• creating a physical volume, a volume group and a root LV using the LVM tools. I also created a second LV for /var; this I don't think is relevant.
• creating a filesystem (ext4) on each of the two LVs.

After taking these steps, the GUI installer offered the two LVs as installation targets; I gladly accepted, also putting /boot on a primary partition separate from the LVM partition.

Installation seemed to go smoothly, and I've verified that both the root and var volumes do contain acceptable-looking directory structures.

However, booting fails; if I understood correctly what happened, I was dropped into a busybox running in the initrd filesystem.

Although I haven't worked through the entirety of the grub2 docs yet, it looks like the entry that tries to boot my new system is correct:

menuentry 'Ubuntu, with Linux 2.6.35-22-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    insmod part_msdos
    insmod ext2
    set root='(hd0,msdos3)'
    search --no-floppy --fs-uuid --set $UUID_OF_BOOT_FILESYSTEM
    linux   /vmlinuz-2.6.35-22-generic root=/dev/mapper/$LVM_VOLUME_GROUP-root ro   quiet splash
    initrd  /initrd.img-2.6.35-22-generic
}

Note that $VARS are replaced in the actual grub.cfg with their corresponding values.

I rebooted back into the livecd and have unpacked the initrd image into a temp directory. It looks like the initrd image lacks LVM functionality. For example, if I'm reading /usr/share/initramfs-tools/hooks/lvm2 (installed with lvm2 on the livecd-booted system, not present on the installed one) correctly, an lvm executable should be situated in /sbin; that is not the case.

What's the best way to remedy this situation? I realize that it would be easier to just use the alternate install CD, which apparently supports LVM, but I don't want to wait for it to download and then have to reinstall.

You hit the problem right on the head: the initramfs does not have LVM support. Here's how to fix it:

1. Boot the LiveCD again
2. Install lvm2 again in the Live environment

3. Bring up the Volume Group (if -a y does not work try -a yes)

   vgchange -a y
   

4. Get the root LV, /boot, and /dev mounted under the separate tree

   mkdir /newroot
   mount /dev/yourVG/rootLV /newroot
   mount /dev/yourbootpartition /newroot/boot
   mount -o bind /dev /newroot/dev
   

5. Copy the needed packages into the /newroot tree

   cp /var/cache/apt/archives/*deb /newroot/tmp/
   

6. Chroot into the new tree and install the packages

   chroot /newroot
   cd /tmp
   dpkg -i *.deb
   

At this point, things should be back to normal (since the initramfs will be regenerated when lvm2 is installed). If not, you can play with running update-initramfs -u inside the chroot.

After installing the system to the hard disk, you need to install lvm2 into that system before it can boot. If you installed lvm2 on the livecd, then the packages will still be in /var/cache/apt/archives. Change to that directory, mount the hard disk, and install the packages to the hard disk using dpkg --root=/mnt *.deb. In your case, you need to mount the root fs to /mnt, and also the var fs into /mnt/var.

Also you don't need the separate /boot partition, and a separate /var partition is questionable.

I ended up doing mostly what Kees Cook nicely lays out, with some help from the final section of this walkthrough. However:

• I didn't bind-mount /dev. It looks like this caused some error messages later; see below.
• I mounted my /var volume on the new root in addition to /boot.

• I didn't copy the debs into the /tmp of the new root. Instead, I ran # apt-get install aptitude; aptitude install lvm2 after chrooting.

  • I did this in order to register these actions in the apt database: for example, aptitude, and perhaps also apt-get, will track which packages were installed explicitly and which were installed automatically as dependencies.
  • Since I'm actually getting my packages via a local apt proxy (running apt-cacher-ng), I didn't even have to wait for them to download again. I did have to make a file at /etc/apt/apt.conf.d/02proxy containing Acquire::http::Proxy "http://local-apt-proxy-server:3142"; before running apt-get. I had done the same thing before starting to install packages while running off the LiveCD before doing the install.

  • I got an error message or warning a couple of times, stating

    Can not write log, openpty() failed (/dev/pts not mounted?)
    

**mount -o bind /dev/pts /mnt/YouNameIt/dev/pts

    This did not prevent the appropriate lines from being added to `/var/log/dpkg.log`.

    I suspect that this issue could have been averted by bind-mounting `/dev`, but I don't really understand what it means, i.e. I don't know what log it's referring to, or why it would need to access a pty in order to write to a log.