- In the node BIOS, the local drive must be higher in the boot order than network boot. Otherwise the node attempts PXE regardless of the BCM setting.
- A working bootloader and boot record on the local disk. BCM writes the boot record when installbootrecord is enabled. The default bootloader is SYSLINUX; it can be set to GRUB, which is the usual choice on UEFI systems like the DGX H200.
- The provisioning interface must be changed from BOOTIF to the node's real network device name. BOOTIF is only defined inside the BCM provisioning environment; during local-disk boot that environment is not running, so a node left on BOOTIF comes up with no network and is therefore not manageable. This is the step most often missed.
The cmsh sequence, run on the head node, is:
# cmsh
% device use <dgx-node-name>
% set installbootrecord yes
% set bootloader grub
% commit
Then change the boot interface from BOOTIF to the node's real device name (find it with ip link on the node; the example below uses eth0):
% device interfaces <dgx-node-name>
% set bootif networkdevicename eth0
% commit
A reboot alone is not enough here: the boot record (and, on UEFI, the local boot entry) is written during image synchronization, not at commit time. So provision the node once more with a normal PXE / image-sync pass to write it. After that pass, with the BIOS set to prefer the local drive (point 1 above), the node boots from the local NVMe as a standalone, managed node on every subsequent boot.
Because the DGX H200 is UEFI, the exact bootloader and boot-record behavior depends on the disk and EFI-partition layout.
Verify the following after deployment using the below command outputs :
The node's real network device name (from ip link on the node); that the disk setup includes an EFI system partition on the intended local boot NVMe; and your installed DGX OS release
# cmsh
% device use <dgx-node-name>
% get disksetup
Conclusion :
BCM 11 fully supports DGX H200 local boot deployments, provided the node is first provisioned using a BCM-controlled software image.
The factory-installed DGX OS cannot be directly adopted as a managed BCM node. After provisioning, BCM can configure the system to boot from local NVMe storage while maintaining full node management, monitoring, configuration synchronization, and Kubernetes cluster participation.