What is the status of KEA PXE booting?

[Patrick M. Hausen]

FreeBSD can perfectly well netboot if you serve the root FS via NFS as intended and documented. No mfsBSD, no pxelinux, ... just an NFS based root filesystem like BSD and Sun have been doing for decades.

Blog post in German:

https://punkt.de/de/blog/2017/automatisierte-installation-von-servern-mit-freebsd-und-zfs.html

[drosophila]

But I can remember that at some point it was no longer compatible with UEFI Servers so double check if the software you eventually go for can also do that!

That would likely be a reason to keep trying to get KEA to work; possibly I'll attempt to install a symlink to the actual install file that with an appended "ff". Should be possible but it's certainly an evil hack. KEA can easily filter by boot agent type and therefore serve different stuff for BIOS vs. EFI.

Die bereits per TFTP bereitgestellte Umgebung muss nun noch zusätzlich per NFS exportiert werden.

That likely was the issue that kept my attempt from succeeding. It did load the netboot-capable boot but since I expected this to be fully handled by TFTP I didn't export the boot FS via NFS (which would have been easy since NFS already serves selected datasets). A pity that one can't do away with TFTP entirely, NFS is less hacky and much faster. and if you have TFTP running, then things must already be secured against nefarious clients so that NFS won't be an additional security issue. For installers, one can just set all respective underlying filesystem permissions to be readonly for everyone since they're not sensitive and thus only manipulation must be prevented. The automated install might need sensitive things like passwords or certificates to be served ("Anschließend setzen wir das Root–Passwort, damit wir uns über die Konsole anmelden können: (...) ROOT_PW_HASH ist dabei natürlich durch den echten Hash des Root–Passworts zu ersetzen."), but a basic interactive install doesn't have these problems.

Thanks for the heads-up!

[drosophila]

Just as (final?) info: the evil hack works: I created a symlink with a final character of 0xff, that points to another symlink with the same name except for the appended 0xff, which in turn points to the intended bootfile (so I can simply change this intermediate symlink, and PXE loaders without this bug will use that, so all end up loading the same file). Then I set KEA to serve the filename without the appended 0xff. The nVidia PXE boot agent boots just fine now, so that really is the entire problem.

Now the only thing I could do is to try to find out whether the 0xff that KEA sends after the end of the BF parameter is somehow necessary or not, and if not, try to convince the KEA developers to change that into an 0x0, hoping that the nVidia PXE boot agent would then view this as null-terminated string and handle it properly. Or just keep the evil hack, which of course stinks in terms of maintainability. :(

[cookiemonster]

FreeBSD can perfectly well netboot if you serve the root FS via NFS as intended and documented. No mfsBSD, no pxelinux, ... just an NFS based root filesystem like BSD and Sun have been doing for decades.

Blog post in German:

https://punkt.de/de/blog/2017/automatisierte-installation-von-servern-mit-freebsd-und-zfs.html

Very nicely written resource, thank you Patrick. I have bookmarked for my next time I need to re-do it. I've been meaning to find the time to investigate doing the efi pxie boot. Much obliged.

[drosophila]

Alright, this has not been the final word. Instead I tested some more with appending a true zero. Doing so through the GUI seems to be impossible because it always escapes the escape character "\" into "\\" and therefore destroys the escaping, but from the config file itself it works with an appended "\u000". But for some reason this works only if at least one letter follows the true zero, otherwise KEA just ends there and doesn't send the zero at all. Adding any character(or multiple) makes it send the zero. Like this:

43 0e 2f 70 78 65 62 6f 6f 74 66 69 6c 65 00 56 ff 23 94
That translates to "/pxebootfile<zero>V", note how the length field now is 0e, correctly counting the length including the zero and the appended "V". This is handled correctly by both Realtek and nVidia, both end up requesting "/pxebootfile", which is correct. So is KEA wrong in not sending the final zero even though it correctly specifies the length? Did nVidia work off an outdated spec or did they simply commit the basic blunder of counting from zero instead of one? Does Realtek have a more stringent sanitizer that converts all non-ASCII characters into end-of-string?

Sadly, the "specification" in RFC4578 only says "The format and contents of these options are NOT defined by the PXE specification.", so this must be defined outside of an RFC.
IBM has a document here that lists "UINT8 bootfile[128];   Bootfile: Boot file name. Null terminated string." on page 50. So it seems like the error is indeed on KEAs part, but what about the difference in parameters (noted above: "file" vs. "BF")? Is there yet another spec that supersedes the 1999 IBM document?
So it seems there is one from uefi here. They don't want to let me look at their precious document through my secured browser, and I'm not willing to compromise my anonymity, especially not to satisfy some random sites self-importance. So my research ends here for now. Maybe I'll get back to it on someone elses computer, who doesn't care about security and privacy.

The final question is: does the GUI have some means to escape escape characters so that it does not escape escape characters? IOW: how do I get the "\" into the config file through the GUI without it being mangled into "\\"? So that the resulting config file reads:

Code Select Expand

"data": "\/pxebootfile\u0000V"Not relying on evil filesystem hacks is nice, but managing KEA through files while a perfectly capable GUI is there for everything else also detracts from maintainability.

[Monviech (Cedrik)]

Since you are already way into hex anyway, why not send hex directly?

Its possible with the new options menu, just select hex.