--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: live-build does not support finding image on lvm
- From: Jay Berkenbilt <qjb@debian.org>
- Date: Mon, 25 Nov 2013 14:46:20 -0500
- Message-id: <20131125144620.0367154722.qww314159@soup.q.qbilt.org>
Package: live-build
Version: 3.0.5-1
Severity: minor
I use live-build to build my own custom images, a feature I love
having. I have my system set up to boot one of my live images from my
hard drive, and this works well. Recently I reinstalled my system and
put /boot on lvm since this works fine with grub2, but my live images
no longer work in this configuration. I determined the problem to be
that the /lib/live/boot/* scripts on the initial ramdisk don't call
vgchange -a y anywhere prior to attempting to locate the root.
To be specific, lvm2 works fine in the live image including in the
initramfs if I run it manually. What doesn't work is that the
initramfs code that mounts the root (in the initramfs context, so I
mean the image that contains the live file system) won't find that
image if that image is on a a file system in lvm. The regular
initramfs code (/scripts/local-*) includes code to initialize lvm, and
in general booting from lvm works fine and has for some time. It
seems to me that this is just an omission of initializing lvm in the
live boot code. For example, if I have this stanza in grub.cfg:
menuentry "Q Debian Live 64" {
search --no-floppy --label live-images --set=root
linux /q-live-64/vmlinuz live-media-path=/q-live-64 hostname=qlive boot=live config
initrd /q-live-64/initrd.img
}
it works correctly if the file system with label live-images is a
regular disk partition but if it's a logical volume, it doesn't work
because /dev/mapper/live0-images (or whatever it's called) doesn't
appear. From the (initramfs) prompt, I can type vgchange -a y and
see/mount it fine, so all the modules are there.
I'm not attaching logs, etc. in this case. For me just copying my
live images to a non-lvm partition works fine, and there's no question
of some kind of subtle config error on my part...there is simply no
code that tries to do this. As a quick and dirty change, I tried
sticking the lvm vgchange command that is run from the "local" boot
(vs. the "live" boot) in 9990-main.sh prior to attempting to mount the
root, but that didn't work (I think it hung -- I remember a similar
problem in an earlier dracut), and I didn't pursue it further.
Basically I didn't put a lot of time into debugging it since just
moving the images to a non-lvm partition is okay and doing a lot of
debugging on the older version of live-build is probably a waste of
time.
I tried running the current unstable version of live-build, but it
didn't run to completion and I don't have time to debug it right now.
Perhaps you've already fixed this going forward. If not, this would
be a nice thing to be able to do. But not a big deal.
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages live-build depends on:
ii debootstrap 1.0.55
Versions of packages live-build recommends:
ii cpio 2.11+dfsg-1
ii gnu-fdisk 1.2.5-2
ii live-boot-doc 3.0.1-1
ii live-config-doc 3.0.23-1+deb8u1
ii live-manual-html [live-manual] 1:3.0.2-1
Versions of packages live-build suggests:
ii debian-keyring 2013.07.31
ii dosfstools 3.0.16-2
ii fakeroot 1.20-1
ii git 1:1.8.4.4-1
ii gpgv 1.4.15-1.1
pn loadlin <none>
pn memtest86+ | memtest86 <none>
ii mtools 4.0.18-1
pn parted <none>
pn squashfs-tools | mtd-tools <none>
ii sudo 1.8.8-2
ii syslinux 3:4.05+dfsg-6+deb8u1
ii uuid-runtime 2.20.1-5.5
pn win32-loader <none>
pn xorriso <none>
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 3.0.1
Hi again,
On Wed, Dec 16, 2015 at 08:24:59AM +0100, Evgeni Golov wrote:
> > When you pass live-media=/dev/mapper/* there is a code-apth to trigger
> > the native lvm2 initrd script (/scripts/local-top/lvm2) which *should*
> > take care of everything you need.
>
> Well, that would have worked, if my image would have lvm2 inside the
> initrd... Will try to build new ones later today.
Yes, rebuilding the image with lvm2 ("echo lvm2 > config/package-lists/lvm.list.chroot")
and then copying the image contents to an ext4 formated LV works like a charm.
Log of my copying around, for completeness:
evgeni@nana ~ % dd if=/dev/zero of=/tmp/live.image bs=1G count=1
evgeni@nana ~ % sudo losetup -f --show /tmp/live.image
/dev/loop2
evgeni@nana ~ % sudo fdisk /dev/loop2
evgeni@nana ~ % sudo kpartx -a /dev/loop2
evgeni@nana ~ % sudo pvcreate /dev/mapper/loop2p1
evgeni@nana ~ % sudo vgcreate loopvg /dev/mapper/loop2p1
evgeni@nana ~ % sudo lvcreate -n looplv -L 1000M loopvg
evgeni@nana ~ % sudo mkfs.ext4 /dev/mapper/loopvg-looplv
evgeni@nana ~ % sudo mount /dev/mapper/loopvg-looplv /mnt
evgeni@nana ~ % sudo mount ~/Debian/live/test/live-image-amd64.hybrid.iso /media
evgeni@nana ~ % sudo cp -a /media/* /mnt
evgeni@nana ~ % sudo grub-install --boot-directory=/mnt/boot /dev/loop2
evgeni@nana ~ % sudo umount /media
evgeni@nana ~ % sudo umount /mnt
evgeni@nana ~ % sudo lvchange -an loopvg
evgeni@nana ~ % sudo kpartx -d /dev/loop2
evgeni@nana ~ % sudo losetup -d /dev/loop2
evgeni@nana ~ % qemu-system-x86_64 -enable-kvm -serial stdio -m 1024 -hda /tmp/live.image
Grub did not have a config, so it came up with a pure shell, I entered:
set root=(lvm/loopvg-looplv)
linux /live/vmlinuz boot-live live-media=/dev/mapper/loopvg-looplv
initrd /live/initrd.img
I hope this helps you. Bug closed with the version the LVM support was added.
--- End Message ---