UEFI PXE Boot - Pain
-
@george1421 I had to disable tftpd and add that line to get it to serve ipxe.efi properly.
-
@brakcounty said in UEFI PXE Boot - Pain:
I had to disable tftpd and add that line to get it to serve ipxe.efi properly.
You shouldn’t need to. The built in tftp server does everything you need. There is one additional ltsp.conf setting that is used in rare instances that might have worked over using dnsmasq’s tftp server.
-
@george1421 bingo it’s started fine now
-
@rogerbrowntdl Welp, sorry for misdirecting you!
-
@brakcounty Chill man, it’s all good… Not everyones setup is gonna be the same. Unfortunately i’ve inherited this network from someone who was far more technical than me but why he set the Watchguard as the DHCP server rather than… oh IDK… an actual DHCP server is beyond me. Meh, it is what it is (I hate that saying but it’s true I guess)
Will try PXE tomorrow and see what happens… It is strange though that dnsmasq was already there and configured but when we first set this up it just fell on its face and wouldn’t PXE any machine hence the need to add the options 66 and 67 to at least get it to PXE so I could put an image out. Fucking manufacturers removing the option for legacy boot is fine and I guess the nature of the IT beast is that nothing stands still for long but it is a proper pain in the arse unpicking stuff to make it work based on them.
-
@rogerbrowntdl said in UEFI PXE Boot - Pain:
bingo it’s started fine now
Ok now that it started, just remember that dhcp (which pxe booting uses) is based on multicast messages, and those data packets typically won’t flow across vlan routers. So just as you needed to do for dhcp, there should be a dhcp-helper/dhcp-relay service on your existing subnet router. That service will have already been configured. What you need to do is add the FOG server’s IP address to the end of that list. What that setting will do is have the dhcp-relay service send the DISCOVER packet directly to the FOG server so dnsmasq can reply with a ProxyDHCP answer. Then the remote vlans pxe boot request will be seen by dnsmasq and load properly.
You should be on your way to pxe booting both bios and uefi systems without needing to mess around with the back end services anymore.
-
@george1421 I LOVE YOU!!! It’s working
@brakcounty thanks for your help alsoI have a new problem where it wont apply the image because it says the disk is too big but I’m sure it’s because I captured the image from a 500gb SSD and i’m trying to apply it to a 256gb SSD but I’m happy as hell because the actual PXE is working!!!
-
@rogerbrowntdl said in UEFI PXE Boot - Pain:
it says the disk is too big bu
Two things here.
- Make sure you are using single disk resizable in the image definition.
- You might need to upgrade fog to the dev-branch to bring the version of FOG up 10 1.5.9.110 or later. There is a change the MS introduced in 21H1 that causes the recovery partition to be marked as unmovable. This would cause that partition on a 500GB disk to be located past the end of a smaller disk. The code in the dev-branch has addressed that. The fix will be in 1.5.10 when its released later this year.
-
@george1421 i can just create a new image for a 256gb drive though right? I guess I can then apply that to either a 256gb or 500gb drive and it wont matter?
-
@rogerbrowntdl yes a smaller mother image would be best. 1.5.9 can grow the golden image to the size of the disk but not shrink it. Or just removed the recovery partition from the golden image. If you have an imaging solution in place is the recovery partition even useful?
I started with fog the shrink option really worked so I would create my golden image on a 70 or 80GB hard drive then expand it post deployment in windows. I also developed our golden images on a VM because I could snapshot the vm before critical steps. That kept me from having to rebuild the entire image again if I botched something. Stuff happens you know.
