#1135094 documentation and code support for more flexible partman/early_command

#1135094#5
Date:
2026-04-27 14:35:12 UTC
From:
To:
Hi,

would you consider it a valid usecase that a very big installation would
have their own scripted scheme to create software-raid, crypto, LVM,
multipath, FC, iSCSI, whatever, setup as a partman/early_command "plugin"?

In that case, that early_command would just emit a recipe telling
partman where to mount which device, with all devices already set up,
formatted and ready to be mounted, leaving ONLY the mount to partman.

The early_command would then mit recipes like:

partman-auto/text/home_scheme ::

 0 0 0 ext4
      device{ /dev/mapper/vg00-root }
      method{ keep }
      mountpoint{ / }
 0 0 0 ext4
      device{ /dev/vda2 }
      method{ keep }
      mountpoint{ /boot }
 0 0 0 vfat
      device{ /dev/vda3 }
      method{ keep }
      mountpoint{ /boot/efi }

In this case, plausibiliy checks should be turned off and the
installer should not refuse to install a swapless system. In lieu of
device{}, the filesystem could also be specified by label{} or
partlabel{}, uuid{}, partuuid{} etc.

Maybe it would also make sense to specify a special, no-op recipe to
tell partman that the early_command has done everything already and that
the filesystem tree is readily mounted in /target and an /etc/fsab was
placed in some well-known path for inclusion in the fresh system.

Please consider doing so. I'll happily assist if that would help.

Another possibility would be to roll one's own installation image with a
local partition.udeb that would provide made-filesystems,
mounted-partitions, partitioned-harddrives, created-fstab,
partman-filesystem and partman-method and thus override partman
completely. I would find it very nice if that would not be necessary.

Greetings
Marc