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.