Package: partman-auto-raid Severity: important Tags: patch Hi,
I'm not a preseed expert but it seems to me we're currently lacking support for one rather common layout that's achievable via the interactive installer, which is RAID+LUKS+LVM. As far as I understand we support a few methods, but only *one* of them can be chosen via partman-auto/method. The partman-auto package intercepts “regular” and deals with it on its own, but also delegates to partman-auto-<METHOD> if a different method is specified: - partman-auto-crypto: sets up LUKS+LVM. - partman-auto-lvm: sets up LVM. - partman-auto-raid: sets up RAID, but can also do RAID+LVM if the RAID specification includes the “lvm” keyword. The fact we're supposed to be choosing one and only one method is confirmed by looking at the implementation of each method, which suggests they were never meant to be combined (i.e. stacked on top of each other): - partman-auto-lvm ships an auto-lvm.sh library, defining functions like auto_lvm_prepare() and auto_lvm_perform(), which it obviously uses itself to implement LVM support. - partman-auto-crypto leverages that auto-lvm.sh library, using both functions directly in its autopartition-crypto script, to implement LUKS+LVM support. - partman-auto-raid also leverages that auto-lvm.sh library, but not as directly as partman-auto-crypto does: since auto_lvm_prepare() wants to create partitions, it was partially copied/adjusted in its initial_auto_raid_lvm script; that being said, it calls auto_lvm_perform() in the end; that's how it implements RAID+LVM. Since partman-auto-raid already knows how to deal with RAID and with RAID+LVM when the “lvm” keyword is detected, I looked into making it support RAID+LUKS+LVM by adding support for the “crypto-lvm” keyword, reusing the logic of the initial_auto_raid_lvm script, inserting parts of the logic of the autopartition-crypto script in there. Tests confirm this seems to be working fine, but I wouldn't call this bulletproof just yet. That being said, it cannot really break existing use cases, so I'm tempted to include this feature right away. https://salsa.debian.org/installer-team/partman-auto-raid/-/commits/lvm-on-luks-on-raid While looking at the implementation, I noticed that partman-auto-raid doesn't declare partman-auto-lvm in its Depends despite using its auto-lvm.sh, so I didn't add partman-crypto to Depends despite using its crypto-base.sh. This seems to be working fine anyway, using either a netboot-gtk build or a full-blown netinst build. Example usage with two disks, having only /dev/sda partitioned, and the entirety of /dev/sdb added to the RAID 0 array, alongside the 4th partition of the first disk: d-i partman-auto/disk string /dev/sda d-i partman-auto/method string raid d-i partman-auto-raid/recipe string 0 2 0 crypto-lvm - /dev/sda4#/dev/sdb . complemented with partman-auto/{choose,expert}_recipe regarding the actual partitioning of /dev/sda using those methods: - biosgrub - efi (fat32, /boot/efi) - format (ext2, /boot) - raid and of course LV definitions. This approach means that all existing settings are still considered as usual, like those for LUKS: d-i partman-crypto/confirm boolean true d-i partman-crypto/passphrase string password d-i partman-crypto/passphrase-again string password d-i partman-crypto/weak_passphrase boolean true d-i partman-auto-crypto/erase_disks boolean false (I decided to also reuse the partman-auto-crypto one despite doing the work from partman-auto-raid, but it's trivial to adjust if desired; that's only meant to be preseeded anyway, no strings attached. That being said, the existing RAID+LVM support is very similar, since partman-auto-lvm/* settings are considered even if partman-auto/method is set to “raid” and partman-auto-raid is doing the heavy lifting, see below.) That also applies for LVM: d-i partman-auto-lvm/guided_size string max d-i partman-auto-lvm/new_vg_name string main d-i partman-lvm/confirm boolean true d-i partman-lvm/confirm_nooverwrite boolean true d-i partman-lvm/device_remove_lvm boolean true I plan on polishing and sharing some complete preseed example later on, and possibly adding a pointer from the example preseed that's published in the installation guide (and therefore on the website). That partman request was submitted to me a while back but I've chosen to prioritize other topics until now, since those were beneficial to virtually everyone and needed to be worked on in a timely fashion: non-free-firmware, Alpha and RC releases, also trying to get a greater autonomy with debian-cd and debian-ftp so that we could accommodate whatever might be needed or preferred by the kernel team and the release team as far as timings go (which seems pretty important the closer we get to the tentative release date). Since we've spent quite some time fixing and improving LUKS support, I would hate it if we didn't consider building on it and including this change in Bookworm. As far as I can tell, there are virtually no changes to existing code path (except for the keyword addition), so that seems very low risk. Cheers, -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
