Bug#610282: preseed: partman-lvm/confirm boolean true does not suppress "Before the Logical Volume ..."

[Pete Kazmier]

Package: debian-installer
Version: 20101127
Severity: normal
Tags: d-i

When using a preconfiguration file to automate the installation of a Debian
squeeze system, the preseed statement:

d-i partman-lvm/confirm boolean true

does not suppress the following message as expected:

Before the Logical Volume Manager can be configured, the current
partitioning scheme has to be written to disk. These changes cannot
be undone.

After the Logical Volume Manager is configured, no additional changes
to the partitioning scheme of disks containing physical volumes are
allowed during the installation. Please decide if you are satisfied
with the current partitioning scheme before continuing.

The partition tables of the following devices are changed:
Virtual disk 1 (vda)

Write the changes to disks and configure LVM?

<Yes> <No>

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

It's unclear to me if (a) the above should be required to suppress the message,
or (b) if the above should be part of the example seed file in the
documentation. I'm unsure of how the installer scripts work, but I was under
the impression based on what I did read on the Debian site that the message
should have been suppressed with only the 'partman-lvm/confirm' statement. The
docs indicated that one should look in /var/lib/cdebconf/templates.dat and
questions.dat. These showed the value for partman-lvm/confirm as having been
seen and set to true. I examined those files on virtual console 2 while the
installer was displaying the message on virtual console 1.

My environment consists of a Debian squeeze KVM host that contains several
guest squeeze VMs. While trying to fully automate the installation of a
squeeze guest, I discovered the installer was prompting for the above
message. The procedure I used to create a guest is as follows (assumes
you have a libvirt storage pool defined as well as a network bridge):

# NAME=guest
# IPADDR=10.0.1.212
# virsh vol-create-as default ${NAME} 5G --format raw
# virt-install -n ${NAME} -r 256 --vcpus 2 --description "My first VM" --os-type linux
--os-variant debiansqueeze --disk vol=default/${NAME},bus=virtio,cache=none --network
bridge=br0,model=virtio --hvm --virt-type kvm --accelerate --vnc --noautoconsole
--location http://debian.lcs.mit.edu/debian/dists/squeeze/main/installer-amd64
--extra-args "auto=true interface=eth0 hostname=${NAME} domain=kazmier.com
netcfg/get_ipaddress=${IPADDR} netcfg/get_netmask=255.255.255.0
netcfg/get_gateway=10.0.1.1 netcfg/get_nameservers=10.0.1.1 netcfg/disable_dhcp=true
url=http://10.0.1.205/preseed/squeeze.cfg"

The '--extra-args' are provided as parameters to the kernel when the installer
is run. They contain values that are not defined in my preconfiguration file
because they are guest specific. Here is my preconfiguration file BEFORE I
resolved the issue by adding the other statement:

# egrep -v '^$|^#' /var/www/preseed/squeeze.cfg
d-i debian-installer/locale string en_US
d-i console-keymaps-at/keymap select us
d-i netcfg/choose_interface select eth0
d-i netcfg/disable_dhcp boolean true
d-i netcfg/dhcp_failed note
d-i netcfg/dhcp_options select Configure network manually
d-i netcfg/confirm_static boolean true
d-i netcfg/get_hostname string unassigned-hostname
d-i netcfg/get_domain string unassigned-domain
d-i netcfg/wireless_wep string
d-i mirror/country string manual
d-i mirror/http/hostname string debian.lcs.mit.edu
d-i mirror/http/directory string /debian
d-i mirror/http/proxy string
d-i clock-setup/utc boolean true
d-i time/zone string US/Eastern
d-i clock-setup/ntp boolean true
d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
d-i base-installer/kernel/image string linux-image-2.6-amd64
d-i passwd/root-password-crypted password [password removed]
d-i passwd/user-fullname string PK
d-i passwd/username string kaz
d-i passwd/user-password-crypted password [password removed]
d-i apt-setup/non-free boolean true
d-i apt-setup/contrib boolean true
d-i apt-setup/services-select multiselect security, volatile
d-i apt-setup/security_host string security.debian.org
d-i apt-setup/volatile_host string volatile.debian.org
tasksel tasksel/first multiselect standard, ssh-server
popularity-contest popularity-contest/participate boolean false
d-i grub-installer/only_debian boolean true
d-i grub-installer/with_other_os boolean true
d-i finish-install/reboot_in_progress note

As I mentioned above, I did resolve the issue by adding another statement
to the preconfiguration file, but I was unsure if that truly was the fix,
so I opted to open my first bug report (please be kind).

-- System Information:
Debian Release: 6.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Christian PERRIER]

Quoting Pete Kazmier (pe...@kazmier.com):
> Package: debian-installer
> Version: 20101127
> Severity: normal
> Tags: d-i
>
> When using a preconfiguration file to automate the installation of a Debian
> squeeze system, the preseed statement:
>
> d-i partman-lvm/confirm boolean true
>
> does not suppress the following message as expected:
>
> Before the Logical Volume Manager can be configured, the current
> partitioning scheme has to be written to disk. These changes cannot
> be undone.
>
> After the Logical Volume Manager is configured, no additional changes
> to the partitioning scheme of disks containing physical volumes are
> allowed during the installation. Please decide if you are satisfied
> with the current partitioning scheme before continuing.
>
> The partition tables of the following devices are changed:
> Virtual disk 1 (vda)
>
> Write the changes to disks and configure LVM?
>
> <Yes> <No>
>
> 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 don't see this partman-lvm/confirm_nooverwrite being used anywhere
in partman-lvm....it is just registered in partman-lvm init script.

[Colin Watson]

On Mon, Jan 17, 2011 at 06:42:36AM +0100, Christian PERRIER wrote:
> Quoting Pete Kazmier (pe...@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.
[...]

-- Frans Pop <f...@debian.org> Tue, 18 May 2010 03:51:35 +0200

> I don't see this partman-lvm/confirm_nooverwrite being used anywhere
> in partman-lvm....it is just registered in partman-lvm init script.

It's used via partman-base.

./lib/commit.sh:122: fulltemplate="$template/confirm_nooverwrite"

Cheers,

--
Colin Watson [cjwa...@debian.org]

[Pete Kazmier]

On Mon, Jan 17, 2011 at 5:10 AM, Colin Watson <cjwa...@debian.org> wrote:

On Mon, Jan 17, 2011 at 06:42:36AM +0100, Christian PERRIER wrote:
> Quoting Pete Kazmier (pe...@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.