Package: debian-installer
when setting up a LUKS device the installer selects a
name based on the block device backing the encrypted storage and I don't see a
way to override or change it. I'm not fond of the naming scheme used to pick the LUKS label so I wind up changing it after install. It's not a huge deal but
I would definitely prefer being able to pick my own label during install instead of having to go back and change it after install.
I agree that using the physical volume block device name is bad
because this name may not be persistent.
FWIW an open merge request proposed a naming scheme based on LUKS
UUID: <https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/9>
I saw a comment about how the feature request belongs in partman-crypto.
I'm happy to re-report this there if that is where it belongs.
On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois <kibi@debian.org> wrote:
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-20):
https://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/9> >>
FWIW an open merge request proposed a naming scheme based on LUKS
UUID:
<
I realize it's been open for a while but I'd rather not change something
like this this late during the release cycle, so it'd be best to look at
it after Trixie is released.
On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois <kibi@debian.org> wrote:
Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-20):
FWIW an open merge request proposed a naming scheme based on LUKShttps://salsa.debian.org/installer-team/partman-crypto/-/merge_requests/9>
UUID:
<
I realize it's been open for a while but I'd rather not change
something like this this late during the release cycle, so it'd be
best to look at it after Trixie is released.
I did not intend to advocate this MR which I consider mostly cosmetic
and quite recent by d-i standards.
Some MRs which aim to fix more severe bugs are much older, even older
than bookworm release.
Not being a fan of having the backing block device be a part of the name
used for the LUKS config using the UUID seems like a very reasonable
change. However, as a sysadmin that has to juggle these things, I would rather not have to type out a UUID when I'm working on a system. Sure cut
and paste is a thing that can be done which helps cut down on the typing
but I am also able to formulate names myself that are shorter, easier to type, and will work for my use cases.
I suggest the following:
1) Change the default name to incorporate the UUID.
2) Update the workflow to prompt the user for their desired name
I think this covers all concerns and imposes a very minimal level of
overhead for users who simply want to accept whatever defaults the
installer may select.
I appreciate that there is development effort associated with features but
my interpretation of what you are saying is that concerns about a LUKS name can be ignored at least in terms of the Debian installer. Is my interpretation incorrect?
Does this mean that concerns regarding long term maintenance would result
in a patch to implement my desired behavior being rejected? Or that to be accepted such a patch would have to not only include the desired change but also all localization requirements to be implemented as well?
That benefits only users who care about that kind of things, so that
really doesn't seem to be a question that should get asked in the
first place.
Are you suggesting that caring about the LUKS name is an irrelevant
detail and such concerns are unreasonable? Please clarify if my
takeaway is incorrect here.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 483 |
Nodes: | 16 (2 / 14) |
Uptime: | 146:51:55 |
Calls: | 9,589 |
Calls today: | 3 |
Files: | 13,676 |
Messages: | 6,148,035 |