Chainloading failed
-
Morning folks.
Had a read around on this but not quite sure my exact problem has come up. Got FOG running nice on one VLAN, excitedly wanted to roll it out around the network but hitting a snag.
When clients boot and try to pass over to the local disk I get the following:
Booting from SAN device 0x80
Boot from SAN device 0x80 failed: Operation canceled (http://ipxe.org./0b8080a0)
Could not boot: Operation canceled (http://ipxe.org./0b8080a0)
Could not boot: Operation canceled (http://ipxe.org./0b8080a0)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 secondsAny magical DHCP 067 file that sorts this? Is it/could it even be that? Just for all the world looks like it’s not paying attention to the message to then pass to the local disk to boot.
Bit stuck and appreciate any and all thoughts and assistance. Thanks folks!
-
…and just to add in, where ipxe.efi is set (and CSM is off in the BIOS to support old-ness) we’re fine and it boots through. Albeit a bit lethargic though, and just on the verge of not really being ok to leave “out in the wild” as is (people will moan and gripe.)
For some context, in a new environment and their imaging here was a little neglected. FOG seemed the best thing to put in to get a smooth, slick imaging solution (as it’s always been tbh) and at the same time cure a little Linux-phobia.
We have though a mix of old BIOS-ey PCs and new UEFI-ish ones. Previously to working here I’d taken newer machines and beaten the BIOS settings into whatever legacy options I needed to force down their throats to get them happy and usually undionly.kpxe working. However here and now I’d like to work more with the UEFI side of things.
So, long story short, I can live with sending techs out around the network and just PXE boot things we want to image but of course I’d much prefer knowing PCs will PXE boot and be ready and willing to image remotely.
Again and help or indeed any thinking or experiments to do would be super. Thanks all!
-
@jra I think there are a few concepts that we need to go over because you have a mixed environment.
BIOS based computers will only boot a bios based boot loader (undionly.kpxe). The default and 99% working BIOS Exit mode is SANBOOT.
UEFI based computers will only boot uefi based boot loaders (ipxe.efi). The default and working most of the time is rEFInd.
This causes a problem if you have a static dhcp server where you manually set dhcp option 67 to a static value. If you want to boot a bios based computer you need to set dhcp option 67 to undionly.kpxe and if you want to boot UEFI you set it to ipxe.efi. If you have a windows based dhcp server you can use dhcp policies as outlined here to create a dynamic dhcp pxe boot options: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy If you have a linux dhcp server then the options are also available for dynamic dhcp booting. If you have a soho router or an ISP managed dhcp server then you can load dnsmasq on your FOG server to supply the pxe boot info only to your clients.
Where you can run into a problem, with FOG its totally allowed to pxe boot into BIOS mode and deploy a UEFI image to the target computer. This works as long as the firmware and image on the hard drive match. Where you run into an issue is if you pxe boot through the iPXE menu in this mixed mode and want to boot to the hard drive and not do any imaging with FOG. If you pxe boot a UEFI computer using CSM in bios mode into the iPXE menu, iPXE can’t tell you did this. It thinks you have a bios computer and will try to use SANBOOT to load the OS. Since the disk structure is UEFI SANBOOT will fail (your error in the original post makes me think this is the case). The same is true for a UEFI boot into iPXE with a bios based image, rEFInd will not be able to chain to a bios boot image.
Now for a new deployment (until FOG 1.5.10 comes out later this spring) I would recommend you do the following.
- Upgrade your FOG 1.5.9 install to the dev branch, this will bring your FOG install to 1.5.9.110 or later. This has the fixes in for Win10 20H1 and later.
- Update your iPXE version to the latest to get support for the current new hardware: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe/2
- Update your FOS Linux kernel to 5.15.x using Web UI -> FOG Configuration -> Kernel update. This updated kernel is needed for new hardware that has the realtek ethernet nic adapter installed.
On my campus I require the techs to sit in front of the computer and intentionally pxe boot into FOG Imaging. I don’t have the target computers pxe booting through the ipxe menu every time. We reimage a computer maybe 2-3 times during the life cycle of a computer. There is no need to add the delay of pxe booting through iPXE menu. Plus windows has a nasty habit of changing the boot order to itself when OOBE/WinSetup finishes. Its just easier to have the techs press F12 during booting and select pxe boot when its time to reimage the computer. Plus this way we know we won’t reimage the wrong computer by accident.
-
@george1421 As always thanks George for the help. Yes indeed DHCP policies will be the way to go to get it all playing nice, but I think also on my end I could commit workstation-side to either/or. And probably of the two UEFI-style will be it.
I’ll more than likely shelve this then and towards the summer update FOG and take advantage of the new features. Ultimately it’d be nice to always have workstations “primed” and I will eventually, but as it stands now (where we only PXE boot when there’s imaging to do) will a - make the boot times a little swifter and b - still be better than WDS!
Cheers.
-
@george1421 …having made my decision though, I have seen the REFIND option available in the Boot Exit Settings. I’ll drop back in if that fixes the universe in the more “legacy” approach to all this.
EDIT - it did not I got a snowstorm of odd characters marching across the screen. Quite pretty but not successful. All fine though, have my route to making this work now.
