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! > >> 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. 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. 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. -- 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/message/N3WWEJZXAPB7WNMPKOH76XBQQOHSGJ62/
