Feature request for FOG 1.6.x - Support GRUB as UEFI exit mode

[george1421]

FOG has a built in function to use grub as an exit mode. Currently GRUB is only really an option for bios mode. Supporting uefi mode for grub would give us an additional exit mode where refind doesn’t work.

[Sebastian Roth]

@george1421 Definitely a good point to discuss and re-think. The binary we use so far essentially is not plain GRUB but GRUB4DOS 0.4.4 - it’s from 2009 (!) but hey, there really is no later version available.

http://web.archive.org/web/20160406111907/http://diddy.boot-land.net/grub4dos/files/intro.htm

Unlike GNU GRUB, which relies on several Stage files, the Grub4dos functions are built into a single file grldr (or grub.exe if booting from DOS or Linux). grldr can be loaded via an existing operating system - e.g. via the NT loader ntldr during the Windows NT/2000/XP boot process. Alternatively grub4dos code can be written to the mbr or partition boot sector of a device.

I guess it was chosen years ago as one alternative to chainload 32 bit legacy BIOS systems as it is very flexible in its capabilities to load different operating systems from your hard disk.

We chainload GRUB4DOS from iPXE and feed it command line options to try to find and load an OS from disk.

As far as I know there is no GRUB4DOS capable to be loaded on UEFI based systems and so question is, what else can we use to chainload an OS from a hard drive on machined in UEFI mode?

Reading a bit on the web I reckon it’s possible to create GRUB2 binaries to be chainloaded from iPXE and I think I have played with grub-mkstandalone.

A quick test let me build a binary running this command on a Debian 10 UEFI install system: grub-mkstandalone --format=x86_64-efi --output=grub_x64.efi --install-modules="linux normal iso9660 memdisk search part_gpt part_msdos" --modules="linux normal iso9660 search part_gpt part_msdos" --locales="" --fonts="" --themes="" "boot/grub/grub.cfg" -v (derived from 1, 2 and 3)

For building binaries for the other platforms/modes you’d need to install Debian packages grub-efi-ia32-bin and grub-pc-bin…

[george1421]

@Sebastian-Roth I grab the grub2 efi stuff with the FOS usb boot tutorial. The usb boot works for both bios and uefi. I was going to test different combinations with an ipxe menu to see if I could get it the right command line options to get it to boot https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

[george1421]

I’ve made some fundamental progress here. I remember when I was working with trying to secure boot ipxe I had 2 boot loaders the shimx64.efi and grubx64.efi that I collected from the Ubuntu repository. I also grabbed grubxnet64.efi that has network capabilities (but we don’t need that).

I copied grubx64.efi and grub.cfg from the tftpboot area over to fog/service/ipxe directory. The grub.cfg file just had a simple grub menu that allowed me to chain to ipxe.efi (not important since it was just left over code).

In the iPXE menu I created a custom menu with these parameters. The key is the second parameter of imgfetch to place the fetched file into the /grub directory in iPXE’s virtual disk.

imgfetch ${boot-url}/service/ipxe/grub1.cfg /grub/grub.cfg
chain -ar ${boot-url}/service/ipxe/grubx64.efi || goto MENU

With a uefi system I pxe booted into the iPXE menu and ran this menu. It booted grub2 and displayed my grub menu. So the framework of booting into grub2 is possible.

Using that same flow I think I can even load grub modules with something like this (untested). Once the module is loaded into the proper spot then the grub.cfg file can load them.

imgfetch ${boot-url}/service/ipxe/grub/x86_64-efi/net.mod  /grub/x86_64-efi/net.mod 
imgfetch ${boot-url}/service/ipxe/grub1.cfg /grub/grub.cfg
chain -ar ${boot-url}/service/ipxe/grubx64.efi || goto MENU

[Sebastian Roth]

@george1421 While I like the idea of not having to embed the grub.cfg file into the binary - for users’ convenience to be able to edit the file - I would like to have the grub modules within the actual binary (its memdisk). It’s just my guts saying this might be more reliable if modules don’t need to be loaded separately.

[george1421]

@Sebastian-Roth I hadn’t considered that it was possible to build in the drivers into grub. I’ve only seen it used in a plug in module mode. But it is probably a good idea to make the most common ones statically linked. I also do like the idea (from flexibility standpoint) to also include the modules in case the fog admin wants to repurposed the exit mode capabilities.

While its still an idea I’m liking the idea

imgfetch ${boot-url}/service/ipxe/grub1.cfg /grub/grub.cfg

Being able to upload different grub files and still have grub boot it. This adds flexibility for one-off situations and I think we can apply it to refind too (where I started with my config). What I’m thinking is that we could add these exit modes:

GRUB_EFI
GRUB_EFI_CUSTOM1
GRUB_EFI_CUSTOM2
GRUB_EFI_CUSTOM3

And then have the configuration files:
grub_efi_exit.cfg
grub_efi_exit1.cfg
grub_efi_exit2.cfg
grub_efi_exit3.cfg

As delivered from the developers all of the efi_exit files would be configured the same. (this also assumes I can get the grub efi exit mode to work to begin with). But this setup would allow the FOG Admin to write/change the other efi_exit functions to support maybe specific hardware and its specific needs. or to write their own custom GRUB menu to do other things. Its kind of an open format. This concept could be extended to refind too.

Now for 32 bit stuff. I don’t know if the 32 bit uefi needs a different grub file or not. But I think we can leverage iPXE to decide to call the 32 bit or 64 bit versions of GRUB based on the arch function in iPXE. Actually that could be extended to the bios compatible version of GRUB too (said without testing). Just a simple iPXE conditional test could direct the 32 bit or 64 bit versions.

As long as we are talking about exit modes, it would be interesting to have an iPXE exit mode too. I can’t think of a use case at the moment, but lets say you wanted to write your own custom iPXE menu to do something after FOG exits. If you could chain to an iPXE menu, that would be interesting.

That IPXE_EFI exit mode could be as simple as

chain -ar ${boot-url}/service/ipxe/ipxe_efi.ipxe || goto MENU

One last bit, I wonder if these exit modes should be housed in a table and not hard coded into the program. That table could contain the name, exit_command, mode of the exit commands. Where mode=0 for all, 1 for bios and 2 for efi (the numbers don’t matter, its the concept) then in the web ui only show bios and all for the bios exit modes and efi and all for uefi exit modes.

[Sebastian Roth]

@george1421 Sounds pretty good to me so far.

As long as we are talking about exit modes, it would be interesting to have an iPXE exit mode too. […]

chain -ar ${boot-url}/service/ipxe/ipxe_efi.ipxe || goto MENU

Not sure what you want to achieve with this? FOG’s exit types are all meant to chainload the installed OS from the local disk. Because there are many different systems with firmware not behaving all the same we provide different exit types. iPXE itself has a pretty “basic” exit type itself, the iPXE command exit (ref). A fair amount of legacy BIOS systems are able to go back and load the OS from disk after that. But the iPXE are also aware of their exit not working in all cases and propose to use GRUB4DOS (possibly why earlier FOG devs decided to use it in the first place).

So back to my point: Why would you chainload to another iPXE binary again for exiting?

[george1421]

@Sebastian-Roth said in Feature request for FOG 1.6.x - Support GRUB as UEFI exit mode:

So back to my point: Why would you chainload to another iPXE binary again for exiting?

I don’t have a specific use case at the moment. So adding additional features without a specific reason may not be as valuable as I initially throught.

Also I had a setback with grub. For some reason grub isn’t loading the config file that is uploaded, but using tftp to connect back to {next-server} (guess) and picking up the grub config file I had there. It is picking up the config file from there, I’m just not sure how it knows where to get the file from. Possibly from dhcp request. I’m still working with it, but grub isn’t quite as dynamic as I would have hoped to find uefi boot partitions.