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 {
    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.

  • What's the reason for bind-mounting /dev? – intuited Feb 18 '11 at 15:58
  • I added /dev in case grub got re-run and wanted to figure out where boot drives were located. I used dpkg in the case that networking is not up or otherwise weird inside the chroot. If networking does work, I recommend "apt-get" over "aptitude" since it does better dep resolution these days. – Kees Cook Feb 19 '11 at 1:49
  • Thanks for the tip about apt-get, it's hard to keep track of what's what. Do you have a link to more info on that? – intuited Feb 19 '11 at 13:48

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.

  • Nice.. that's easier than chroot-ing. I guess this won't register in aptitude's db of packages that were explicitly installed though, so I should probably just install lvm2 and its dependencies this way. Any downsides to using a separate /var? Other than the issue of having to allocate extra 'slack' space? I'd like to be able to snapshot it, so I don't want to mix it in with other large variable files; I'm planning to symlink or bind-mount my home directory to a directory in a separate /data volume that I will create after the system's up & running, to hold music and such. – intuited Feb 17 '11 at 23:33
  • Also: I'll also need to mount the boot fs at /mnt/boot, no? I gather that lvm2 builds a new initrd on installation. – intuited Feb 17 '11 at 23:37
  • @intuited no, it will be recorded as manually installed just like always. Yes, you also need /boot mounted if you have a separate one of those. Having a separate /var doesn't help with making snapshots. – psusi Feb 18 '11 at 2:00
  • A separate /var partition won't help with snapshots, no, but it will, for example, help prevent the root fs from filling up unexpectedly. Are you saying that it will introduce problems with taking snapshots? Oh, wait, that's you on the other question comment thread. Nevermind.. – intuited Feb 18 '11 at 3:10

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.
  • I'm accepting my own answer because it worked well for me; see Kees' answer for a similar solution which may be more reliable in some situations. – intuited Feb 20 '11 at 0:35

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.