PXE-E18: Server response timeout on Supermicro X11SSE-F

[JakeStanger]

Hey, I'm trying to get Bootimus set up on my server as it looks really promising, but I'm having some issues getting the client to boot in currently:

The startup logs for Bootimus all look good to me. I can see that the correct address is detected, and the proxyDHCP server starts up with what look like correct details to me.

2026/04/19 13:58:10 Data directory structure initialized at: ./data
2026/04/19 13:58:10   - ISOs: ./data/isos
2026/04/19 13:58:10   - Bootloaders: ./data/bootloaders
2026/04/19 13:58:10 Auto-detected server IP: 192.168.1.3
2026/04/19 13:58:10 Connecting to PostgreSQL database at localhost:5432...
2026/04/19 13:58:10 Running PostgreSQL database migrations...
2026/04/19 13:58:10 CustomFile index already migrated
2026/04/19 13:58:10 Database connected and migrations completed (PostgreSQL)
2026/04/19 13:58:10 Admin authentication enabled
2026/04/19 13:58:10 Profiles: Seeded/updated 25 distro profiles (version: 0.1.26)
2026/04/19 13:58:10 Starting Bootimus - PXE/HTTP Boot Server
2026/04/19 13:58:10 Boot directory: ./data/bootloaders
2026/04/19 13:58:10 Data directory: ./data
2026/04/19 13:58:10 ISO directory: ./data/isos
2026/04/19 13:58:10 TFTP Port: 69
2026/04/19 13:58:10 HTTP Port: 8090
2026/04/19 13:58:10 Admin Port: 8091
2026/04/19 13:58:10 Server Address: 192.168.1.3
2026/04/19 13:58:10 Found 1 ISO image(s)
2026/04/19 13:58:10   - nixos-minimal-25.11.9418.c7f47036d3df-x86_64-linux (1.5 GiB)
2026/04/19 13:58:10 NBD Port: 10809
2026/04/19 13:58:10 Starting HTTP server on port 8090...
2026/04/19 13:58:10 Starting Admin server on port 8091...
2026/04/19 13:58:10 Setting up admin interface
2026/04/19 13:58:10 Starting TFTP server on port 69...
2026/04/19 13:58:10 proxyDHCP: listening on UDP/67, advertising next-server=192.168.1.3 (BIOS=undionly.kpxe, UEFI=bootimus.efi, ARM64=bootimus-arm64.efi)
2026/04/19 13:58:10 NBD server listening on :10809

When the server boots, I can see that four separate DISCOVER requests are received by the server. I assume the client machine is either not receiving a reply, or receiving an invalid one and retrying?

2026/04/19 14:31:31 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/19 14:31:35 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/19 14:31:43 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/19 14:31:53 Boot logs retrieved: 0 entries
2026/04/19 14:31:53 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/19 14:31:59 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/19 14:32:23 Boot logs retrieved: 0 entries

Some notes:

• Both the server and client have static IPs assigned by the DHCP server.
• The client machine is bare metal (I was able to use SuperMicro's fancy web client to capture the BIOS/startup)
• I'm using docker host networking for Bootimus
• No config file, just using env vars as below:

  BOOTIMUS_ADMIN_PORT	8091
  BOOTIMUS_DB_HOST	localhost
  BOOTIMUS_DB_PASSWORD	[REDACTED]
  BOOTIMUS_DB_USER	bootimus
  BOOTIMUS_HTTP_PORT	8090
  BOOTIMUS_PROXY_DHCP_ENABLED	true
  PATH	/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  

• I've uploaded an ISO and enabled two tools (memtest & netboot.xyz), but otherwise not touched the bootimus configuration
• The client machine is running a fairly old BIOS version:
  

[garybowers]

I actually run a couple of Supermicro's mostly short depth servers, so I was able to replicate your issue on one of my X11SCL-IF boards - the latest version 0.1.38 ^should^ fix your issues, let me know how you get on.

[JakeStanger]

Thanks for the quick response, although no luck I'm afraid. I've just updated & I'm getting the exact same sequence of events and logs as before:

2026/04/20 11:49:08 Data directory structure initialized at: ./data
2026/04/20 11:49:08 - ISOs: ./data/isos
2026/04/20 11:49:08 - Bootloaders: ./data/bootloaders
2026/04/20 11:49:08 Auto-detected server IP: 192.168.1.3
2026/04/20 11:49:08 Connecting to PostgreSQL database at localhost:5432...
2026/04/20 11:49:08 Running PostgreSQL database migrations...
2026/04/20 11:49:08 CustomFile index already migrated
2026/04/20 11:49:08 Database connected and migrations completed (PostgreSQL)
2026/04/20 11:49:08 Admin authentication enabled
2026/04/20 11:49:08 Profiles: Seeded/updated 25 distro profiles (version: 0.1.26)
2026/04/20 11:49:08 Starting Bootimus - PXE/HTTP Boot Server
2026/04/20 11:49:08 Boot directory: ./data/bootloaders
2026/04/20 11:49:08 Data directory: ./data
2026/04/20 11:49:08 ISO directory: ./data/isos
2026/04/20 11:49:08 TFTP Port: 69
2026/04/20 11:49:08 HTTP Port: 8090
2026/04/20 11:49:08 Admin Port: 8091
2026/04/20 11:49:08 Server Address: 192.168.1.3
2026/04/20 11:49:08 Found 1 ISO image(s)
2026/04/20 11:49:08 - nixos-minimal-25.11.9418.c7f47036d3df-x86_64-linux (1.5 GiB)
2026/04/20 11:49:08 NBD Port: 10809
2026/04/20 11:49:08 Starting HTTP server on port 8090...
2026/04/20 11:49:08 Starting Admin server on port 8091...
2026/04/20 11:49:08 Setting up admin interface
2026/04/20 11:49:08 Starting TFTP server on port 69...
2026/04/20 11:49:08 NBD server listening on :10809
2026/04/20 11:49:08 scheduler: 0 active task(s) loaded
2026/04/20 11:49:08 proxyDHCP: listening on UDP/67 + UDP/4011, advertising next-server=192.168.1.3 (BIOS=undionly.kpxe, UEFI=bootimus.efi, ARM64=bootimus-arm64.efi)
2026/04/20 11:49:50 Auth: User 'admin' logged in
2026/04/20 11:49:50 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:49:50 ListImages returning 1 images
2026/04/20 11:49:50 [0] nixos-minimal-25.11.9418.c7f47036d3df-x86_64-linux (filename: nixos-minimal-25.11.9418.c7f47036d3df-x86_64-linux.iso, size: 1621032960)
2026/04/20 11:50:20 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:50:50 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:51:20 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:51:56 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:52:28 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:52:58 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:53:28 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:53:46 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/20 11:53:50 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/20 11:53:58 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/20 11:53:58 Stats retrieved: 0 clients, 1 images, 0 boots
2026/04/20 11:54:14 proxyDHCP: DISCOVER -> 0c:c4:7a:b2:95:48 arch=7 bootfile=bootimus.efi
2026/04/20 11:54:28 Stats retrieved: 0 clients, 1 images, 0 boots

The server eventually times out E18 & falls back to the EFI shell.

And just to sanity check:

For reference this is a SuperServer 5039MS-H12TRF and each node has a X11SSE-F board.

[garybowers]

Thanks for confirming - seems like this could be environmental the logs narrow this down nicely. I can see bootimus is receiving your client's DISCOVER and replying (proxyDHCP: DISCOVER -> ... arch=7 bootfile=bootimus.efi), so the reply is leaving our socket. PXE-E18 means the client didn't accept any reply it received, which leaves a few possible causes. Could you help me narrow it down?

Network topology
Is the client on the same L2 subnet/VLAN as the bootimus host, or is there a router between them? DHCP broadcasts don't cross routers without a DHCP relay (ip helper-address), which is the most common cause of "bootimus logs a reply but the client times out."

Primary DHCP server
What's handing out IP leases on that network — router (which model?), pfSense/OPNsense, Unifi, dnsmasq, Windows DHCP, ISC, etc.? If the DHCP server itself is also setting PXE options (next-server, bootfile, option 66), it can conflict with bootimus's proxyDHCP.

"Static IP from DHCP" — which is it?
Do you mean a static reservation in the DHCP server (client still does DHCP, just gets the same IP every time), or truly static config on the client with no DHCP server involvement? UEFI PXE requires a DHCP exchange regardless of the OS-level IP config, so a truly static setup would time out even with bootimus working perfectly.

Does Legacy/BIOS PXE boot work?
If you can flip the Supermicro firmware to Legacy/BIOS PXE (not UEFI) and retry, we'd serve undionly.kpxe instead of bootimus.efi. If BIOS works and UEFI doesn't, it points to a UEFI-specific vendor-options issue we can fix. If both fail, it's network.

Does another client work?
A VM on the same network, a laptop, anything other than this Supermicro box. This tells us whether bootimus is broken for everyone or whether this specific Supermicro UEFI is rejecting our reply.

Docker details
You mentioned host networking — does the host have a single NIC, or multiple NICs/bridges/VLANs? With host networking on a multi-interface box, broadcast replies can exit the wrong interface.

[JakeStanger]

Network topology

It's a very simple home setup. There's a cable from router to switch, and then everything is connected to the switch. All devices are on the same 192.168.1.x subnet & there's no fancy VLANs or anything.

Primary DHCP server

I'm using the router's built-in server. It's an ISP-provided router - Technicolor DGA4135. There's no other DHCP servers running, although I can in theory enable the one built into pi-hole for testing if required (that sits on the same box as the bootimus instance).

"Static IP from DHCP" — which is it?

Both have static reservation in the DHCP server to ensure both talk to the DHCP server.

Does Legacy/BIOS PXE boot work?

Seemingly not, although it definitely feels like a BIOS issue. Attempting to network boot just loads into the BIOS settings before even attempting to connect 🙃 Nothing in the Bootimus logs either.

Does another client work?

Yep - I've tried my desktop (Asus B450 ROG motherboard plugged into the same switch), and another old Asus desktop plugged directly into the router. Both worked as expected straight away:

2026/04/20 12:55:36 Stats retrieved: 1 clients, 1 images, 0 boots
2026/04/20 12:55:40 proxyDHCP: DISCOVER -> 04:d9:f5:83:e0:eb arch=7 bootfile=bootimus.efi
2026/04/20 12:55:40 proxyDHCP: REQUEST -> 04:d9:f5:83:e0:eb arch=7 bootfile=bootimus.efi
2026/04/20 12:55:40 TFTP: Client requesting file: autoexec.ipxe
2026/04/20 12:55:40 TFTP: Serving dynamic autoexec.ipxe (HTTP port: 8090)
2026/04/20 12:55:40 TFTP: Successfully sent autoexec.ipxe (523 bytes)
2026/04/20 12:55:40 proxyDHCP: DISCOVER -> 04:d9:f5:83:e0:eb arch=7 bootfile=bootimus.efi
2026/04/20 12:55:40 proxyDHCP: REQUEST -> 04:d9:f5:83:e0:eb arch=7 bootfile=bootimus.efi
2026/04/20 12:55:40 Storage: Auto-created dynamic client for MAC 04:d9:f5:83:e0:eb
2026/04/20 12:55:41 Inventory: Saved hardware info for 04:d9:f5:83:e0:eb (product: System Product Name, manufacturer: System manufacturer, memory: 0)
2026/04/20 12:55:41 Client Connected: MAC 04:d9:f5:83:e0:eb (IP: 192.168.1.116:28760) requesting boot menu
2026/04/20 12:55:41 GetImagesForClient: client=04:d9:f5:83:e0:eb, AllowedImages=[], ShowPublicImages=true
2026/04/20 12:56:06 Stats retrieved: 2 clients, 1 images, 0 boots

Docker details

Docker is running on bare metal, and there is only a single NIC on the box, so it should be interfacing directly with the outside world. There are a lot of other Docker networks on the machine (all bridges), but I don't think these should ever come into play?

---

To me this definitely does feel like a UEFI issue. The one thing I can try (reluctantly, with my nails in my mouth) is updating the Supermicro box to the latest BIOS version given it's on 2.0 and the latest is 2.14.

[garybowers]

Thanks, do you have any other machines you could also test on? In the mean time I'm still looking into it on the code side.

Appreciate you giving it a go hopefully we can resolve the issue.

[JakeStanger]

Unfortunately not without some difficulty. I might be able to ask my housemates to give it a go if that's helpful though. Will be similar setup - gaming desktops plugged directly to switch.

The supermicro box does have 12 nodes so I'm tempted to update the BIOS of one and see if that helps, which should help narrow it down.

Let me know if you think it would be worth it though. I'd rather avoid needing to do a BIOS update (or 12) if I can help it.

[garybowers]

updating bios is always a bit ..... ehhhh especially on these supermicro's, is the LAN connected to the same IPMI Port i.e. are you sharing a LAN + IPMI or do you have multiple connections?

[JakeStanger]

I've tried both, but I've currently got the 1st node connected directly. When using the IPMI port, PXE boot fails to find Bootimus at all. I assume there's something odd happening with the internal routing.

The machine isn't doing anything yet (the other 11 cables and all the boot drives are in the post) so I can fiddle as needed.

[garybowers]

So jealous seems like a epic machine!! What's the power consumption on that beast?

I'm just asking Gemini if it knows any reason it came up with

Enter BIOS > Advanced > IPMI Configuration > Network Configuration.
2. Check if Update IPMI LAN Configuration is [Yes].
3. Ensure the VLAN setting in IPMI is [Disabled] (unless your network specifically requires it). If IPMI is on a VLAN and the BIOS is not, the NIC can get "confused" at the hardware level.

[JakeStanger]

No luck with that, the VLAN is off and other settings look correct.

I've had an interesting discovery though. Node 2 for some reason isn't showing up with the rest, and I've found it's running a completely different BIOS version (I'm hoping that's the reason, although unrelated matter):

I think going by Supermicro's site it is the latest version too. Not sure why there's two version numbers going on.

I've tried net booting and ran into the same DISCOVER x4 with no reply issue, so that rules out needing to update the others, or that it's been patched.

Interestingly I've not set this machine up with DHCP yet, and it instead has a static IP assigned via IPMI. Either the router is doing something funky to track static assignments somehow, or that's suspicious.

---

So jealous seems like a epic machine!! What's the power consumption on that beast?

I'm scared to find out, but from what I've read it's relatively little for its size and the amount of noise it makes. I think the PSU is 2kW.

[JakeStanger]

I've been having another play around with this today and tried a few things to no avail:

• Updated Bootimus to v0.1.58 just in case something had inadvertently fixed it
• Ensured the BIOS and firmware are definitely up to date
• Tested multiple nodes in case one of them was behaving funny
• Wired up all 4 of the LAN ports (2 per node, plus 2 for the IPMI controller)

I did spot something with the last point though. Each node has three MAC addresses - one for the BMC/IPMI controller, and one per LAN port. The DISCOVER calls always come from LAN1 (makes sense). I originally assigned the static lease to the BMC address, although putting it on LAN1 seems to have made no difference. That does potentially explain why node 2 without a static lease could communicate though, because it was probably just given a regular old DHCP lease.

I don't know enough about how the networking works under the hood, but I'm wondering if maybe it's not getting a reply because it's getting routed to the 'wrong' address?

[garybowers]

This could very well be the case, I think it could be getting mixed up which MAC to use. Have you cross referenced the MAC recorded in bootimus with that of the nic and which MAC is which?

…

On Sun, 26 Apr 2026 at 14:38, Jake Stanger ***@***.***> wrote: *JakeStanger* left a comment (garybowers/bootimus#51) <#51 (comment)> I've been having another play around with this today and tried a few things to no avail: - Ensured the BIOS and firmware are definitely up to date - Tested multiple nodes in case one of them was behaving funny - Wired up all 4 of the LAN ports (2 per node, plus 2 for the IPMI controller) I did spot something with the last point though. Each node has three MAC addresses - one for the BMC/IPMI controller, and one per LAN port. The DISCOVER calls always come from LAN1 (makes sense). I originally assigned the static lease to the BMC address, although putting it on LAN1 seems to have made no difference. That does potentially explain why node 2 without a static lease could communicate though, because it was probably just given a regular old DHCP lease. I don't know enough about how the networking works under the hood, but I'm wondering if maybe it's not getting a reply because it's getting routed to the 'wrong' address? — Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE2EGRBKL2VDZ5UCEKN5K5T4XYGMBAVCNFSM6AAAAACX6SZDJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMRSGE2DSMBQGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[JakeStanger]

Yeah, helpfully LAN2's address is one higher than LAN1 so it's easy to identify them (:48 vs :49). Bootimus is definitely communicating via LAN1's address, which is physically connected. It doesn't seem to make any difference whether the other ports are connected or not though :/

[JakeStanger]

Hey just to update, I had a play around in the BIOS with the adapter settings but still had no luck. Ended up just USB booting to install across all 12 (slightly painful, but not the worst).

The issue is "resolved" in respect to it being a non-issue for myself, but happy to keep it open and do any further testing if you make any changes in future. Appreciate your time on this!