| Message ID | 1453302381-28692-2-git-send-email-ian.campbell@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Ian Campbell writes ("[PATCH OSSTEST 2/3] Debian: erase-other-disks: erase partitions first"):
> It seems that when sdX is zeroed there is some chance that sdX[0-9]
> will disappear before we get to them.
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
We're really pushing the commit-message-to-code ratio here :-).
Ian.
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm index cf3486b..20f3de7 100644 --- a/Osstest/Debian.pm +++ b/Osstest/Debian.pm @@ -1057,12 +1057,13 @@ udevadm settle for sd in sd hd; do log "\${sd} devices present before: `echo /dev/\${sd}*`" for b in a b c d e f; do + for dev in /dev/\${sd}\${b}[0-9]; do + zero + done + dev=/dev/\${sd}\${b} zero done - for dev in /dev/\${sd}a[0-9]; do - zero - done udevadm settle log "\${sd} devices present after: `echo /dev/\${sd}*`" done
It seems that when sdX is zeroed there is some chance that sdX[0-9] will disappear before we get to them. When partman comes along and recreates the partitions it is likely that they will occupy the same disk space as before (since d-i's autopartition is deterministic), meaning that LVM will find the old PV headers again. This is in particular problematic on multi disk systems where we end up with an LV spanning sda5 and sdb. sdb is successfully erased here but sda5 is not, however LVM will still find the LV with missing PV, which is sufficient to trigger partman-lvm's checks for erasing devices which weren't explicitly listed, resulting in: !! 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. which cannot be preseeded around. If the autopartitioning is not deterministic (as might be the case when installing a different version of Debian to last time) then going from layout A -> B -> A' risks B (by chance) not destroying the headers created by A, meaning that A' will find them and suffer again from the problem above. This is handled via the use of ts-host-install-twice which will cause A' to run twice, i.e. A -> B -> (A' -> A''). In this case A' will fail as above, but A'' will startup seeing the partition layout put in place by A' (which matches A) and erase those partitions, leading to success later on. Also erase partitions for all sd/hd? not just sda+hda. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- Osstest/Debian.pm | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)