LWN: Comments on "Garrett: Booting with EFI" https://lwn.net/Articles/451690/ This is a special feed containing comments posted to the individual LWN article titled "Garrett: Booting with EFI". en-us Wed, 15 Oct 2025 17:43:48 +0000 Wed, 15 Oct 2025 17:43:48 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net Garrett: Booting with EFI https://lwn.net/Articles/454182/ https://lwn.net/Articles/454182/ breakneck <div class="FormattedComment"> I followed your instructions and was unable to get PXE boot to work using RHEL 6.1 (it just dumps me to the GRUB shell).<br> <p> I finally thought to look at the traffic with Wireshark and saw some strange behavior. bootx64.efi transfers successfully, but then when it tries to download the GRUB config file, it requests a filename which includes the client's MAC address. It doesn't make a request for "default" or "efidefault". If I change my config filename to the filename it's looking for, PXE boot starts working great. <br> <p> Is there a setting to specify where my config file is located?<br> <p> Here's some info about my setup:<br> <p> ------------------------<br> Wireshark log for TFTP request:<br> -------------------------<br> No. Time Source Destination Protocol Length Info<br> 700 4.829030 192.168.100.53 192.168.100.100 TFTP 108 Read Request, File: /86800000-0011-0010-0080-E06995883282, Transfer type: octet, tsize\000=0\000, blksize\000=512\000<br> <p> ------------------------<br> /var/log/messages log file:<br> -------------------------<br> Aug 4 18:47:18 red dhcpd: DHCPDISCOVER from e0:69:95:88:32:82 via eth1<br> Aug 4 18:47:19 red dhcpd: DHCPOFFER on 192.168.100.53 to e0:69:95:88:32:82 via eth1<br> Aug 4 18:47:21 red dhcpd: DHCPREQUEST for 192.168.100.53 (192.168.100.100) from e0:69:95:88:32:82 via eth1<br> Aug 4 18:47:21 red dhcpd: DHCPACK on 192.168.100.53 to e0:69:95:88:32:82 via eth1<br> Aug 4 18:47:21 red in.tftpd[9493]: RRQ from 192.168.100.53 filename BOOTX64.efi<br> Aug 4 18:47:21 red in.tftpd[9493]: tftp: client does not accept options<br> Aug 4 18:47:21 red in.tftpd[9494]: RRQ from 192.168.100.53 filename BOOTX64.efi<br> Aug 4 18:47:22 red in.tftpd[9495]: RRQ from 192.168.100.53 filename BOOTX64.efi<br> Aug 4 18:47:22 red in.tftpd[9496]: RRQ from 192.168.100.53 filename /86800000-0011-0010-0080-E06995883282<br> Aug 4 18:47:22 red in.tftpd[9497]: RRQ from 192.168.100.53 filename //86800000-0011-0010-0080-E06995883282<br> Aug 4 18:47:22 red in.tftpd[9498]: RRQ from 192.168.100.53 filename //86800000-0011-0010-0080-E06995883282<br> Aug 4 18:47:22 red in.tftpd[9499]: RRQ from 192.168.100.53 filename //86800000-0011-0010-0080-E06995883282<br> Aug 4 19:02:22 red xinetd[9304]: EXIT: tftp status=0 pid=9459 duration=1090(sec)<br> <p> ------------------------<br> 86800000-0011-0010-0080-E06995883282 GRUB config file<br> -------------------------<br> default=0<br> timeout 10<br> title RHEL6<br> root (nd)<br> kernel /rhel/vmlinuz keymap=us lang=en_US method=<a href="ftp://192.168.100.100/RHEL6">ftp://192.168.100.100/RHEL6</a> ip=dhcp noipv6<br> initrd /rhel/initrd.img<br> <p> -------------------------<br> dhcpd.conf<br> -------------------------<br> ddns-update-style none;<br> ignore client-updates;<br> allow booting;<br> allow bootp;<br> subnet 192.168.100.0 netmask 255.255.255.0 {<br> range 192.168.100.50 192.168.100.250;<br> option routers 192.168.100.254;<br> option subnet-mask 255.255.255.0;<br> next-server 192.168.100.100;<br> filename "BOOTX64.efi";<br> }<br> <p> </div> Fri, 05 Aug 2011 02:35:56 +0000 Garrett: Booting with EFI https://lwn.net/Articles/452234/ https://lwn.net/Articles/452234/ pjones <div class="FormattedComment"> In addition to what Matthew said, the boot menu is also not standardized. I think there's some chance we can script some boot menus, if they're compliant with the HII guidelines, but some of them are simply outside the realm of possibility.<br> </div> Wed, 20 Jul 2011 01:14:21 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451842/ https://lwn.net/Articles/451842/ smoogen <div class="FormattedComment"> Oh cool. That will make getting the new Fedora boxes up a lot faster. Currently the boxes are taking forever trying to boot uefi pxe, timing out, trying other things then falling back to internal ethernet pxe. Feels like it takes about 8 minutes to get a box to being able to install.<br> </div> Fri, 15 Jul 2011 22:04:54 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451829/ https://lwn.net/Articles/451829/ pjones IPv4 netbooting should currently work in Fedora/RHEL (look <a rel="nofollow" href="http://fedoraproject.org/wiki/QA:Testcase_UEFI_pxeboot">here</a> for some instructions; this should also be in a future version of the Installation Guide.)<br> <br> IPv6 pxeboot isn't ready just yet. Fri, 15 Jul 2011 20:33:08 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451828/ https://lwn.net/Articles/451828/ pjones <div class="FormattedComment"> That's something I'm looking into for the future, but for various reasons hasn't happened yet.<br> </div> Fri, 15 Jul 2011 20:24:29 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451827/ https://lwn.net/Articles/451827/ UnderScore <div class="FormattedComment"> Can anyone comment on the state of PXE booting and UEFI? I haven't seen much (not that I've really looked hard) about it and it appears that cobbler does not yet support it.<br> Thanks,<br> James<br> </div> Fri, 15 Jul 2011 20:18:02 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451816/ https://lwn.net/Articles/451816/ mjg59 <div class="FormattedComment"> No, because it's simply an application that runs under the EFI shell.<br> </div> Fri, 15 Jul 2011 18:13:49 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451815/ https://lwn.net/Articles/451815/ luto <div class="FormattedComment"> Does the test suite not include things like "intelligently handles the boot menu?"<br> <p> It would be fairly easy to test. Just put three bootloaders in the system partition: EFI/boot/bootx64.efi, EFI/test/a.efi, and EFI/test/b.efi. Set a.efi first in the boot order and b.efi second. Then tell the user running the test to navigate their firmware menu and boot from b.efi.<br> <p> Sadly, even my shiny new Intel board can't do that. You'd think that the inventor of the original EFI spec would get this right. (Of course, the board can't reboot via EFI either. Oh, well.)<br> </div> Fri, 15 Jul 2011 18:10:37 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451814/ https://lwn.net/Articles/451814/ cesarb <div class="FormattedComment"> Would it be possible to have them enhance the test suite to catch these kinds of problems?<br> </div> Fri, 15 Jul 2011 18:05:03 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451813/ https://lwn.net/Articles/451813/ mjg59 <div class="FormattedComment"> The problem is actually that none of the bugs we've hit are in paths exercised by the test suite, either because it doesn't test them or because they only trigger once you've set up non-executable pages or non-1:1 pagetables.<br> </div> Fri, 15 Jul 2011 17:27:53 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451808/ https://lwn.net/Articles/451808/ pjones <div class="FormattedComment"> Not that I know of. As far as I know they use the SCT on uefi.org just like everybody else does.<br> <p> There really isn't anything obviously nefarious going on here.<br> </div> Fri, 15 Jul 2011 17:04:59 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451791/ https://lwn.net/Articles/451791/ hitmark <div class="FormattedComment"> Let me guess, MS has their own test suite...<br> </div> Fri, 15 Jul 2011 15:01:40 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451784/ https://lwn.net/Articles/451784/ n1ho <div class="FormattedComment"> I took a 1TB USB drive and put EFI and GUID partitions on it, and then installed Ubuntu Natty on it with GRUB2. It took a bit of playing around with 'parted' to set everything up just right, but it does work. In fact, I was then able to create multiple partitions on it, and was able to install openSUSE 11.4 and Mageia on two of them. They were slightly confused, but they did install, and I had to remember to 'update-grub' under Ubuntu before being able to actually try to boot either openSUSE or Mageia. However, both Fedora 14 and 15's installer utterly failed to recognize the partitions and crapped out with seg faults when I attempted installations. (Mandriva also worked, but I've since dropped it in favor of Mageia). And, this is all on an Acer Aspire One netbook, not an Apple machine.<br> <p> So, some (slow) progress is being made in the Linux community, but it appears there is a fair amount of distribution-specific work ahead.<br> </div> Fri, 15 Jul 2011 13:50:50 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451782/ https://lwn.net/Articles/451782/ pjones <div class="FormattedComment"> It actually does have this.<br> </div> Fri, 15 Jul 2011 13:39:07 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451779/ https://lwn.net/Articles/451779/ mjg59 <div class="FormattedComment"> Doing so implies overwriting the fallback bootloader that Windows installed, so in a sense you're still messing with it. Probably safely, though.<br> </div> Fri, 15 Jul 2011 13:28:42 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451778/ https://lwn.net/Articles/451778/ proski <div class="FormattedComment"> I think installing a smart fallback bootloader to EFI is still a better idea than messing with a Windows install.<br> </div> Fri, 15 Jul 2011 13:25:22 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451773/ https://lwn.net/Articles/451773/ mjg59 <div class="FormattedComment"> Boot sectors also being something that doesn't exist in EFI :)<br> </div> Fri, 15 Jul 2011 12:13:07 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451745/ https://lwn.net/Articles/451745/ bdonlan <div class="FormattedComment"> And you don't actually register partitions in the windows bootloader, you put a boot sector into a file and pass _that_ to the windows bootloader.<br> </div> Fri, 15 Jul 2011 04:40:00 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451744/ https://lwn.net/Articles/451744/ ringerc <div class="FormattedComment"> It sounds like EFI also needs a better test suite. Don't just boot Windows, boot the EFI test suite image. Require that vendors that claim "EFI support" pass the test suite.<br> <p> If a test suite that checks for all these quirks can be grown over time as issues are discovered, and if there's an incentive for vendors to actually use the test suite, then things might improve. It's not too late in the implementation of EFI to get that sort of thing moving.<br> </div> Fri, 15 Jul 2011 04:04:14 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451732/ https://lwn.net/Articles/451732/ mjg59 <div class="FormattedComment"> Try booting with reboot=a, or wait for 3.0. Some machines appear to assume that they've got a flat address space when rebooting.<br> </div> Fri, 15 Jul 2011 02:22:07 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451730/ https://lwn.net/Articles/451730/ mjg59 <div class="FormattedComment"> ...and the problem is, obviously, to a large extent influenced by a specification that explicitly allows this kind of behaviour while later on disclaiming any responsibility for how operating systems should handle it. The only way to handle that is by having more participation in the appropriate bodies.<br> </div> Fri, 15 Jul 2011 02:20:09 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451727/ https://lwn.net/Articles/451727/ pjones <i>Once again, hardware vendors are myopically focusing on Windows.</i><br> <br> This is a bit hyperbolic - enough to be a somewhat unrealistic assessment. While it is true that there are vendors who don't care about Linux at all, many others do. In general, there's been quite a bit of cooperation in making sure Linux supports UEFI platforms. There could be more, and there have been setbacks; I'm not saying it's a perfect scenario. But at the same time, we, the Linux community, could be much more involved than we currently are.<br> <br> As an example, the UEFI forum holds two plugfests per year; one in North America and one in Asia (where many hardware vendors are). The most recent plugfest was held last week at the Microsoft campus in Redmond, WA. Of Linux vendors, only Red Hat and Canonical sent any representatives whatsoever. The atmosphere was fairly collegial, and nobody *refused* to allow testing of any kind.<br> <br> It's not just hardware vendors that could be communicating and working together better.<br> Fri, 15 Jul 2011 01:52:07 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451713/ https://lwn.net/Articles/451713/ mjg59 <div class="FormattedComment"> You don't boot partitions in EFI.<br> </div> Thu, 14 Jul 2011 22:32:02 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451707/ https://lwn.net/Articles/451707/ elanthis <div class="FormattedComment"> The windows boot loader will quite happily let you add entries to boot from other partitions, which can include ones with GRUB installed.<br> </div> Thu, 14 Jul 2011 21:46:11 +0000 Garrett: Booting with EFI https://lwn.net/Articles/451704/ https://lwn.net/Articles/451704/ jgg <div class="FormattedComment"> I've got a system here I went to the trouble to make boot with EFI, and it is still a big pain. Got it working with Ubuntu Maverick, but when I fresh installed Natty it formatted the EFI partition, which made Windows completely unbootable. Plus I get a kernel oops on reboot every time.<br> <p> Not sure EFI is worth the hassle, but once you've got Windows installed as EFI I think there isn't much choice for Linux - or at least it is even more hassle :|<br> <p> On the plus side, the Asus EFI BIOS seems to work mostly OK, it can EFI boot from USB and AHCI, but curiously not from the on board IDE.<br> </div> Thu, 14 Jul 2011 21:32:39 +0000