action #151258
Updated by livdywan 7 months ago
## Motivation The initial problem I observed is that `PXEBOOT=once` no longer works properly: it does a PXE boot *every* time the VM boots, not just the first time. I believe this was caused by https://github.com/os-autoinst/os-autoinst/commit/bb95579ddd226e3aac93fdaf4339b1037dd1915e , because it sets `bootindex` for the network device any time `PXEBOOT` is set, even if it's set to "once", and you cannot define "once" behaviour using bootindex (I've filed that as a missing qemu feature - https://gitlab.com/qemu-project/qemu/-/issues/1995 ). When I went to look at fixing this, though, I struggled, because our behaviour here is pretty...messy. The [qemu docs](https://www.qemu.org/docs/master/system/bootindex.html) specifically say "Note that it does not make sense to use the bootindex property together with the -boot order=... (or -boot once=...) parameter. The guest firmware implementations normally either support the one or the other, but not both parameters at the same time. Mixing them will result in undefined behavior, and thus the guest firmware will likely not boot from the expected devices.", but we are definitely doing this. Even before bb95579 , I'm pretty sure there are cases in which we will set both `-boot order` and some `bootindex` values (e.g. any time we set `BOOTFROM=disk` on x86_64 BIOS, I think). The more I look at all the code that handles the BOOTFROM variable, the messier it seems and the harder it seems to resolve this sensibly. I think conceptually it'd be simplest to just always use `bootindex` and drop the code to set `-boot order` and `-boot once`, but then we'd lose the "PXEBOOT=once" support where it works (only x86_64 BIOS, I think), and we'd have to check x86_64 BIOS actually supports/respects bootindex and it works the way we want in all the cases we support... The interaction between BOOTFROM and PXEBOOT and USBBOOT seems pretty confused conceptually, too. Quick! If I set "BOOTFROM=disk PXEBOOT=1", what does that mean? What should it mean? What does it do? ## Acceptance criteria * **AC1:** Backwards compatibility has been preserved * **AC2**: Common use cases of boot configurations are well-known and documented (e.g. in `backend_vars.asciidoc` or `backend.md`) * **AC3**: The use cases identified via AC2 are supported ## Suggestions * Confirm best practice for boot options * Consider if https://gitlab.com/qemu-project/qemu/-/issues/1995 is necessary or more "nice to have" * Add documentation for how to use the settings correctly or link to upstream qemu docs * Maybe revert the change that led to this problem (https://github.com/os-autoinst/os-autoinst/commit/bb95579ddd226e3aac93fdaf4339b1037dd1915e) * Brainstorm on AC2 in a workshop session