make update-ipxe error

[realtime-neil]

make update-ipxe error

[danderson]

Sounds like ipxe's build is broken? Other than twiddling one piece of config we don't alter it from upstream.

[realtime-neil]

I've had better luck building ipxe from source checkouts. Would you be okay with pixiecore using a later release of ipxe? How about a submodule of the same?

I understand the importance of the EMBED script and the go-bindata-generated golang source. I'm confident I can keep the existing semantics while changing the Makefile to play with a submodule instead of vendored sources --- if you're okay with that.

[danderson]

My current experience with submodules at Tailscale leads me to think that I'm not a huge fan, but I won't turn down a PR that fixes the build for containing submodules.

Later release of ipxe should be fine and mostly desirable (isn't that what the update script does? I've forgotten :( ). The main catch is that every time ipxe updates, there's a chance it won't interact correctly with the rest of the boot sequence, but there's no way to find that out other than make the change and see what happens.

[realtime-neil]

Okay, understood; I'll see if I can get a submodule to work.

The update-ipxe target in the Makefile probably used to do exactly that --- that is, when the git commands weren't commented out. In its current form, it's just rebuilding the same (vendored?) ipxe source every time. It's too bad ipxe doesn't (yet) have reproducible builds, but that's a problem for another day.

What I could do is delete the vendored ipxe source for an ipxe submodule pinned to the latest stable release. The path to third_party/ipxe/ipxe-bin.go would have to move elsewhere (anywhere outside of the submodule) but that would be the only golang-visible change.

[danderson]

Doh. Can you tell it's been a while since I've poked at this code :).

What you propose SGTM.