[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: