Bug#1088104: partman-auto-raid: Recipe delimiter parsing shortcoming restricts mdadm $EXTRA_ARGS
On 14/05/2025 at 21:47, Cyril Brulebois wrote:
Feel free to add this to the wishlist, without any promises though.
https://wiki.debian.org/DebianInstaller/Trixie/Wishlist
I can do it if Johannes agrees.
I haven't tried to fully understand the patches and its implications, but
that might be doable even if we're getting late in the release cycle.
Patch 1 (amended by patch 3) enforces that partman-auto-raid recipe
separator periods are isolated (surrounded by blanks), so that dots
which may exist in recipe elements (devices, extra-args...) are not
processed as recipe separators any more. E.g.:
1 2 0 fat32 -
/dev/disk/by-path/pci-0000:61:00.0-nvme-1#/dev/disk/by-path/pci-0000:a4:00.0-nvme-1
# --metadata=1.0 .
The implication is that existing partman-auto-raid recipes in which a
separator period is appended to the last recipe element will not be
supported any more, e.g.:
1 2 0 ext4 / /dev/sda1#/dev/sdb1.
This is what is already enforced by partman-auto recipe parser and
illustrated in all examples provided by partman-auto-raid documentation
[1], even though it does not formally state that separator periods must
be isolated.
[1]
<https://sources.debian.org/src/debian-installer/testing/doc/devel/partman-auto-raid-recipe.txt>
Patch 2 adds support for the special "efi" method in partman-auto-raid
recipes. However it seems to be incomplete, as IIUC it does not set the
"esp" flag/partition type identifier on RAID member partitions, which
may be required by some UEFI implementations to recognize such
partitions as ESP when booting from the removable media path (other UEFI
implementations may be able to use any partition containing a FAT
filesystem as an ESP, regardless of the partition type identifier). Note
that grub-install cannot update EFI boot variables if /boot/efi is not a
plain partition, so booting from such setup relies on the removable
media path or manually updating EFI boot variables with efibootmgr via
preseed commands.
Reply to: