Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Tyler Riddle]

>
> aren't as trivial as you seem to think they are


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.

On Tue, Apr 22, 2025 at 5:10 PM Cyril Brulebois  wrote:

> Tyler Riddle  (2025-04-22):
> > 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?
>
> I've just explained that efforts required to support that aren't as
> trivial as you seem to think they are.
>
> > > 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.
>
> 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,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Cyril Brulebois]

Tyler Riddle  (2025-04-22):
> 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?

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

> > 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.

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Tyler Riddle]

>
> That would mean a new feature, localization, plus long term maintenance


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.

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.



On Tue, Apr 22, 2025 at 3:23 PM Cyril Brulebois  wrote:

> Tyler Riddle  (2025-04-22):
> > 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
>
> 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.
>
> > 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.
>
> That would mean a new feature, localization, plus long term maintenance,
> in addition to “very minimal level of overhead” for everyone.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Cyril Brulebois]

Tyler Riddle  (2025-04-22):
> 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

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.

> 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.

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


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Tyler Riddle]

>
> 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


 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-


 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 
wrote:

> 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.
>
> > I agree that using the physical volume block device name is bad
> > because this name may not be persistent.
>
> 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.
>
> On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois  wrote:
>
>> Hi,
>>
>> Pascal Hambourg  (2025-04-20):
>> > 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 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,
>> --
>> Cyril Brulebois (k...@debian.org)
>> D-I release manager -- Release team member -- Freelance Consultant
>>
>

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Cyril Brulebois]

Pascal Hambourg  (2025-04-21):
> > On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois  wrote:
> > > Pascal Hambourg  (2025-04-20):
> > > > 
> > > > 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 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.

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

> Some MRs which aim to fix more severe bugs are much older, even older
> than bookworm release.

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


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: Re: Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 partman-crypto 131
Bug #1103706 [debian-installer] debian-installer: Allow user to specify label 
for LUKS devices setup during install
Bug reassigned from package 'debian-installer' to 'partman-crypto'.
Ignoring request to alter found versions of bug #1103706 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1103706 to the same values 
previously set
Bug #1103706 [partman-crypto] debian-installer: Allow user to specify label for 
LUKS devices setup during install
Marked as found in versions partman-crypto/131.

-- 
1103706: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103706
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Pascal Hambourg]

Control: reassign -1 partman-crypto 131

On 20/04/2025 at 23:38, Tyler Riddle wrote:

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.


Done.


On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois  wrote:

Pascal Hambourg  (2025-04-20):


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 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.

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Tyler Riddle]

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.

> I agree that using the physical volume block device name is bad
> because this name may not be persistent.

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.

On Sun, Apr 20, 2025 at 3:29 PM Cyril Brulebois  wrote:

> Hi,
>
> Pascal Hambourg  (2025-04-20):
> > 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 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,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Cyril Brulebois]

Hi,

Pascal Hambourg  (2025-04-20):
> 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:
> 

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,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Pascal Hambourg]

On 20/04/2025 at 21:52, Tyler Riddle wrote:

Package: debian-installer


The right package is actually partman-crypto.


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:

Bug#1103706: debian-installer: Allow user to specify label for LUKS devices setup during install

[Tyler Riddle]

Package: debian-installer
Version: Trixie Alpha 1
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: cardboardaardv...@gmail.com, debian-boot@lists.debian.org

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  
2) cryptsetup config --label  
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.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.21-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled