The cause of this (assuming that it's the same bug as I've been tracking in Debian Squeeze) is that the LVM data is on the disk, but the partitions are not, so when it tries to look for pre-existing PVs it finds none. Then it sets up the partitions, and assuming the partitions are created in the same place, the partitions that are created are then revealed to contain the previous LVM data, which throws a spanner in the works.
As a work around, I've modified /lib/partman/lib/auto-lvm.sh, just below thse lines:
The sleep is to allow things to settle after the partitions are created by the COMMIT. This should really be detecting when the partitions are ready, rather than just pausing for a while.
The 'pvs --all' seems to kick pvs such that it then lists the information we need -- without that it reacts as though the PVs are not there.
and then we can remove the lvm info from the device.
The cause of this (assuming that it's the same bug as I've been tracking in Debian Squeeze) is that the LVM data is on the disk, but the partitions are not, so when it tries to look for pre-existing PVs it finds none. Then it sets up the partitions, and assuming the partitions are created in the same place, the partitions that are created are then revealed to contain the previous LVM data, which throws a spanner in the works.
As a work around, I've modified /lib/partman/ lib/auto- lvm.sh, just below thse lines:
open_dialog COMMIT
close_dialog
adding:
sleep 10
pvs --all > /dev/null
device_remove_lvm $dev
The sleep is to allow things to settle after the partitions are created by the COMMIT. This should really be detecting when the partitions are ready, rather than just pausing for a while.
The 'pvs --all' seems to kick pvs such that it then lists the information we need -- without that it reacts as though the PVs are not there.
and then we can remove the lvm info from the device.
With that change the install works for me.