We flashed the BMC firmware on a batch of Supermicro H12SSL boards, 1.01.10 to 1.08.03. Routine. Then nothing would reinstall: ISOs would not mount over IPMI virtual media, or they mounted and the installer panicked partway through. The rest of the fleet, still on the old firmware, worked fine.
Same boards, same ISO, same Samba share. The only variable was the BMC. The cause was Samba: the new firmware talks to the virtual media share differently, and a modern Samba refuses it. Here is the short version with the fix. The same pattern applies across the Supermicro SSL family (H12SSL, H13SSL, H14SSL).
We burned the first afternoon on the SAS controller, reseating PCI cards, and which EPYC PCIe quadrant the boot path sits on. It was none of that. The BMC is a small Linux, and after 1.08.03 it was a different one.
What Actually Broke
Turn up Samba logging and read what the BMC sends:
The BMC offers the SMB2 wildcard dialect 0x02FF. Samba answers NT_STATUS_NOT_SUPPORTED, which surfaces on the BMC as MEL-0258 "SAMBA protocol not Supported" and "Unknown Status" mount failures. Reading smb2_negprot.c makes it clear: Samba only honours that wildcard when the SMB1 codepath is reachable, and SMB1 is off by default in modern builds. Supermicro reworked the virtual media SMB client in BMC 1.04.03 to negotiate a range (minimum SMBv1.0, maximum SMBv3.02). The old firmware never needed the wildcard honoured. The update did not break Samba, it changed the client so a stricter Samba refuses it.
The Part That Still Panicked
Fixing the dialect got ISOs to mount. It did not stop the panics. Our Samba had aio read size = 1, so it answered large reads with asynchronous STATUS_PENDING interims. The older virtual media client mishandled that mid-stream, during the heavy sequential read of pulling a squashfs into RAM, dropped the connection, and the installer died with Attempted to kill init exitcode=0x00000007 and bad message_id 0 in the log. Force synchronous reads and it holds:
The Fix
Put this on the Samba share that serves your virtual media ISOs. It pins the protocol window the reworked BMC expects and forces synchronous reads.
Then reset the BMC once. It caches a wedged SMB state and keeps failing against a share that is now correct until you do. Serve the ISO from fast storage so the streaming stays clean.
Scope it
Reaching down to NT1 with signing and encryption off is fine for an isolated virtual media share on a locked-down management network. Do not apply this profile to a general file share, and do not expose the share off the management segment.
Lessons
- Test virtual media after every BMC update, on a real install, not just a mount.
- Read the negprot log and the Samba source before swapping hardware. Ten minutes in
smb2_negprot.cbeat an afternoon of guessing. - "Mount OK" is not "boots". Pin
server max protocolon virtual media shares, and reset the BMC after any SMB change.
We Run the Metal so You Do Not Fight the BMC
This kind of thing eats an afternoon when you run your own hardware. We run bare metal and managed virtualization in our own European datacenters (AS215197). The BMC firmware, the virtual media, and the 2am reinstalls are our problem, not yours.