HostInit: host PXE gets DHCP lease but PXE-E21 immediately — is enabling HTTP Boot via Redfish the right fix?

[jingjingl1]

Context

I am onboarding a machine (BlueField-3, NVIDIA H8230 host, AMI MegaRAC 13.05 BMC) through NICo. After carbide-api moves the machine to HostInit / WaitingForDiscovery, the host needs to PXE-boot to fetch the OS image.

What I observed

Host boots, NIC 58:A2:E1:D7:10:BE (BlueField host PF) runs DHCP and gets lease 20.1.1.5 from carbide-dhcp, Start PXE over IPv4... Station IP address is 20.1.1.5 PXE-E21: Remote boot cancelled. tcpdump on the L20 control-plane node captured 0 packets from that MAC, so no TFTP/HTTP request ever reached carbide-pxe.

Questions

1. Is enabling HTTP Boot via Redfish actually required for this step?
   The DHCP lease succeeds, so the network path from host → DPU → carbide-dhcp is working. Is PXE-E21 here caused by carbide-pxe not serving a TFTP NBP (i.e. it only speaks HTTP boot), or is there another reason?
2. Is the real root cause somewhere else entirely?
   Given that tcpdump on the control-plane node saw 0 packets, the failure may be before any protocol decision — e.g. the DHCP OFFER's next-server / bootfile fields are empty or wrong, causing the host firmware to cancel before even attempting a file transfer.

[Advait251206]

From the behavior you’re describing, the key signal is this:

DHCP lease succeeds, but no TFTP/HTTP request is ever sent, followed immediately by PXE-E21: Remote boot cancelled.

That combination usually means the failure is happening before the firmware even attempts to fetch a boot program, so this is not yet an HTTP vs TFTP problem.

---

What PXE-E21 typically indicates

PXE-E21 ("Remote boot cancelled") is most commonly triggered when:

• The DHCP offer is accepted
• But no valid boot instruction is usable

This usually happens if one of the following is true:

1. Missing or empty boot filename

If DHCP does not provide:

• bootfile-name (Option 67), or
• a valid UEFI NBP path

…the firmware has nothing to execute → it aborts immediately.

---

2. Missing next-server (Option 66)

Even if the host gets an IP lease, PXE still needs:

• next-server pointing to PXE/TFTP/HTTP boot server

If this is empty or incorrect, many UEFI implementations will silently cancel boot.

---

3. Wrong PXE mode (UEFI vs legacy mismatch)

BlueField / H8230 setups often default to UEFI PXE, which expects:

• .efi bootloader (not legacy PXE ROM)
• often HTTP Boot or iPXE-style flow depending on firmware config

If the DHCP server is serving a legacy NBP or mismatched architecture path, the firmware may abort early.

---

About your HTTP Boot via Redfish question

Is enabling HTTP Boot via Redfish required?

Not strictly—but in modern NVIDIA / BlueField / AMI MegaRAC environments, HTTP Boot is often the preferred or required path depending on firmware configuration.

However:

• PXE-E21 happens before HTTP/TFTP selection matters
• So enabling HTTP Boot alone will not fix this unless DHCP is correctly advertising it

---

Why you saw zero packets in tcpdump

This is actually the most important clue:

No TFTP, no HTTP, no follow-up traffic at all

That strongly suggests:

👉 The firmware never accepted a valid boot path from DHCP

So the problem is almost certainly:

• DHCP options (66/67 or vendor-specific PXE options)
• or incorrect boot mode negotiation (UEFI PXE vs BIOS PXE)
• or missing PXE boot policy from carbide-pxe / carbide-dhcp integration

---

What to check first (in order)

1. Inspect DHCP offer contents

Verify carbide-dhcp is actually sending:

• Option 66: next-server
• Option 67: bootfile name (e.g. .efi loader)
• or HTTP Boot URL (if using UEFI HTTP boot)

---

2. Confirm firmware boot mode

On AMI MegaRAC + BlueField setups:

• Ensure NIC is in UEFI PXE mode
• Check if HTTP Boot is enabled in BIOS/BMC
• Check whether PXE vs HTTP boot is prioritized

---

3. Verify PXE service behavior

If carbide-pxe is in the chain:

• Does it expect HTTP-only boot?
• Or is it supposed to serve TFTP as fallback?
• Is it actually generating a boot policy for this host identity?

---

4. Check bootfile architecture mismatch

Common failure case:

• DHCP gives legacy PXE binary
• Host expects UEFI .efi
• Firmware aborts immediately → PXE-E21

---

Direct answer to your hypothesis

“Is the root cause that DHCP fields are empty or wrong?”

👉 Yes — based on the “no packets at all” observation, this is the most likely root cause.

It is not yet an HTTP Boot vs TFTP transport issue—it’s earlier:

the firmware never reaches the stage where it chooses a transport.

---

Summary

• PXE-E21 here = boot aborted before fetch stage
• No network traffic = no boot program selected
• Most likely cause = missing/invalid DHCP boot parameters
• HTTP Boot via Redfish may be relevant later, but is not the immediate fix

---

If you want, I can help you narrow it further if you can share a DHCP offer packet (or carbide-dhcp config snippet). That usually makes the root cause immediately obvious.

---

If this answer helped or pointed you in the right direction, I'd appreciate it if you could mark it as the accepted answer so it's easier for others with the same issue to find.

Also, if you found my contribution useful, I'd appreciate it if you could check out my GitHub profile, follow me, and star any repositories you find interesting.

GitHub: https://github.com/Advait251206