Bare-metal provisioning · Prasanta Kumar Behera

How a bare server gets from 'powered on' to 'running an installer' without a human: BMCs and the Redfish API (power, boot override, virtual media), legacy IPMI, the PXE → iPXE → HTTP boot chain, DHCP details for BIOS vs UEFI, and firmware consistency.

The BMC: remote hands

Every server-class machine has a baseboard management controller (Dell iDRAC, HPE iLO, Lenovo XClarity, Supermicro BMC…). It runs independently of the main CPU and lets you:

power on/off/cycle,
choose the next boot device,
mount virtual media (an ISO over the network),
see the console and hardware inventory, and update firmware.

The BMC is a tiny robot butler living inside the server. Even when the big computer is asleep, the butler is awake and listening. From far away, you can tell it: "wake the computer up", "this time, start from the network", or "pretend this CD is in the drive". That's how a computer 500 km away gets set up without anyone touching it.

Security first: put BMCs on an isolated out-of-band network, change default credentials (per-server passwords are best), update BMC firmware, and never expose BMCs to the internet.

Redfish

Redfish (a DMTF standard) is a REST API over HTTPS:

$ curl -sku admin:"$PW" https://10.0.10.21/redfish/v1/Systems | jq '.Members'
$ curl -sku admin:"$PW" -X PATCH -H 'Content-Type: application/json' \
    https://10.0.10.21/redfish/v1/Systems/1 \
    -d '{"Boot":{"BootSourceOverrideTarget":"Pxe","BootSourceOverrideEnabled":"Once"}}'
$ curl -sku admin:"$PW" -X POST -H 'Content-Type: application/json' \
    https://10.0.10.21/redfish/v1/Systems/1/Actions/ComputerSystem.Reset \
    -d '{"ResetType":"ForceRestart"}'

System and manager IDs and some behaviours differ by vendor (e.g. System.Embedded.1 on Dell); discover them from the API rather than hard-coding. Provisioning tools (Tinkerbell Rufio, Metal3/Ironic) wrap these calls.

Virtual media boot mounts an ISO from an HTTP server via the BMC, so you don't need PXE or DHCP at all, which is handy for remote sites (lesson 02).

The network boot chain

power on (boot override: PXE/HTTP)
  → NIC firmware sends DHCP DISCOVER (with option 93: client architecture)
  → DHCP OFFER: IP + next-server + boot filename (ipxe.efi or undionly.kpxe)
  → TFTP download of iPXE (small)
  → iPXE does DHCP again (identifies itself as iPXE) → gets an HTTP script URL
  → iPXE fetches kernel + initrd over HTTP (fast, reliable)
  → in-memory OS / installer starts (e.g. Tinkerbell HookOS, Ironic Python Agent)

Chainloading to iPXE lets you use HTTP instead of slow TFTP for big files.
UEFI HTTP Boot can skip TFTP entirely on modern firmware.
Across routed networks, configure DHCP relay (ip helper) on the site router.

Firmware consistency

The same image behaves differently on hardware with different BIOS/UEFI settings, NIC firmware or RAID/HBA modes:

Define a firmware and BIOS baseline per hardware model (boot mode UEFI, Secure Boot state, virtualisation, SR-IOV, power profile, disk controller mode).
Apply it with Redfish (BIOS attributes, firmware update service) or vendor tooling during day 0.
Record the actual versions in the site inventory and alert on drift.

Scenario: nodes PXE-boot, then hang waiting for network

New servers at a site get the iPXE menu, load the kernel, then the in-memory OS hangs "waiting for network". Other sites with the same image work.

How do you isolate the layer?

DHCP inside the OS: iPXE got an address, but the booted OS does DHCP again. Is the second request answered? (Capture on the provisioning interface: tcpdump -ni <if> port 67 or port 68.)
VLAN tagging: the NIC boots untagged (native VLAN) in firmware, but the OS config expects a tagged VLAN, or vice versa. Check the switch port mode.
Driver/firmware: a new NIC model or firmware version not supported by the in-memory OS kernel. Check the console for missing interfaces (ip link).
Which NIC: a server with several NICs may PXE-boot on one and bring up another in the OS. Match MACs in the inventory.
Spanning tree / port speed: slow port activation (STP) can make early DHCP time out; use edge/portfast on server ports.

Compare with a working site: same image, so the difference is network or hardware.

Try it: Redfish and PXE without real servers

Run the DMTF Redfish Mockup Server or sushy-tools (an emulator that exposes libvirt VMs through Redfish) on a Linux host.
List systems, set a one-time PXE boot override and power-cycle a VM through Redfish with curl.
Set up dnsmasq for DHCP + TFTP with iPXE, serving ipxe.efi to UEFI clients, on an isolated libvirt network.
PXE-boot a UEFI VM into an iPXE script that loads a small Linux kernel/initrd over HTTP.
Mount an ISO through the emulator's virtual media endpoint and boot from it.

Going deeper: fleet-grade bare metal

Keep a hardware compatibility list per image version (NICs, RAID controllers, firmware).
Automate BMC credential rotation and store credentials in a vault.
Consider Secure Boot from day 0: signed boot chain (shim, kernel), with keys managed centrally.
Log every BMC action for audit; BMC access is effectively root on the machine.

Recap

The BMC gives remote power, boot choice, virtual media, console and firmware control; isolate and secure it.
Redfish (REST/JSON) is the modern API; IPMI is legacy.
Boot chain: DHCP → iPXE → HTTP kernel/initrd → in-memory OS; pick binaries by client architecture; use relay across routers.
Keep firmware/BIOS baselines per model and detect drift.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.