Bug#1092978: debian-installer: netinst installer uses efi partition from another disk

[Ted]

Package: debian-installer
Severity: important
X-Debbugs-Cc: ***@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?

I installed Debian with "GNU/Linux trixie-DI-alpha1 _Trixie_ - Official
Alpha amd64 NETINST with firmware 20241230-11:26" using the luks
encrypted full disk partition scheme. It installed but the installer
used an efi partition from another disk where there was another Debian
installation. When I moved the disk to its real home and tried to boot
the computer looked at me like a dog who was just shown a card trick, it
couldn't boot. I did the luks-encrypted full disk trixie installation
to /dev/sdb.

sda 476.9G
├─sda1 Ra9D0mUuId-C2D0 vfat 258.4M

sdb 223.6G
├─sdb1 73De-s0mE8therUuId vfat 960M /boot/efi

/etc/fstab line before being fixed:

UUID=Ra9D0mUuId-C2D0 /boot/efi vfat umask=0077 0 1


* What exactly did you do (or not do) that was effective (or
ineffective)?

I had to boot a computer from a working Linux installation, decrypt the
encrypted partition, then mount the proper partitions at /mountpoint,
/mountpoint/boot and /mountpoint/boot/efi, then chroot to the system,
edit the fstab to point to the efi partition on the OS disk, then
reinstall grub with "grub-install /dev/sdb" and run update-grub before I could get the new installation to boot on its own.

* What was the outcome of this action?

The system booted normally after I futzed around with it, but a less
experienced user would have given up.

* What outcome did you expect instead?

I expected the installer to choose the efi partition on the target
disk that the installer had just created, not some other random disk's efi partition.

*** End of the template - remove these template lines ***


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

Kernel: Linux 6.12.6-amd64 (SMP w/4 CPU threads; PREEMPT)
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: system

[Pascal Hambourg]

Post by Ted
I installed Debian with "GNU/Linux trixie-DI-alpha1 _Trixie_ - Official
Alpha amd64 NETINST with firmware 20241230-11:26" using the luks
encrypted full disk partition scheme. It installed but the installer
used an efi partition from another disk where there was another Debian
installation.

Possibly a duplicate of #1034208, #1034812, #1041168. Hopefully fixed by
the change proposed in #1092892.

Post by Ted
When I moved the disk to its real home and tried to boot
the computer looked at me like a dog who was just shown a card trick, it
couldn't boot. I did the luks-encrypted full disk trixie installation
to /dev/sdb.

Note that even if the installer had used the correct EFI partition, it
would not have booted on another machine because the EFI boot variables
were not updated on the target machine but on the installing machine
(possibly breaking booting on the other disk).

Post by Ted
I had to boot a computer from a working Linux installation, decrypt the
encrypted partition, then mount the proper partitions at /mountpoint,
/mountpoint/boot and /mountpoint/boot/efi, then chroot to the system,
edit the fstab to point to the efi partition on the OS disk, then
reinstall grub with "grub-install /dev/sdb" and run update-grub

"/dev/sdb" is useless with EFI. By default grub-install uses the EFI
partition mounted on /boot/efi.

[Debian Bug Tracking System]

Your message dated Fri, 17 Jan 2025 22:37:06 +0000
with message-id <E1tYuxe-002hgw-***@fasolo.debian.org>
and subject line Bug#1092978: fixed in partman-efi 108
has caused the Debian Bug report #1092978,
regarding debian-installer: netinst installer uses efi partition from another disk
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 ***@bugs.debian.org
immediately.)