How to set up dhcpd.conf to serve different UEFI files per OS

[Thomas Cameron]

I am trying to kickstart multiple versions of Linux. Some of my systems 
are BIOS based, and some are UEFI based.

I have a stanza in my dhcpd.conf file that looks like this:

         class "pxeclients" {
         match if substring (option vendor-class-identifier, 0, 9) = 
"PXEClient";
         next-server 172.31.100.1;
         if option architecture-type = 00:07 {
                 filename "shim.efi";
                 } else {
         filename "pxelinux.0";
     }
   }

I got the shim.efi I am serving from the tftpboot directory from the 
Fedora 38 shim-x64 package.

The problem is, when I try to kickstart a RHEL machine, it errors out 
saying the shim is invalid.

Is it that the shim.efi file is signed for UEFI environments, and the 
RHEL kernel is expecting the signature for the RHEL shim.efi file? If 
so, how do I specify which shim.efi file I want to use based on the 
kernel? I would assume I'd need to add the correct shim.efi file in 
/var/lib/tftpboot/images/[kickstart_os] the same as I add the vmlinuz 
and initrd.img. But how do I tell the machine being kickstarted where to 
get the correct shim.efi? Is there a vendor-class-identifier I can check 
to see what the OS is, and then point the machine being kickstarted to 
that file?

Or am I going about this the wrong way?

Thomas

[Chris Adams]

Once upon a time, Thomas Cameron <thomas.cameron(a)camerontech.com&gt; said:
>  Is it that the shim.efi file is signed for UEFI environments, and
>  the RHEL kernel is expecting the signature for the RHEL shim.efi
>  file? If so, how do I specify which shim.efi file I want to use
>  based on the kernel? I would assume I'd need to add the correct
>  shim.efi file in /var/lib/tftpboot/images/[kickstart_os] the same as
>  I add the vmlinuz and initrd.img. But how do I tell the machine
>  being kickstarted where to get the correct shim.efi? Is there a
>  vendor-class-identifier I can check to see what the OS is, and then
>  point the machine being kickstarted to that file? 
As far as I can tell, you cannot configure network boot for different
OSes in a UEFI Secure Boot environment.  The shim is loaded first,
before you get to the point of choosing which kernel to boot, and a
given distribution's shim will only load other Linux things signed by
that distribution's key.

It'd be nice if there was a way to chainload one shim from another
(they're all signed by the MS firmware-trusted key, so it seems like
this should be possible and still meet the security requirements), so
you could have a menu option "Switch to RHEL" that would load the RHEL
shim+bootloader, but I don't think that's possible today.  I'm using
grub2 for network book rather than syslinux, but I couldn't figure out a
way to make that work.

The only way to handle it would be to distinguish the clients at the
DHCP server (use separate VLANs, pre-configure MAC addresses, etc.).
Once the DHCP server sends an answer, it's too late to change.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Thomas Cameron]

On 6/4/23 14:40, Chris Adams wrote:
>  As far as I can tell, you cannot configure network boot for
> different
>  OSes in a UEFI Secure Boot environment.  The shim is loaded first,
>  before you get to the point of choosing which kernel to boot, and a
>  given distribution's shim will only load other Linux things signed by
>  that distribution's key.
>
>  It'd be nice if there was a way to chainload one shim from another
>  (they're all signed by the MS firmware-trusted key, so it seems like
>  this should be possible and still meet the security requirements), so
>  you could have a menu option "Switch to RHEL" that would load the RHEL
>  shim+bootloader, but I don't think that's possible today.  I'm using
>  grub2 for network book rather than syslinux, but I couldn't figure out a
>  way to make that work.
>
>  The only way to handle it would be to distinguish the clients at the
>  DHCP server (use separate VLANs, pre-configure MAC addresses, etc.).
>  Once the DHCP server sends an answer, it's too late to change. 
Yeah, that's
why I was hoping there was maybe some magic in the 
vendor-class-identifier response that I could use. It would make life a 
LOT easier.

I've started using cobbler again 
(https://cobbler.readthedocs.io/en/latest/quickstart-guide.html). 
Cobbler was HORRIBLY broken in Fedora 37, but it seems to be fixed in 
38. I do love that, when I set up a distro, it automatically creates the 
grub.cfg file in /var/lib/tftpboot/grub and creates the menu files for 
me. I actually have my kickstarts set up such that I can install Fedora 
38 and RHEL 9, except for this weird shim issue. I guess when I'm going 
to install RHEL machines, I need to copy the RHEL shim.efi to 
/var/lib/tftpboot, and when I'm going to install Fedora machines, copy 
the Fedora shim.efi. It's kind of a pain in the backside. But I can 
script it pretty easily. I just need to remember to run the script when 
I decide to change what I'm installing.

Thanks so much for the answer, I appreciate it, Chris.

-- 
Thomas

[Chris Adams]

Once upon a time, Thomas Cameron <thomas.cameron(a)camerontech.com&gt; said:
>  Yeah, that's why I was hoping there was maybe some magic in the
>  vendor-class-identifier response that I could use. It would make
>  life a LOT easier. 
All the DHCP communication happens before shim is loaded (and then it's
too late to change), so all you can see is the base hardware info.  If
you know your hardware, you could configure MAC addresses in your DHCP
config to control the response, pointing to a different shim/config
depending on which MAC is requesting.

Otherwise, I suppose you might be able to do something odd like serve up
one shim/config via TFTP and a different one via HTTP, so you could
choose UEFI PXE for one OS and UEFI HTTP for the other.  It would
probably be confusing after the fact though.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Joe Zeff]

On 06/04/2023 01:40 PM, Chris Adams wrote:

>  It'd be nice if there was a way to chainload one shim from
> another 
If memory serves, you could have GRUB boot Windows by giving it the 
command chainload +X, where X represented the number of sectors to load. 
  I've no idea if GRUB2 still does this, but if so, it might be what's 
needed.

[Chris Adams]

Once upon a time, Joe Zeff <joe(a)zeff.us&gt; said:
>  On 06/04/2023 01:40 PM, Chris Adams wrote:
>  >It'd be nice if there was a way to chainload one shim from another
>  
>  If memory serves, you could have GRUB boot Windows by giving it the
>  command chainload +X, where X represented the number of sectors to
>  load.  I've no idea if GRUB2 still does this, but if so, it might be
>  what's needed. 
I poked around at that at one point, and couldn't find a way to get it
to chainload another shim from the network.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Barry]

>  On 4 Jun 2023, at 19:43, Thomas Cameron
> <thomas.cameron(a)camerontech.com&gt; wrote:
>  
>  Or am I going about this the wrong way? 
I have always seen this done by having tooling that read a database of hardware mac
addresses mapped to config.

With that setup you “just” edit the database to switch the os you want and rebuild
your dhcpd/tftpd config.

Barry

[Thomas Cameron]

On 6/4/23 16:25, Barry wrote:
>  I have always seen this done by having tooling that read a database
> of hardware mac addresses mapped to config.
>
>  With that setup you “just” edit the database to switch the os you want and rebuild
>  your dhcpd/tftpd config. 
Unfortunately, the vast majority of my systems are virtual
machines, so 
the MAC addresses are dynamically generated. And even with the physical 
servers, I go back and forth between RHEL and Fedora on a pretty regular 
basis. So that MAC address mapping doesn't necessarily stay the same.

I think the easiest thing in my little environment is to write a little 
shell script that copies the RHEL or Fedora shim.efi to 
/var/lib/tftpboot before I kickstart a machine. I suspect that it will 
take a little bit before I do it out of habit, but I install machines so 
frequently for different projects that it will become a habit pretty 
quickly.

I really wish that there was something in the OS that would identify 
itself when it sends a DHCP broadcast. I've read up 
https://kb.isc.org/docs/isc-dhcp-44-manual-pages-dhcp-options and it 
suggested that I add:

set vendor-string = option vendor-class-identifier;

to my dhcpd.conf, and I tried it. But all that I see in the logs when I 
get a dhcp request is:

lease 172.31.100.165 {
   starts 0 2023/06/04 21:55:20;
   ends 0 2023/06/04 22:55:20;
   cltt 0 2023/06/04 21:55:20;
   binding state active;
   next binding state free;
   rewind binding state free;
   hardware ethernet 30:e1:71:51:24:18;
   uid "\0010\341qQ$\030";
   set vendor-string = "anaconda-Linux";
   set vendor-class-identifier = "anaconda-Linux";
}

I feel like there's more info in the dhcp requests than I know how to 
find. Still digging.
-- 
Thomas

[Samuel Sieb]

On 6/4/23 15:00, Thomas Cameron wrote:
>  I really wish that there was something in the OS that would identify
>
>  itself when it sends a DHCP broadcast. I've read up  
The part you're missing is that it isn't the OS that's sending the DHCP 
request.  It's the BIOS.  There's no OS loaded yet, that's what you're 
trying to boot.

[Thomas Cameron]

On 6/4/23 17:12, Samuel Sieb wrote:
>  The part you're missing is that it isn't the OS that's
> sending the 
>  DHCP request.  It's the BIOS.  There's no OS loaded yet, that's what 
>  you're trying to boot.  
The hardware definitely sends a DHCP request when it
tries to PXE boot. 
But when the OS actually loads, it sends a separate DHCP request. I was 
hoping to find that and use it for an if/then/else sort of menu.

But that's probably too late, if I understand the boot and installation 
processes.

Thomas

[Chris Adams]

Once upon a time, Thomas Cameron <thomas.cameron(a)camerontech.com&gt; said:
>  I really wish that there was something in the OS that would identify
>  itself when it sends a DHCP broadcast. 
Again, the DHCP request that gets a response "use this file" comes from
the firmware, not the OS.

It goes something like:

- BIOS/UEFI configured for network boot sends DHCP request
- DHCP server says "use this file (aka shim)"
- BIOS/UEFI loads that file and runs it
- shim loads grub2 or pxelinux, they get their configs/menus
- you choose an OS to load
- grub2/pxelinux fetches kernel and checks the signature and fails it it
  doesn't match

The step that has to change between Fedora and RHEL is step #2, when the
DHCP says "use this file", and at that point, the only thing involved is
the BIOS/UEFI firmware.  The only available info at that point is some
very minimal hardware info like the MAC address.  After that, it's too
late to change.
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Thomas Cameron]

On 6/4/23 17:30, Chris Adams wrote:
>  Again, the DHCP request that gets a response "use this
> file" comes from
>  the firmware, not the OS.
>
>  It goes something like:
>
>  - BIOS/UEFI configured for network boot sends DHCP request
>  - DHCP server says "use this file (aka shim)"
>  - BIOS/UEFI loads that file and runs it
>  - shim loads grub2 or pxelinux, they get their configs/menus
>  - you choose an OS to load
>  - grub2/pxelinux fetches kernel and checks the signature and fails it it
>     doesn't match
>
>  The step that has to change between Fedora and RHEL is step #2, when the
>  DHCP says "use this file", and at that point, the only thing involved is
>  the BIOS/UEFI firmware.  The only available info at that point is some
>  very minimal hardware info like the MAC address.  After that, it's too
>  late to change. 
Fair enough.

-- 
Thomas