On Mon, Jan 17, 2011 at 06:42:36AM +0100, Christian PERRIER wrote:
> Quoting Pete Kazmier (
pete@kazmier.com):
> > I was able to resolve the issue by adding the following preseed statement
> > to my preconfiguration file:
> >
> > d-i partman-lvm/confirm_nooverwrite boolean true
>
> CC'ing Colin Watson, who introduced this confirm_nooverwrite template
> back in April 2010. He may have more clues than me, whether this
> belongs to the installation guide, who'd need to be updated or if this
> might be a bug in partman-lvm.
I already updated the installation guide for this some time ago.
installation-guide (20100518) unstable; urgency=low
[ Colin Watson ]
[...]
* partman now asks a slightly different (and less scary) confirmation
question if it doesn't appear that any data is being overwritten.
Document the associated preseeding changes.
[...]
I was unable to find this in the documentation:
kaz@air:installation-guide-20100518$ grep -r 'partman-lvm/confirm_nooverwrite' *
I do see 'partman/confirm_nooverwrite', but no 'partman-lvm/confirm_nooverwrite'. I could easily be overlooking something as I'm not familiar with the way the documentation is produced. Also, there is a seed file that is linked somewhere, and that seed file also didn't have the key. I just happened to stumble upon this somehow after a lot of googling.
I think I may also have stumbled onto a bug as well yesterday while I was trying to figure out how to automate the install of these guest VMs. After I realized there was a new key needed in my preseed file, I discovered the automated build would fail sometimes. Here is the scenario:
- Create a 5G LV called 'guest1' on my KVM host for the guest's /dev/vda
- Install using my preseed file
- Use the whole disk (vda) with LVM
- Use a single partition for everything
- Results in /boot on vda1, LVM on vda5
- Install completes fully automated, no errors
I then wanted to retry the build to confirm the new preseed file continues to work as expected, but this time I changed the hostname. So, I destroyed 'guest1' and installed 'guest2' using this sequence of steps:
- On my KVM host, delete LV 'guest1'
- Create a 5G LV called 'guest2' on my KVM host for the guest's /dev/vda
- Install using my preseed file
- Use the whole disk (vda) with LVM
- Use a single partition for everything
- Results in /boot on vda1, LVM on vda5
- Installer fails indicating '/dev/vda5' is already in VG 'guest1' !!
The 'guest1' VG should not exist in this scenario, yet the installer had known about it. I'm not familiar with the installer, but I think that it was picking up the old guest1's LVM metadata on the guest2's /dev/vda, which was really the same physical backing of my KVM host's disk. When creating the LV on my host, lvcreate zeros out the first KB of space by default (see lvcreate(8)), but that would only have overwritten the /boot partition on the guest's vda. The guest's LVM doesn't start for at least 200MB, so whatever metadata was written by the first guest1's installer (specifically the VG name of guest1) was still present and the installer for guest2 picked that up. In order to proceed, I had to zero out more than the first 200MB (say 300MB) of the LV on the host so the guest2 installer could proceed. So my new procedure for building a guest3 would be:
- On my KVM host, delete LV 'guest2'
- Create a 5G LV called 'guest3' on my KVM host for the guest's /dev/vda
- dd if=/dev/zero of=/dev/world/guest3 bs=1M count=300 (zero out the first 300MB on the LV, which will eventually be presented to the guest and installer as /dev/vda. This will blow away the previous installer's VG that was created.
- Install using my preseed file
- Use the whole disk (vda) with LVM
- Use a single partition for everything
- Results in /boot on vda1, LVM on vda5
- Install completes fully automated, no errors
Success finally! So, I'm not sure if this is a bug, or if I should have been expected to zero out the LV before presenting it to the installer on the guest, but I could see this being a common situation for someone building guests on a KVM host.