While updating some d-i preseed configs from stretch to bullseye, I
found that previously working partman configs no longer produce the
expected output. For example, on a 3.5T disk, I have the following
partman config:

  boot-root :: \
    538 538 538 ext4 \
      $primary{ } \
      $bootable{ } \
      method{ format } \
      format{ } \
      use_filesystem{ } \
      filesystem{ ext4 } \
      mountpoint{ /boot } \
    . \
    21475 21475 21475 ext4 \
      lv_name{ root } \
      method{ lvm } \
      format{ } \
      use_filesystem{ } \
      filesystem{ ext4 } \
      mountpoint{ / } \
      $lvmok{ } \
    . \
    1024 1024 -1 ext4 \
      lv_name{ var } \
      method{ lvm } \
      format{ } \
      use_filesystem{ } \
      filesystem{ ext4 } \
      mountpoint{ /var } \
      $lvmok{ } \
    .

I would expect this to produce the following:
- 512M /boot
- LVM VG filling the rest of the disk with:
  - 20G /
  - 3.4T /var (rest of the disk)

That is what happens in stretch and earlier (and maybe buster, I haven't
tested). In the bullseye installer I end up with the following:

  $ lsblk
  NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda            8:0    0  3.5T  0 disk
  ├─sda1         8:1    0  512M  0 part /boot
  └─sda2         8:2    0  3.5T  0 part
    ├─vg0-root 254:0    0   20G  0 lvm  /
    └─vg0-var  254:1    0  976M  0 lvm  /var

In trying to track down this bug, I found that
partman-auto-lvm/guided_size was added and according to
https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/debian/partman-auto-lvm.templates#L77-L79,
defaults to a value of "some number". Unsurprisingly, this is not a
valid number configuration option, so the maximum size doesn't get set
properly. Setting "d-i partman-auto-lvm/guided_size string max" in my
preseed restores the previous behavior. I believe there are two issues
here:

1. "partman-auto-lvm/guided_size" should default to "max" in order to
   maintain compatibility with previous releases.
2. When "partman-auto-lvm/guided_size" is set to an invalid value it
   seems that the code does not behave properly. I'm not sure what behavior
   I'd expect, but I don't think the behavior I am seeing of picking the
   minimum size for each partition is correct.

Thanks!

Stephen

Hi Stephen,

Stephen Gelman <ssgelm@debian.org> (2022-05-17):

Without trying to second guess why this default value is there instead
of something else, you can check partman-auto-lvm/perform_recipe_by_lvm
and the few db_subst calls.

I suppose the big difference between preseeding and not preseeding is the
seen flag checked at the top of the while loop. I don't remember all the
details around preseeding but I'd think "auto" means most questions are
flagged as seen, which means you don't get the default replacement you'd
get with an interactive installation.


I'm not too sure how to best approach a possible fix. While the issue
has cost you some debugging time, having to be explicit about how much
space should be used for LVM doesn't look /that/ bad to me (even if that
means that recipes that had been working for some releases no longer
do).

That being said, maybe there are some places in the documentation and/or
examples where we should add that.


Cheers,

Understood. I do think that newer example preseeds
have partman-auto-lvm/guided_size set to max, so there shouldn’t be a
documentation issue (other than the general lack of documentation around
the preseed file but that is unrelated to this!) My personal preference
would be for the debian-installer to raise an error if this value is
missing - that would have saved me a ton of debugging time. Expecting it to
be set does seem very reasonable to me, but I think if an older preseed
isn’t going to work properly we at least owe it to the user to surface a
proper error message.

Stephen