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

Bug#1036347: marked as done (debian-installer: missing support for RAID+LUKS+LVM via preseed)

Your message dated Wed, 24 May 2023 13:31:33 +0200
with message-id <20230524113133.mgbp2aghgre5p4yr@mraw.org>
and subject line Re: Bug#1036347: debian-installer: missing support for RAID+LUKS+LVM via preseed
has caused the Debian Bug report #1036347,
regarding debian-installer: missing support for RAID+LUKS+LVM via preseed
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

1036347: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036347
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: partman-auto-raid
Severity: important
Tags: patch


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.


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

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.

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

--- End Message ---
--- Begin Message ---
Version: 51

Cyril Brulebois <kibi@debian.org> (2023-05-19):
> 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).

The documentation aspect remains to be done, likely after RC 4.

The upload happened; closing this bug report manually as I forgot to add
a reference in the changelog.

Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Attachment: signature.asc
Description: PGP signature

--- End Message ---

Reply to: