Bug#812105: partman-auto: should allow recipes to ask for head of new partitions to be erased
Package: partman-auto
Version: 126
Severity: wishlist
At work we have an automated test infrastructure based on Debian, which
frequently (several times a day) automatically reinstalls the host OS, using
preseeding.
In the past we have found that d-i is often tripping over the LVM
partitions from the last iteration in ways which are difficult (or maybe even
impossible) to preseed around. Therefore we have a hook in
/lib/partman/init.d/25erase-other-disks which goes around and zeroes the first
part of each partition and whole device with:
dd if=/dev/zero of=$dev count=64
in order to destroy any preexisting partition tables or LVM PV metadata etc.
However due to our reinstalls being pretty deterministic we end up usually
recreating the exact same partition layout, meaning that if we failed to erase
a partition for some reason then the LVM PV metadata from before would
magically reappear and the corresponding LV would come back to life etc.
This then causes the checks in partman-lvm/lib/lvm-remove.sh:remove_lvm_find_vgs
to trigger in at least the multiple disk case where we had a LV covering sda5
and sdb and only sdb was erased. Under those circumstances pvs reports the LV
as consisting of sda5 and an unknown device (which was sdb before it was
erased):
# pvs
File descriptor 3 (pipe:[1250]) leaked on pvs invocation. Parent PID 7880: /bin/sh
File descriptor 4 (/dev/ttyS0) leaked on pvs invocation. Parent PID 7880: /bin/sh
File descriptor 5 (/dev/ttyS0) leaked on pvs invocation. Parent PID 7880: /bin/sh
File descriptor 6 (/dev/ttyS0) leaked on pvs invocation. Parent PID 7880: /bin/sh
Couldn't find device with uuid drT3OS-wiB0-t44l-Q1bW-P1Yh-RLEQ-g3ZFix.
PV VG Fmt Attr PSize PFree
/dev/sda5 itch-mite lvm2 a-- 232.60g 211.66g
unknown device itch-mite lvm2 a-m 232.83g 232.83g
This leads to:
!! ERROR: Unable to automatically remove LVM data
Because the volume group(s) on the selected device also consist of physical
volumes on other devices, it is not considered safe to remove its LVM data
automatically. If you wish to use this device for partitioning, please remove
its LVM data first.
It is not possible to preseed with "I know, I don't mind".
I think the single disk case is OK because remove_lvm_find_vgs understands the
sda5 is intended to be erased.
I've just fixed a bug in our test harness which was erasing the whole disk
first apparently causing /dev/sda[0-9] to go away before they could be erased,
which was exposing the sort of issue described above.
Even with that bug fixed there is still a risk when the partitioning is
non-deterministic (i.e. due to changes in d-i between releases, and automated
testing flipping between them for some reason) and automatically going from
A->B->A where B (by happenstance) doesn't manage to clobber the headers from
A. We are working around this by trying the install twice.
It would be much better if it were possible to ask partman to erase the first
part of a partition after it creates it, in fact it perhaps ought to be the
default to do so.
I'm aware that there is already something similar sounding in existence, but it
looks to be specific to partman-crypto and erases the entire disk, which is
unnecessary in our case and too time consuming to serve as a workaround.
I'm filing this against Jessie's version of partman-auto since the "Unable to
automatically remove LVM data" only started hitting us when we updated to using
Jessie (not 100% sure why) and because although a lot of the above concerns LVM
I think the underlying issue is a general one.
Thanks,
Ian.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64
Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Reply to: