Physical machines can't boot from new kernel

[danderson]

Physical machines can't boot from new kernel

[danderson]

Gaaah HP machines are the bane of my existence. At least half of pixiecore's byzantine bugs are these stupid machines. I have half a mind to just document that they're unsupported because they're buggy pieces of crap.

sigh Okay, remaining calm...

Okay, I need to start keeping notes of what firmwares do what broken stuff. Currently, there are two conflicting goals:

• Some firmware contain an iPXE with insufficient functionality, and we have to chainload to a supported iPXE. Chainloading ipxe->ipxe is not reliable if you use undionly.kpxe, so we have to use ipxe.pxe.
• Some firmware (this one) requires using the UNDI stack for network configuration, so we have to use undionly.kpxe.

Network booting is pretty stateless, so we can't easily do trial and error against targets without massive changes to pixiecore (it'd pretty much need a database at that point).

But, okay, here's what we can do:

1. If the requesting firmware is iPXE or gPXE, chainload to embedded ipxe.pxe. By using ipxe as its firmware, the machine is proving that the ipxe native drivers will work (and ipxe->undionly.kpxe chainload is unreliable).
2. Otherwise, chainload to undionly.kpxe, for maximum compatibility with whatever weird firmware requested a boot.

This means we have to carry 5 embedded copies of ipxe instead of 3 (undionly bios32, undionly bios64, native bios32, native bios64, EFI), which sucks... But it's feasible.

[masaeedu]

lol, your patience is appreciated. Does the dhcpdiscover sent out by the prebaked pxe on the platform identify it in any way? So that e.g. you can distinguish an ipxe dhcpdiscover from a non-ipxe network boot firmware's dhcpdiscover?

[danderson]

Yeah, iPXE has identifying marks I can use to distinguish between all these cases. In theory it's possible for a hostile firmware developer to use ipxe but change the userclass (aka "name of the firmware") to something other than ipxe, but thankfully I haven't found anyone doing that yet.

Working on a fix for this now, it'll just take a little while longer because I have to change the ipxe embedding logic first...

[danderson]

Can you test again with the change I just pushed? It switches back to undionly.kpxe for everything except chainloading from another iPXE, so I think it should fix your issue.

[masaeedu]

/cc @maneamarius

@danderson I don't have physical access to the servers at the moment, will let you know as soon as we run a test.

[danderson]

No problem! I'm doing a bit of followup refactoring to try and make the logic easier to follow, so I'll have a followup commit or two shortly.

[maneamarius]

Hi @danderson we've tested the changes you've made and it all seems to be working well now.
Thanks a lot for the hard work, please keep it up!
We're trying to help any way we can, even though we're not Go lang devs ourselves :)

[maneamarius]

So in the future you need any testing done on physical servers (we run some HP DL380p G8 and IBM X3650 M7), we are more than happy to assist! Just send me or @masaeedu a message.

[danderson]

Great news, thanks for testing!

For long-term testing, I'll keep you in mind if I have more scary changes to test... Although what I really need is a bunch of diverse machines on a test bench where I can set up some automated regression testing... But surprisingly nobody seems interested in giving me a bunch of server hardware :P

Thanks for filing bugs and helping me test!