Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Samuel Thibault]

Pascal Hambourg, le mar. 04 juil. 2023 08:09:33 +0200, a ecrit:
> but AFAIK manual partitioning does not allow to create a partition
> table on a RAID array.

Yes, but after creating the RAID array, one can use guided partitioning
and point it at the RAID disk, and that'll happily partition it and put
an EFI partition there (see #1040266), and then grub-installer just
fails and the user is at a loss without understanding why when they
don't notice that an EFI partition was added inside the RAID array.

> > It's fine to have an EFI partition inside a RAID array. One “just” needs
> > to pass --no-nvram and to register it manually. That's not something
> > that's achievable via d-i at the moment though (unless recent changes in
> > grub-installer, near the end of the bookworm release cycle) made it
> > possible indirectly.

Ok, but the warning still seems precious to me. And it it might hint
that possibility (and the warning won't prevent the user from doing it).

Samuel

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Cyril Brulebois]

Pascal Hambourg  (2023-07-04):
> On 04/07/2023 at 03:24, Cyril Brulebois wrote:
> > It's fine to have an EFI partition inside a RAID array. One “just” needs
> > to pass --no-nvram and to register it manually. That's not something
> > that's achievable via d-i at the moment though (unless recent changes in
> > grub-installer, near the end of the bookworm release cycle) made it
> > possible indirectly.
> 
> Any pointer to these recent changes ?

kibi@tokyo:~/debian-installer/packages/grub-installer (master=)$ git log -p 
-Gno-nvram
→ 0007c1296f202fff8e84640d4e1737502690ca46


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


signature.asc
Description: PGP signature

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Pascal Hambourg]

On 04/07/2023 at 03:24, Cyril Brulebois wrote:

Samuel Thibault  (2023-07-04):

As pointed out in #1040266, when using guided partitioning inside a
raid, partman-auto creates an EFI partition there, and then grub-install
fails because it can't register it. This error could also happen if a
user creates by hand an EFI partition inside the raid by mistake. Just
like partman-efi warns when no EFI partition is defined, it should also
warn when an EFI partition is defined inside a raid or lvm (thus
actually unreachable from EFI).


FWIW a long ime ago I submitted a MR to allow EFI partitions only on 
disk labels which support the ESP flag (i.e. not the "loop" disk label 
used on LVM logical volumes and unpartitoned RAID arrays). It won't 
prevent an EFI partition in a partitioned RAID array, but AFAIK manual 
partitioning does not allow to create a partition table on a RAID array.



It's fine to have an EFI partition inside a RAID array. One “just” needs
to pass --no-nvram and to register it manually. That's not something
that's achievable via d-i at the moment though (unless recent changes in
grub-installer, near the end of the bookworm release cycle) made it
possible indirectly.


Any pointer to these recent changes ?

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Cyril Brulebois]

Samuel Thibault  (2023-07-04):
> As pointed out in #1040266, when using guided partitioning inside a
> raid, partman-auto creates an EFI partition there, and then grub-install
> fails because it can't register it. This error could also happen if a
> user creates by hand an EFI partition inside the raid by mistake. Just
> like partman-efi warns when no EFI partition is defined, it should also
> warn when an EFI partition is defined inside a raid or lvm (thus
> actually unreachable from EFI).

It's fine to have an EFI partition inside a RAID array. One “just” needs
to pass --no-nvram and to register it manually. That's not something
that's achievable via d-i at the moment though (unless recent changes in
grub-installer, near the end of the bookworm release cycle) made it
possible indirectly.


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


signature.asc
Description: PGP signature

Re: Proposal: change Japanese font for GUI installer

[Cyril Brulebois]

Hi,

Kentaro HAYASHI  (2023-06-30):
> To solve this issue, I've tried the following steps.
> 
> Step 1: Bundle MotoyaLCedar (MTLc3m.ttf) for fonts-android-udeb.
>MTLc3m.ttf itself is included fonts-android source archive,
>but not shipped as a udeb yet.
> Step 2: Apply PoC patch for cdebconf package to use MotoyaLCedar.
>The actual patch file is attached to #1037256.
> Step 3: build cdimage with build_netboot-gtk
> 
> Here is the Pros and Cons:
> 
> Pros:
>   * Fix longstanding Japanese glyph (typeface) rendering issue
> which is introduced since Debian 9 (stretch).
>   * No side effect for other languages.
> 
> Cons:
>   * Increase image size a bit. +1.9MB

I'm interested in fixing this issue but before doing so, I'd like us to
take some time to investigate the increased memory pressure we've seen
between Debian 11 and Debian 12, leading to situations where the OOMK
kicks in.


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


signature.asc
Description: PGP signature

Bug#1040267: partman-efi: Should warn about EFI partition inside raid or lvm

[Samuel Thibault]

Source: partman-efi
Version: 101
Severity: normal
Tags: d-i

Hello,

As pointed out in #1040266, when using guided partitioning inside a
raid, partman-auto creates an EFI partition there, and then grub-install
fails because it can't register it. This error could also happen if a
user creates by hand an EFI partition inside the raid by mistake. Just
like partman-efi warns when no EFI partition is defined, it should also
warn when an EFI partition is defined inside a raid or lvm (thus
actually unreachable from EFI).

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1040266: partman-auto: should not create EFI partition when ran inside software RAID disk

[Samuel Thibault]

Source: partman-auto
Version: 162
Severity: normal
Tags: d-i

Hello,

It took me some time to realize why I was not able to install Debian
with software RAID1 system. The reason is that when I was running the
Guided partitioning on the whole software RAID disk, partman-auto would
create an EFI partition there, and thus even if I had created an EFI
partition outside the RAID, grub would try to use the partition inside
the RAID. If partman-auto wasn't creating an EFI partition inside the
RAID, I wouldn't have had any issue.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1040251: marked as done (debian-installer: Add UTC timezone selection for all locales)

[Debian Bug Tracking System]

Your message dated Tue, 4 Jul 2023 02:45:36 +0200
with message-id <20230704004536.qpnrmiyydzzkx...@mraw.org>
and subject line Re: Bug#1040251: debian-installer: Add UTC timezone selection 
for all locales
has caused the Debian Bug report #1040251,
regarding debian-installer: Add UTC timezone selection for all locales
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 ow...@bugs.debian.org
immediately.)


-- 
1040251: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040251
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-installer
Version: 20230607
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: b...@brentk.io

Dear Maintainer,

   * What led up to the situation?
 When using the text based debian installer, I would like to be able to 
 choose the UTC timezone (etc/UTC) as an option for my timezone. When
 the timezones are displayed for selection, a set of timezones are
 displayed based on the user's locale selection. Users should have the
 option of selecting UTC in addition to the options present in their
 locale.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 When choosing en_us for my locale during installation, I am only presented
 with US specific time zones. If only presenting timezone associated with
 the users locale, UTC should also be present, as folks use UTC in many 
 server deployments, regardless of their actual locale setting.
   * What was the outcome of this action?
 No UTC option is available in the installer.
   * What outcome did you expect instead?
 To have the UTC timezone available in addition to the locale specific 
 timezones.

 In addition to the notes above, if using a preseed file, the timezone can
 be specified regardless of local information. This is specifically for
 interactive text based installation, where the system owner may want to
 use UTC instead of a local time zone.


./brent



-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-9-arm64 (SMP w/1 CPU thread)
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

-- no debconf information
--- End Message ---
--- Begin Message ---
Brent Kolasinski  (2023-07-03):
> Even better. Thanks. Currently in the process of translating things
> from Red Hat land to Debian, and this is now an non-issue with this
> information. Appreciate the responsiveness. 
> 
> I think it is safe to close this item as I have paths forward for what
> I am wishing to accomplish.

Great, doing so then!


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


signature.asc
Description: PGP signature
--- End Message ---

Bug#1040251: debian-installer: Add UTC timezone selection for all locales

[Brent Kolasinski]

Cyril,

Even better. Thanks. Currently in the process of translating things from Red 
Hat land to Debian, and this is now an non-issue with this information. 
Appreciate the responsiveness. 

I think it is safe to close this item as I have paths forward for what I am 
wishing to accomplish.

All the best,

./brent


--- Original Message ---
On Monday, July 3rd, 2023 at 15:31, Cyril Brulebois  wrote:


> 
> 
> Hi Brent,
> 
> Brent Kolasinski b...@brentk.io (2023-07-03):
> 
> > There does seem to be quite a few extra steps involved in the expert
> > install vs the normal install, especially if the only reason you are
> > running expert mode is to just set the timezone to UTC.
> 
> 
> Right. I forgot to mention a middle ground: passing time/zone=Etc/UTC on
> the kernel command line (instead of starting expert install) should give
> you the desired results without going through all those extra steps.
> 
> (That is, stuff you would stash in a preseed file/URL can also be passed
> on the kernel command line. Reading your mails, I'm not sure this is
> known / has been considered already.)
> 
> 
> Cheers,
> --
> Cyril Brulebois (k...@debian.org) https://debamax.com/
> 
> D-I release manager -- Release team member -- Freelance Consultant

Bug#1040251: debian-installer: Add UTC timezone selection for all locales

[Cyril Brulebois]

Hi Brent,

Brent Kolasinski  (2023-07-03):
> There does seem to be quite a few extra steps involved in the expert
> install vs the normal install, especially if the only reason you are
> running expert mode is to just set the timezone to UTC.

Right. I forgot to mention a middle ground: passing time/zone=Etc/UTC on
the kernel command line (instead of starting expert install) should give
you the desired results without going through all those extra steps.

(That is, stuff you would stash in a preseed file/URL can also be passed
on the kernel command line. Reading your mails, I'm not sure this is
known / has been considered already.)


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


signature.asc
Description: PGP signature

Bug#1040251: debian-installer: Add UTC timezone selection for all locales

[Brent Kolasinski]

Hi Cyril,

Expert Installation provides the behavior I was looking for, specifically 
adding the extra option of UTC at the end of local timezones. 

There does seem to be quite a few extra steps involved in the expert install vs 
the normal install, especially if the only reason you are running expert mode 
is to just set the timezone to UTC.

However, I do notice the non-expert installer is opinionated about a lot of 
options vs the expert installer, so if this has been decided as a feature folks 
don't normally use - then I think it is OK to be relegated to the expert 
installer (or have someone just use the preseed with the correct value / set 
the TZ post installation via configuration management or a `dpkg-reconfigure 
tzdata`).

Appreciate the fast response. 

./brent




--- Original Message ---
On Monday, July 3rd, 2023 at 14:37, Cyril Brulebois  wrote:


> 
> 
> Hi Brent,
> 
> Brent Kolasinski b...@brentk.io (2023-07-03):
> 
> > * What led up to the situation?
> > When using the text based debian installer, I would like to be able to
> > choose the UTC timezone (etc/UTC) as an option for my timezone. When
> > the timezones are displayed for selection, a set of timezones are
> > displayed based on the user's locale selection. Users should have the
> > option of selecting UTC in addition to the options present in their
> > locale.
> > * What exactly did you do (or not do) that was effective (or
> > ineffective)?
> > When choosing en_us for my locale during installation, I am only presented
> > with US specific time zones. If only presenting timezone associated with
> > the users locale, UTC should also be present, as folks use UTC in many
> > server deployments, regardless of their actual locale setting.
> > * What was the outcome of this action?
> > No UTC option is available in the installer.
> > * What outcome did you expect instead?
> > To have the UTC timezone available in addition to the locale specific
> > timezones.
> > 
> > In addition to the notes above, if using a preseed file, the timezone can
> > be specified regardless of local information. This is specifically for
> > interactive text based installation, where the system owner may want to
> > use UTC instead of a local time zone.
> 
> 
> Looks like something that should be possible via the expert install
> option. Have you tried that?
> 
> For normal installs and users selecting a country with a unique
> timezone, I'm not sure we want to actively add a prompt to make them
> pick between that unique timezone and UTC… so I think that should only
> happen in expert mode.
> 
> 
> Cheers,
> --
> Cyril Brulebois (k...@debian.org) https://debamax.com/
> 
> D-I release manager -- Release team member -- Freelance Consultant

Bug#1040251: debian-installer: Add UTC timezone selection for all locales

[Cyril Brulebois]

Hi Brent,

Brent Kolasinski  (2023-07-03):
>* What led up to the situation?
>  When using the text based debian installer, I would like to be able to 
>  choose the UTC timezone (etc/UTC) as an option for my timezone. When
>  the timezones are displayed for selection, a set of timezones are
>  displayed based on the user's locale selection. Users should have the
>  option of selecting UTC in addition to the options present in their
>  locale.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  When choosing en_us for my locale during installation, I am only 
> presented
>  with US specific time zones. If only presenting timezone associated with
>  the users locale, UTC should also be present, as folks use UTC in many 
>  server deployments, regardless of their actual locale setting.
>* What was the outcome of this action?
>  No UTC option is available in the installer.
>* What outcome did you expect instead?
>  To have the UTC timezone available in addition to the locale specific 
>  timezones.
> 
>  In addition to the notes above, if using a preseed file, the timezone can
>  be specified regardless of local information. This is specifically for
>  interactive text based installation, where the system owner may want to
>  use UTC instead of a local time zone.

Looks like something that should be possible via the expert install
option. Have you tried that?

For normal installs and users selecting a country with a unique
timezone, I'm not sure we want to actively add a prompt to make them
pick between that unique timezone and UTC… so I think that should only
happen in expert mode.


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


signature.asc
Description: PGP signature

Bug#1040251: debian-installer: Add UTC timezone selection for all locales

[Brent Kolasinski]

Package: debian-installer
Version: 20230607
Severity: wishlist
Tags: d-i
X-Debbugs-Cc: b...@brentk.io

Dear Maintainer,

   * What led up to the situation?
 When using the text based debian installer, I would like to be able to 
 choose the UTC timezone (etc/UTC) as an option for my timezone. When
 the timezones are displayed for selection, a set of timezones are
 displayed based on the user's locale selection. Users should have the
 option of selecting UTC in addition to the options present in their
 locale.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 When choosing en_us for my locale during installation, I am only presented
 with US specific time zones. If only presenting timezone associated with
 the users locale, UTC should also be present, as folks use UTC in many 
 server deployments, regardless of their actual locale setting.
   * What was the outcome of this action?
 No UTC option is available in the installer.
   * What outcome did you expect instead?
 To have the UTC timezone available in addition to the locale specific 
 timezones.

 In addition to the notes above, if using a preseed file, the timezone can
 be specified regardless of local information. This is specifically for
 interactive text based installation, where the system owner may want to
 use UTC instead of a local time zone.


./brent



-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-9-arm64 (SMP w/1 CPU thread)
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

-- no debconf information

Bug#849400: debian-installer: LUKS on rootfs and boot

[Cyril Brulebois]

Jinesh Choksi  (2023-07-03):
> - This bug was raised in 2016.
> 
> - Grub2 added support for accessing LUKS1 partitions in 2011.
> 
> - Between 2016 and 2019 (when cryptsetup defaulted to luks2 -
> https://gitlab.com/cryptsetup/cryptsetup/-/commit/ae90497762bc4e3f04064e0ebbbde8c64bf27c4a)
> the issue described in this bug could have been addressed by removing
> the "Check - Is there a /boot partition for encrypted root?" check.
> 
> - Were there any other factors as to why the check was still valid in
> those 4 years and hence not removed ?

You want “unhelpful”? You got it! The answer is: “yes”.

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


signature.asc
Description: PGP signature

Bug#849400: debian-installer: LUKS on rootfs and boot

[Jinesh Choksi]

On 2023-07-03 00:57 +01:00 BST, "Cyril Brulebois"  wrote:
> Hi,
> 
> Jinesh Choksi  (2023-07-02):
>> The issue is this block of code:
>> https://salsa.debian.org/installer-team/partman-crypto/-/blob/master/check.d/crypto_check_mountpoints#L94-102
>> 
>> This 17 year old "Check - Is there a /boot partition for encrypted
>> root?" is no longer valid.
> 
> It is.
> 
>> Grub2 added support for accessing LUKS1 partitions in 2011 -
>> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=a251b71915e40194d12995dbac9efd787687f988
> 
> Sure, that's known, and there were two talks during Mini-DebConfs in
> 2019 about this and LUKS2 (Marseille, Hamburg).
> 
>> Grub2 support for LUK2 is also present but only for PBKDF2 keys -
>> https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755
> 
> And since default LUKS2 settings are argon2id (argon2i previously), that
> means that cannot work.
> 
>> For people who use LUKS1 to do full disk encryption, this "Check - Is
>> there a /boot partition for encrypted root?" is a blocker in the
>> Debian installer.
> 
> People finding their way to use LUKS1 instead of the default LUKS2 can
> remove this check on their own.
> 
>> Dear maintainer(s), please review this bug report and remove this
>> check.
> 
> Not until GRUB gets support for argon2i{d,}. And that's where my focus
> is right now when it comes to d-i vs. LUKS.
> 
> PoC at https://salsa.debian.org/kibi/grub/-/commits/luks2-argon2-v0
> but I have better plans to investigate.
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
> 



Unhelpful and disappointing that users who need to setup FDE in Bookworm have 
to jump through hoops.

To the future reader(s), setting up FDE in Bookworm as it is now, with luks1 
can be achieved via the following (assuming disk = /dev/sda):

- Perform an Expert Install

- Choose manual disk partitioning

- Setup a GPT partition table

- Setup an EFI partition (min 100MB), mounted as /boot/efi

- Setup a DMCRYPT partition using remaining free space. (i.e. Physical volume 
for encryption)

- Choose to "Configure encrypted volumes"

- Set a password for the encrypted volume

- Switch to TTY2, activate console and type in: (you need to do the following 
as cryptsetup defaults to luks2 (since 2019) and the installer doesn't provide 
options to select which luks format to use)

  - cryptsetup luksClose sda2_crypt

  - cryptsetup luksFormat --type luks1 /dev/sda2

  - cryptsetup luksOpen /dev/sda2 sda2_crypt

- Select "Go back", and select "Detect Disks" (needed to refresh partman's 
state)

- Select "Partition Disks" again

- Set the file system for the encrypted volume to "physical volume for LVM". 
You need to do this because of the issue mentioned in this bug. By using LVM, 
it bypasses the issue in this bug. Even though you don't actually need LVM. The 
alternative suggested by the D-I release manager is to remove the following 
block of code in the /lib/partman/check.d/07crypto_check_mountpoints file 
before you finalise your partitioning:

--snip--
# Check - Is there a /boot partition for encrypted root?
if [ $crypto_root = yes ] && [ $have_boot = no ]; then
templ="partman-crypto/crypto_root_needs_boot"
db_set $templ false
db_fset $templ seen false
db_input critical $templ
db_go || true
exit 1
fi
--snip--

- Select "Configure the Logical Volume Manager"

- Create a volume group e.g. vgDEBIANVM

- Create a logical volume for '/'' e.g. lvROOT

- (optional) Create logical volume for '/home' e.g. lvHOME

- Create logical volume 'swap' e.g. lvSWAP

- Set up the file system and mount point for the above logical volumes as 
required and finalise partitioning.

- Proceed with installation as normal until you get to the "Install Grub Boot 
Loader" stage. You will find that this stage errors at the "grub-install 
(dummy)" step.

- If you look at msgs on TTY4, you will note it says to add 
GRUB_ENABLE_CRYPTODISK=y. Switch console on TTY2 and edit 
/target/etc/default/grub file and add this line. 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925134)

- Run the "Install Grub Boot Loader" stage again and it will work and rest of 
the install will progress normally.



Dear Maintainer,

- This bug was raised in 2016.

- Grub2 added support for accessing LUKS1 partitions in 2011.

- Between 2016 and 2019 (when cryptsetup defaulted to luks2 - 
https://gitlab.com/cryptsetup/cryptsetup/-/commit/ae90497762bc4e3f04064e0ebbbde8c64bf27c4a)
 the issue described in this bug could have been addressed by removing the 
"Check - Is there a /boot partition for encrypted root?" check.

- Were there any other factors as to why the check was still valid in those 4 
years and hence not removed ?

Bug#1040224: cdebconf: confmodule cannot be sourced by scripts that use `set -u`

[Gioele Barabucci]

Package: cdebconf
Version: 0.270
Tags: patch

Dear cdebconf maintainers,

cdebconf's `confmodule` cannot be sourced by scripts that turned on 
strict variable handling via `set -u`, similarly to what is reported in 
#369953 for classic debconf.


A patch to fix this this problem can be found at 
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/21
(extracted from 
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/19).


Regards

--
Gioele Barabucci

Bug#1040216: cdebconf: confmodule: Erranous behaviour if IFS does not start with a space during db_*

[Gioele Barabucci]

Package: cdebconf
Version: 0.270
Tags: patch

Dear cdebconf maintainers,

in confmodule, the command arguments are passed to cdebconf via

IFS=' ' printf "%s\n" "$*"

That command-local assignment of IFS affects the way printf works, but 
not the way in which "$*" is expanded by the shell: "$*" will be still 
expanded using the IFS of the calling shell.


Example of this fault behavior:

$ dash -c 'IFS="."; set -- a b c; IFS=" " printf "%s\n" "$*"'
a.b.c.

This means that any db_foo command will fail if the calling shell's IFS 
does not start with a space, e.g. `IFS=$'\n'; while read foo; do ... 
do_foo ...; done`.


A patch to fix this this issue is available at 
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/20


(extracted from 
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/19)


Regards,

--
Gioele Barabucci