On 06/21/2018 05:19 PM, Chris Murphy wrote: > On Thu, Jun 21, 2018 at 2:28 PM, Kyle Marek <psppsn96@xxxxxxxxx> wrote: >> On 06/21/2018 03:07 PM, Chris Murphy wrote: >>> On Thu, Jun 21, 2018 at 11:12 AM, Kyle Marek <psppsn96@xxxxxxxxx> wrote: >>> >>>> I would greatly appreciate a move to a uniform GPT+EF02+EF00 >>>> partitioning default with a shared boot loader config. >>> An ESP on BIOS is perhaps weird when making so much of this booting >>> and startup stuff user facing; but it's actually integrated in the >>> Matthew Garrett derivative of the BootLoaderSpec and is used as $BOOT. >> I suppose it is weird without the context of EFI, but there's no reason >> for it to cause issues. > Weird is better than inconsistency! Agreed. >>> In ancient times, there were some BIOS firmware floating about that >>> would face plant on encountering GPT, we tried it by default and it >>> caused too many problems and had to be reverted but that was long >>> enough ago it's possible such hardware is quite rare. >> Wow, that really sucks, especially since most GPTs implement a >> compatibility/protective MBR, anyway. >> >> There's really no reason for this behavior to exist, but since it >> did/does (and since it should be a minority), would it be reasonable to >> invert the logic regarding inst.gpt? (default to GPT and use MBR only if >> "inst.mbr" is set). I would think this is fair because the >> choking-on-GPT issue really is more of a firmware bug than something >> that should be treated as the lowest-common-denominator. > Likely old hardware no longer getting firmware updates. And since GPT > is a creation of the UEFI spec, I don't know whether BIOS firmware can > be held accountable when splatting upon encountering GPT. I don't > remember why it splats. (When I said earlier "we tried this" that's > the Fedora Royal We, as in Anaconda once switched to GPT by default > and it caused too many problems for blacklisting to resolve.) Since > bugs in the RHBZ are immortal, there might be a hint buried in the bug > archive. There's also a hint here: > > /usr/share/doc/syslinux/gpt.txt > > I've got way too much experience with the madness of hybrid MBR on > Macs using "Bootcamp" to support Windows; I want all of those weeks of > time refunded to me. This is a huge FUUUCK NOOOO! > > But the new protocol section of that file is eyebrow raising. This > mbrgpt.bin thing is not new, it's been around a while, and makes me > wonder if the "bug" was originally in GRUB's initial jump code written > to the first 440 bytes of LBA 0. Huh! This could be a long ago solved > problem by now, as it's never been revisited in Fedora land. If it helps, I've only ever used GRUB on GPT when installing to BIOS systems. I haven't encountered *any* issues so far. > Anyway, as for GPT by default and inst.mbr as the fallback - the > problem is that a failure puts the user into a black hole. It's > totally opaque to them that they'd need to use inst.mbr to get out. > I'd rather fail safe. Fail danger is only OK if the alternative is > fail guaranteed. No I think we're obligated to demonstrate on X number > of models known to splat with Fedora 18/19 (or whatever it was) GRUB + > GPT, no longer splats with Fedora 28/29 GRUB +GPT. >From my own experience, I really feel as if this issue doesn't exist anymore. However, for machines where it might, I think that good documentation might be enough to mitigate the black hole issue. In addition, decisions about default partitioning really only apply to new installs on unpartitioned disks. All I am trying to say here is that initial failure to install doesn't exactly result in a loss of anything. Please correct me if I am wrong. > And in any case before that time, it should be simple to pass inst.gpt > within the Fedora compose system to get VM images that always use GPT. > I've never heard of a VM BIOS having this bug, but if it's true it > should be and can be fixed. >> There's also the issue that a lot of PXE firmwares boot BIOS-only on EFI >> machines. Personally, I address this by loading iPXE off of a flash >> drive, but for organizations that can't/won't do this, it would be >> useful to make an EFI-capable install even if the installer was booted >> with BIOS for this reason. >> >>> OK anyway, I don't see broad BLS consensus forming yet, but I do see >>> two items that aren't controversial and could move forward as part of >>> this feature proposal: >>> >>> a. Consistent $BOOT/loader/entries for UEFI and BIOS where $BOOT is >>> the ESP on UEFI, and $BOOT is "other" on BIOS (most likely the >>> existing /boot ext4 volume currently used). i.e. do not put >>> /loader/entries in /EFI/fedora >> By "consistent", do you mean that both EFI and BIOS boot loaders will >> reference the same entry files? I like that. > Yes. > >> However, I don't like the entries existing on ESP mostly because of the >> use case of md-RAID for /boot referenced in another thread. I think it >> would be best to just put the GRUB EFI file on ESP and put the rest of >> the bulk GRUB stuff in its utility partition (which may be RAID-ed). > Right. The config + kernel + initramfs on traditional /boot can make > use of software raid, depending on static one time proper > configuration of each member drive's ESPs and now the ESPs never need > to be touched and thus not sync'd. > > Whereas constantly changing the ESP, means we need some way to > establish a master and rsync to the extras. > >> I think GRUB using its own partition is fair especially because GRUB >> isn't an EFI-only bootloader. >> >>> b. If GPT, installer always creates both EF02 and EF00 partitions. For >>> creating VM images, I think it's sane if the anaconda inst.gpt option >>> is always used to make sure the image is created with GPT >>> partitioning, thereby making sure they get EF02 and EF00. >> EF02 and EF00 good. I would prefer if this wasn't an EFI-only >> conditional due to my above responses. > Right. But I think there is some minimal burden to figure out if GRUB > now conforms to the protocol mbrgpt.bin does and some reasonable > assurance the problem Fedora originally ran into is fixed, or that the > problem is moot. There was a lot to digest with the above and the GPT-default-splatting part. Just for clarification, are you "completely" opposed to installing GPT on BIOS systems by default *until* there is reason to believe that the issues described were now-fixed GRUB bugs? Beyond the benefit of being able to boot EFI and GPT by default, there is also the benefit of not storing GRUB in the gap before the first MBR partition (I think this is *especially* eyebrow raising on the MBR side of things), and the benefits of having GPT in general such as a lack of a partition limit, backup partition table, and support for drives larger than 2 TiB (though it needs to be noted that the partitions that need to be accessed with BIOS calls need to exist within the first 2 TiB, or 8 GiB for compatibility with really stupid/old BIOSes). Once the GPT-splatting issue is better understood, I really think that if GPT-by-default can be considered at all, it should be. _______________________________________________ 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/message/QGPZA5R36ACTQLCRSBW73VJGQCYVZGED/
