Re: grub2 BIOS booting iso and code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 26, 2022 at 5:17 PM Thomas Schmitt <scdbackup@xxxxxxx> wrote:
>
> Hi,
>
> Brian C. Lane wrote:
> > If this fixes the boot issues with the XPS 15 then it's probably worth
> > using this instead of the 'clean' GPT method and then revisit later once
> > BIOS support finally goes away.
>
> (Now i am not sure whether i shall hope for a significant test result.)
>
> It should be noted that Ubuntu publishes 'nearly clean' GPT with boot
> flag MBR partition since a year. 22.04 is out and still bears this layout.
> So there are not many machines around which suffer from the yet unknown
> particular demand of the Dell XPS 15 L502X.
>
> I am still pondering what to try next when the experiment results are in.
>
> If test_oldlayout.iso boots, then the next step would possibly to deface
> the GPT of boot-grub2-f36.iso by changing the type of MBR partition 1 from
> 0xEE to 0x83 or 0x00. If that does not boot, then i would ask for setting
> the boot flag of partition 1.
> (These are not proposed solutions. The experiments shall just tell what
> exactly the BIOS expects and does not get from boot-grub2-f36.iso.)
>
> If test_oldlayout.iso does not boot, then i am quite clueless.
> I doubt that the heavily illegal GPT partition for the overall ISO in
> the old Fedora ISOs does the trick.
> I also doubt that the presence of the macboot.img is significant for a
> legacyBIOS. It is mentioned with type 0x00 in the MBR partition table
> and as "Apple UFS" in GPT.
>
> So only success with test_oldlayout.iso will bring more insight.
> But that might also perpetuate the really undesirable test_oldlayout.iso.
>

I don't know if it's been mentioned, but until very recently, pretty
much all TianoCore based UEFI implementations failed to boot
protective MBR marked GPT partitions. I know this because I fixed that
issue last year[1] when working on hybridizing Fedora Cloud images,
and the issue has existed since at least 2007.

That doesn't mean that all proprietary UEFI implementations retain
this bug from their forked TianoCore implementations that make up
their UEFI codebases, but it would not surprise me if a lot of them
do.

[1]: https://github.com/tianocore/edk2/commit/b3db0cb1f8d163f22b769c205c6347376a315dcd



-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux