boot.php denied on random PCs
-
This is a new install of FOG 1.5.9 using https
Everything has been working great since the install a week or so ago but today we had a few random machines that get the following error on PXE boot.The models are Dell GX 790, 9010, and 9020. But we have many of each of those models that pxe boot and image just fine.
tftp://xxx.xxx.xxx.xxx/default.ipxe… ok
https://xxx.xxx.xxx.xxx/fog/service/ipxe/boot.php … Permission denied (http://ipxe.org/0216eb8f)
could not boot:Permission denied (http://ipxe.org/0216eb8f)
chainloading failed. hit ‘s’ for the ipxe shell; reboot in 10 secondsAny idea why this would pop up for just a handful of machines out of (4 out of around 100)?
Thanks!
-
@abroome82 The logic here doesn’t hold true.
4 out of 100 and the only difference is this unique hardware?
Well just thinking wildly, this hardware is old. So that might also imply you are using the bios boot loader undionly.kpxe. Is it possible that the bios boot loader is not the compiled version FOG created when it compiled iPXE for your https install?
iPXE is what manages downloading over the http/https protocol, so it shouldn’t be anything specific to the hardware. The PXE rom on the target computer only knows how to download using tftp. So it does that and starts up iPXE which supports http and https file transfers. So that makes me think there is something unique about iPXE.
Is it possible that you have a second dhcp server some place that is misconfigured to point to an old FOG server that is using http file transfer, where iPXE would be as FOG was delivered?
-
Hi George.
Yea the hardware is old but this is a public school system so it’s the newest I have available to me.
We do use undionly.kpxe for the BIOS machines.
For UEFI it uses snponly.efi
I get the same error using both if I switch one of the 9020s with the issue to UEFI boot or Legacy boot.
I verified it’s pulling from the correct DHCP server. It’s the only one at that site.
-
@abroome82 said in boot.php denied on random PCs:
Yea the hardware is old but this is a public school system so it’s the newest I have available to me.
I was only referencing old as in they are probably running in bios mode over something more modern probably running in uefi mode.
Can you make a general statement that all GX790s and 9010s have this issue? Or is it specific to an precisely this 790 and that 9010 have the issue? If its just precisely this computer, have you updated the firmware on these specific computers? The 790, 9010, 9020 cover 3 generations of computers its strange how the issue persisted across the generations.
-
Oh I know you were. I didn’t mean it as a slight, if it came off that way I apologize.
No most 790/9010/9020 work absolutely fine. It is just these 4 particular machines as far as I know. My techs are going building by building. I was in the process of collecting the latest firmware for each model for them to test and get back with me.
-
@abroome82 Sounds pretty awkward. Nothing that rings a bell here for me straight away. I’ll keep pondering on this.
-
So updating firmware fixed the issue.
I’m not sure why but some middle firmware versions weren’t working. The 790s with A11 worked fine, but A18 produced the error, and then when they updated to A21 it worked.
We can mark this as solved. I appreciate everyone helping.
