On Sun, May 5, 2019 at 5:45 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Sat, May 04, 2019 at 01:35:32PM -0600, Chris Murphy wrote: > > The reason why this bug exists in my opinion is because we're being > > too accommodating to the technical users who want linux multiboot, and > > want Fedora to not step on their bootloader. I'm not convinced that's > > a very good policy anymore. I personally would flip it around and > > forcibly update the bootloader by assuming we own it, and if it turns > > out that's the wrong assumption the injured party is a technical user > > who should be familiar with linux mulit-boot madness and its esoteric > > work arounds. > > This makes the assumption, which was also made earlier in the thread, > that it's somehow impossible to check what bootloader is installed. > Why? My bootloader is happy to tell me its version: > $ bootctl Yes but this is out of scop for the conversation because your bootloader is UEFI, and the bug under discussion is BIOS. On BIOS, there are *three* common stage 1 bootloaders in common use on Linux distros, and there's no room for versioning or signatures in the 440 bytes available for this bootloader. The only way to know what we're dealing with, is to read and parse those 440 bytes, and find out where and what they jump to and then parse that stage 2 code. As an example of common: openSUSE uses (or at least used to, it's been a couple years since I checked this) the syslinux mbr.bin as their stage 1 bootloader, and they use GRUB as their stage 2 bootloader. As for version, GRUB has a version.mod but you have to be running GRUB in the pre-boot environment to run it. There is no checker for what is actually installed or who installed it. The facility doesn't exist. I don't know why. Considering there's maybe one downstream that provides an unmodified upstream, and everyone else provides heavily modified GRUB such that referencing an upstream version is pointless, you'd need a facility to inject a version+signature for the distribution's naming scheme to know what the installed binary actually is. And that includes Fedora, whose GRUB has hundreds of patches on top of upstream. > ... > Current Boot Loader: > Product: systemd-boot 241-565-g43d51bb > Features: ✓ Boot counting > ✓ Menu timeout control > ✓ One-shot menu timeout control > ✓ Default entry control > ✓ One-shot entry control > File: /EFI/systemd/systemd-bootx64.efi > ... > Nowadays it's gives the exact git commit it's built from, in the past > it was just the release version, but either is enough. Therefore > 'bootctl update' can fairly reliably *update*, i.e. do the installation > if the thing we have is newer than the version already installed. There's definitely no room for this in stage 1 bootloaders. There might be (I'm not sure) enough room to reference a package in the stage 2 bootloader, so that we know what distro and their version of the bootloader it is, at least know that it's not ours. But the ship has sailed. This capability needed to be in Fedora 5 years ago. > In case of grub and MBR things are a bit more involved, but I don't > think there's any significant technical limitation to doing the same > check and conditional installation. It is insufficient to check the stage 2 bootloader. You have to start at the beginning, LBA 0, and follow it just like the computer does. You can't work backwards. Both the 1MB MBR gap, and 1MB GPT BIOSBoot partition are big enough to contain multiple stage 2 bootloaders, and grub-install has a facility to avoid stepping on stage 2 bootloader in those locations if it can. So that stage 2 is written, and then it writes out a custom stage 1 bootloader in LBA 0 that tells the computer specifically what LBA to jump to in either the MBA gap or BIOS Boot partition. If you have a checker to look in those two locations, and it finds two or more stage 2 bootloaders, which one is the currently use one? You don't know. You have to read LBA 0 and parse it. Multiboot on BIOS was always this much of a clusterfuck. -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
