pxe boot failure
-
If there is only one, a dhcp reservation with the correct option 67 would work fine. If you have over 30 then you should try to setup some matching in dhcp if possible. See https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence
-
can you provide a screen shot of the error so we can see the exact error message?
What ipxe boot file are you sending to this computer?
As a test, can you place a dumb switch between the target computer and the building network switch? On the surface this sounds like it could be a spanning tree issue, were your building switch is not using one of the fast spanning tree protocols. The dumb switch will mask this bad behavior.
-
sorry, was a bit busy lately, cant reply in time. so, here comes my photo of the failure:
as for the ipxe file i cant tell you atm as i cant ask for the config of the dhcp from the administrators in the night
i will ask them as i dont remember what i told them to set (something really default after the fog setup).i will make the test what u wanted with the dumb switch (i hope i can reproduce it as the original laptop was sent back to the owner, so i need to get another one. i think it has clones somewhere).
-
@Foglalt I am still thinking to test with a dumb (unmanaged) switch between the target computer and the building switch. On the surface this appears like a spanning tree issue. The dumb switch test will give us a better idea.
-
Unfortunatelly the laptop and its clones are not available for the test atm. but in the shipment we will have some as far as we are informet. So, test will be possible maybe.
As for your question about pxe file we send to clients:
filename “undionly.kpxe”;
If i recall well, i found some dhcp config sample for solving ipxe issues with different types of ipxe implementations. If that can be working out somehow it can be a solution if finally it comes out that not the spanning tree but the ipxe implementation somehow. I am not a dhcp guru and not in charge of managing that machine i have some delays to implement my needs in that part, i must admit.
-
@Foglalt said in pxe boot failure:
filename “undionly.kpxe”;
If that doesn’t work, you can also try
undionly.kkpxeandipxe.pxe -
My problem is that it is struggling to change pxe boot file to another for test purpose. I mean several ppl use fog service to deploy images. There come a problematic hardware for which changing the image name in dhcp is too slow. I am as I stated before, not a dhcp guru so i dont know its all capabilities. Is there any way to “chainload” maybe? It would be ugly to change the binary under the name undionly.kpxe untill the testhardware loads then back fast to let others work properly with previous one.
(sorry for slow replies, somehow i dont get notices of topic replied. i will work on it, maybe i did something wrong)
-
@Foglalt said in pxe boot failure:
My problem is that it is struggling to change pxe boot file to another for test purpose.
Alright - for testing purposes - all you need to do is create a DHCP reservation for a specific and single unit. Once the reservation is created, edit the reservation to include Option 067 with the file you want to test - this reservation edit will only effect that reservation only and that unit only.
-
And is there a solution if i see that some hw works with this and some with them? I mean a general solution or a kind?
-
We are over some tests at last. As you suggested I did the following:
- used a total dumb “link” between the pc and the network (hub): no change, still no boot properly
- I used undionly.kkpxe and ipxe.pxe one by one. unfortunatelly no change.
Still no change, that means this hardware has somehow problems. Any other suggestion maybe? The problem is that we will surely get such hw, so it would be good to have a workaround somehow. Ah, one more thing. ipxe.pxe file gave a little difference. It said during boot that it boots from SAN device. Does it changes a thing?
