One-time next boot selects the wrong item when the image is grouped

[hcaldicott]

Hi all,

Firstly, thanks a lot for all of your work on this project. I have previously been using iVentoy and have searched for something more powerful and open. The closed nature of iVentoy has always made me a little uncomfortable, so I was really happy to find this project when I finally decided to hunt around again for alternatives after a couple of years.

Anyway - an issue I have discovered while trying to use Bootimus as part of an automated Ansible pipeline for bare metal server builds...

Problem

When a client's one-time next boot image belongs to an image group, Bootimus renders the image as an iso<ID> entry inside the group submenu but sets that same entry as the default selection on the top-level menu.

Because iso<ID> is not a selectable item in the top-level menu, iPXE falls back to the first valid top-level entry. In our case that was the Tools group, so a machine armed for an unattended Alma installation stopped at the Tools menu instead of booting the requested image.

This all happened because we had our Alma Linux ISO stored in an image group named "Linux", instead of existing at the top level.

Steps to reproduce

1. Create and enable a kernel-boot image.
2. Assign the image to a client and place it in an image group (e.g. "Linux")
3. Set that image as the client's one-time next boot image.
4. PXE boot the client.

Expected behavior

The client should boot the one-time image directly without requiring menu interaction.

Actual behavior

Bootimus emits a top-level menu whose default is the grouped image's iso<ID> label, even though that label exists only in the group submenu. iPXE selects the first valid top-level item instead, which is not the configured one time boot image.

Conceptually, the generated script contains:

:start
menu Bootimus - Boot Menu
item group5 Linux
choose --default iso17 selected
goto ${selected}

:group5
item iso17 AlmaLinux

Root cause

MenuBuilder.Build() always renders the interactive main menu. buildMainMenu() uses nextBootImageID as the default item but does not account for grouped images being absent from that menu.

Proposed fix

When nextBootImageID identifies an enabled image, emit goto iso<ID> before the menus. Keep rendering the image boot sections so the target label exists, and fall back to the normal interactive menu if the requested image is missing or disabled.

I have a tested patch for both a grouped next-boot image and the unavailable-image fallback. It has also been validated on a physical UEFI PXE client: the patched server proceeded directly to the requested image and served its kernel and initrd.

[hcaldicott]

Side note: your docker workflow is broken and is not currently publishing a docker image for the latest release.