> Hi Mario, thanks for joining the conversation. > The system in which I'm testing is a Precision T3620 with the very last > firmware 2.15.0 (published in mid 2020). It seems that this is affecting a lot > of Dell's BIOSes: > [1]: https://www.dell.com/community/Linux-Developer-Systems/Linux-EFISTUB/td- > p/4586378 > [2]: https://www.dell.com/community/Laptops-General-Read-Only/Dell-UEFI- > implementation-does-not-support-Linux-Kernel-EFISTUB/td-p/5185272 > [3]: https://bbs.archlinux.org/viewtopic.php?pid=1753169#p1753169 > [4]: https://github.com/xdever/arch-efiboot > Thanks, I'll bring this to some folks internally to discuss. I can't make any promises for this type of change. I do want to mention that your system as well as all of those in the linked posts are older system that I understand don't run the same firmware code base as current systems. So it's entirely possible that the issue doesn't exist in current systems. If anyone else on the mailing lists is also seeing this on some more recent stuff running the newer firmware code base (Like XPS 7390 or XPS 9300) it would be really helpful. You can tell you're running a system with the newer firmware code base by what the setup looks like. This is the older stuff: http://kbimg.dell.com/library/KB/DELL_ORGANIZATIONAL_GROUPS/DELL_GLOBAL/Content%20Team/Restructuring%20of%20USB%20and%20Thunderbolt%20settings%20on%20new%20BIOS%20version%2002.jpg This is the newer stuff: https://www.dell.com/support/article/en-uk/sln322323/xps-13-7390-and-7390-2in1-external-display-limitations-in-pre-boot-environments?lang=en > > > > > > I guess the other option if Ard chooses not to adopt a quirk for this > > > described behavior is to use shim to load the kernel efistub, and let > > > it do the split for you. > > We can circumvent this bug in several ways (using GRUB, packing > kernel plus initrd into a single EFI file, etc.) but honestly, I'd like to > have > the same loading scheme in all my machines. As Arvin stated, and I share > his statement, section 3.1.3 of the UEFI standard is clear: > "The remaining bytes in the load option descriptor are a binary data buffer > that is passed to the loaded image. If the field is zero bytes long, a NULL > pointer is passed to the loaded image. The number of bytes in OptionalData > can be computed by subtracting the starting offset of OptionalData from total > size in bytes of the EFI_LOAD_OPTION".
