Bug#768897: Rough data flow trace
It seems that (debugging with the assumption that latest git and the on-DVD version
are Sufficiently Similar):
1. Flags for partitions are retrieved via libparted, which sets the "lvm" flag
on any partitions that have that GPT type.
2. partman-lvm/init.d/lvm sets the "lvm" method on all partitions with the
"lvm" flag, resulting in (3) from the test sequence.
3. partman-lvm/lib/lvm-base.sh:pv_list assumes all devices with the method "lvm"
are PVs.
4. partman-lvm/choose_partition/lvm/do_option:do_initial_setup iterates over
pv_list and does pv_create on everything in it immediately.
5. partman-lvm/lib/lvm-base.sh:pv_create tests for the presence of an active
PV using the exit code of the pvs command, and anything that doesn't indicate
one results in pvcreate -ff, resulting in (8) from the test sequence. Running
pvcreate without -f interactively will detect the LUKS signature and offer an
abort, as it happens.
On the immediate front, it _may_ be that testing whether it's "safe" to create a
new PV there would be better done via something like
pvcreate --test --quiet -- "$pv" </dev/null >/dev/null 2>&1
(which e.g. exits 5 on finding a LUKS signature) rather than checking using ! pvs.
Or, better yet, along the lines of crypttab(5)'s precheck=un_blkid. By itself, that
would probably make the install fail without further reworking though.
A better question would probably be why that flag->method propagation is done in
manual partitioning mode in the first place; I assume that's used for something,
but I don't know what, having not delved into this code before.
---> Drake Wilson
Reply to: