On 10/04/2023 at 15:13, Steve McIntyre wrote:
Overall comment: I'm not trying to make the heuristics 100% reliable
here, as I don't think that's actually possible. Instead, I'm trying
to tread the fine line of:
* minimising false negatives - let's try to pick up on the most
common cases where people are dual-booting with other systems and
might not understand the issues here. That's 99%+ going to be
people with Windows installed
* minimising false positives - the issue that angered Cyril in
particular, with an incomplete LVM setup triggering the "bios
bootable OS" warning
IMO it is more important to avoid false positives, because switching to
a BIOS installation on systems which are not BIOS-boot capable would
create a non bootable system. In case oft is easier to install GRUB for
BIOS boot on an running EFI system than the other way around.
- Other BIOS boot loaders such as syslinux/extlinux do not need or use a BIOS
boot partition.
Also not a use case I'm particularly caring about, I'll be
honest. They're also *really* not likely to work well without another
filesystem in use, which I expect we'll detect anyway.
Indeed other partitions are needed and will be detected, but they will
not increment $NUM_NOT_ESP if the disk is GPT and has no BIOS boot
partition (so $DISK_BIOS_BOOT=no), so it might cause a false negative.
So why not just treat MSDOS and GPT disk labels equally and treat BIOS
boot partitions like any other non-ESP ?
1b) IIUC the patch fixes #1033913 because the disk selected for installation
has received a new GPT disklabel without a BIOS boot partition, so further
checking is skipped. But IMO the root cause of #1033913 is that changes are
not committed to disk after setting the 'boot' and 'esp' flags to the newly
created ESP partition before stopping parted_server.
I originally thought about fixing partman-auto-lvm but it appears that
other transient states can also trigger the "force UEFI installation"
dialog during partitioning, for example after setting up LVM in manual
partitioning if there is no ESP partition yet. As discussed in
#debian-boot, a more general fix might be to run the check only once
because only existing partitions before partitioning are relevant. Are
there any use cases for which this might cause a false negative ?
4) It appears that partman fails to detect the specially crafted partition
table on the installation media created with a debian image. Is it intended
or fortunately unintentional ? If partman could see the EFI partition on the
installation media, the detection of BIOS-bootable systems would fail.
That's not a worry for today... :-)
Sure, but the issue can also happen if another removable media is
present. For instance the USB drive I use to provide missing firmware
has an ESP partition (and a regular partition table) thus can cause a
false negative.
