Describe the bug
On fresh clones of deployment-recipes, boot-filename (the DHCP option containing the BSS URL) is not getting served in the DHCPOFFER.
To Reproduce
Steps to reproduce the behavior:
Fresh clone of deployment-recipes
Configure .env, start Ochami containers.
Populate SMD and BSS.
Try to boot a node
iPXE fails with: Nothing to boot: No such file or directory (https://ipxe.org/2d03e18e)
Expected behaviorboot-filename is present in the DHCPOFFER and contains http://<bss_url>/boot/v1/bootscript?mac=<mac>. iPXE can contact BSS to receive the boot script and find the kernel/initramfs accordingly, e.g:
Next server: 172.16.0.253
Filename: http://172.16.0.253:8081/boot/v1/bootscript?mac=ec:e7:a7:05:9f:ec
http://172.16.0.253:8081/boot/v1/bootscript... ok
bootscript : 749 bytes [script]
http://10.100.0.1:9000/boot-images/efi-images/compute/slurm/vmlinuz-4.18.0-553.5.1.el8_10.x86_64... ok
http://10.100.0.1:9000/boot-images/efi-images/compute/slurm/initramfs-4.18.0-553.5.1.el8_10.x86_64.img... ok
Mitigations
Restarting the Ochami services and repopulating SMD/BSS seems to mitigate this issue.
Notes
In my testing, this problem does not seem to occur on fresh pulls of Ochami containers when deployment-recipes is already configured (this is why this issue is filed under deployment-recipes instead of dnsmasq-dhcpd)
Describe the bug On fresh clones of deployment-recipes,
boot-filename
(the DHCP option containing the BSS URL) is not getting served in the DHCPOFFER.To Reproduce Steps to reproduce the behavior:
.env
, start Ochami containers.Nothing to boot: No such file or directory (https://ipxe.org/2d03e18e)
Expected behavior
boot-filename
is present in the DHCPOFFER and containshttp://<bss_url>/boot/v1/bootscript?mac=<mac>
. iPXE can contact BSS to receive the boot script and find the kernel/initramfs accordingly, e.g:Mitigations Restarting the Ochami services and repopulating SMD/BSS seems to mitigate this issue.
Notes