Dear Maintainer,

I am using encrypted storage which I setup during install. I also tend to use
the LVM. When I setup a volume group in the installer I am able to specify the
volume group name but 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.

Just to document it, the outline for changing the LUKS label and winding up
with a system that still works is:

1) dmsetup rename <old label> <new label>
2) cryptsetup config --label <new label> <block device backing encrypted
storage>
3) update the contents of /etc/crypttab to change the old label to the new
label
4) update-initramfs -u
5) update-grub

This can be done either as an online operation after first boot when the
install is completed, with an installer shell after the install is done and the
installer is prompting for a reboot, or if you catch the install step at the
right place in the advanced install by launching a shell before a reboot is
prompted. I don't recall exactly where to launch the shell during an advanced
install but it is very late in the process.

This really is just a nice to have but it would definitely be nice to have.

The right package is actually partman-crypto.
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>

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-20):

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.


Cheers,

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.

Notwithstanding the merit of this I wanted to make sure it's understood
this is different from my feature request which would be to change the
installer workflow so that instead of selecting a LUKS label for me the
installer prompts me for what I want the LUKS label to be similar to the
way that the LVM configuration workflow works.

Also thank you for giving my feature request some attention.

Control: reassign -1 partman-crypto 131

Done.

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.

Pascal Hambourg <pascal@plouf.fr.eu.org> (2025-04-21):

Well, given I saw it and it seemed risky to me, I thought I'd say
something about this one in particular.

I'm not quite sure how to reply to that.


Cheers,

 I wanted to expound on my particular feature request of letting the user
select the LUKS name and how that relates to changing the LUKS name to one
based on UUID. From the merge request:

instead of e.g. vda2_crypt, the mapping will be called luks-<uuid>


 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
3) Offer the UUID based name to the user by pre-populating it in the
dialogue box so if they find the name acceptable they can simply confirm it
4) Ensure that the LUKS name is configurable via preseed so automated
installs still allow the user to have the name they want

It may make sense to apply similar changes to the volume group if a user is
setting up LVM via the installer. It certainly seems desirable to me to
have consistent behavior between the LVM and LUKS configuration phases
during install.

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.


On Sun, Apr 20, 2025 at 3:38 PM Tyler Riddle <cardboardaardvark@gmail.com> wrote:

Tyler Riddle <cardboardaardvark@gmail.com> (2025-04-22):

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.

That would mean a new feature, localization, plus long term maintenance,
in addition to “very minimal level of overhead” for everyone.


Cheers,

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


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.

I can somewhat understand such a position when we are talking about the
difference between crypt_sda3 and crypt00 but the pending change to use a
LUKS name based on UUID now brings in the context of .a change that will
increase the length of a LUKS name from around a dozen characters to one
that has more than 40 characters as well as the particular string that
needs to be typed out going from one that can be recreated by glancing at
it to one that would become effectively untypable. Please consider the
burden of getting a UUID into a configuration file if someone is not using
a mouse or otherwise does not have cut/paste available. It's certainly not
impossible but it moves into the realm of becoming a serious hassle and
outright chore.

An exceedingly difficult string to type that is itself a component of
operations that may need to be performed on a system that is in a degraded
state is going to cause problems for people and at a point in time when
they already have enough problems. I already rename the LUKS devices so for
me there will be a slight increase in annoyance related to moving from
crypt_sda3 to crypt_b94cc3fe-b64a-4496-bea7-745736218e6b as a part of my
post install workflow. But such a change, if not possible to be overridden
during install, is going to result in a significant population that
previously didn't care about the LUKS name to ones that will.

Tyler Riddle <cardboardaardvark@gmail.com> (2025-04-22):

I've just explained that efforts required to support that aren't as
trivial as you seem to think they are.

No. I understand this might important to you and a minority of users,
and what I wrote is that the default installation is about the vast
majority of users, who likely don't care at all and shouldn't be
bothered with that question. (Independently of the cost topic mentioned
above.

Don't expect more engagement from my side on either bugs.


Cheers,

I don't recall suggesting any effort was trivial.

 shouldn't be bothered with that question.


You didn't answer my question regarding the viability of a patch to
implement my suggested feature. Though given this statement it sounds like
there is no avenue available to get the suggested feature implemented even
if I were to do it myself and jump through every hoop so nothing more is
required from the D-I team than merging it.

Don't expect more engagement from my side on either bugs.


Ok. I don't particularly recall asking for your specific engagement in this
bug or any other. It appears that the "top down management shall declare
edicts" approach that originated with the move to systemd has grown.

You also didn't answer my question in a personal email to you asking how I
might identify the package specific to any bug report I make with the
installer. No one can force you to be helpful but that seems
counterproductive.

I'm sure as the D-I release manager you are busy but I am also sure the
attitude you have extended to me is poor.