While discussing https://bugzilla.redhat.com/show_bug.cgi?id=1331317 , it was noted that we could catch bugs of this type in openQA if we had tests which tried to boot the ISOs as disks (rather than as CD/DVD). I'm not sure off the top of my head if you can tell os-autoinst to do this, but if not, we could send patches. It'd be nice to catch this kind of problem in automation so we know when it breaks.
Metadata Update from @adamwill: - Issue tagged with: newtest
Note: I thought about the way to implement this a bit, and I think I can see two different ways to do it. It's a slightly interesting question that can maybe teach a bit about how the scheduling works...@pschindl :)
Is this still relevant, @adamwill?
Yeah, it is, I just somehow never find ten minutes to do it. It should be very trivial, IIRC I actually noticed a few weeks back that there's a variable to tell openQA to do exactly this.
So, I have just found the time and went over the OpenQA manual, do you think that I made a hit when found this? :crocodile:
USBBOOT: when set to 1, the image will be loaded through an emulated USB stick.
USBBOOT
If this is what needs to be done? Which flavours do we want to set this for? Currently nothing like that is set in the templates, @adamwill.
Yeah, I think that's the one. I guess we'd want to do an install-and-boot test with that variable set for one live image and one installer image.
Metadata Update from @lruzicka: - Issue assigned to lruzicka
Metadata Update from @lruzicka: - Custom field story_points adjusted to 2
Back to this issue, hope we'd finish this finally.
Metadata Update from @lruzicka: - Custom field story_points adjusted to 1 (was: 2)
I have investigated more about this and it is not that easy.
The USBBOOT option works as expected, but when the system is installed, the options stays on and works also after the reboot, so the computer boots the image again and never boots the installed system.
The SuSE guys advised me to use the "Boot from hard drive" grub option that they are using, but this could only be done on Everything and Server ISOs, as we do not have that option on Live images and only if BIOS is used (not available on EFI). We could run this on Everything BIOS to see at least the emulation works.
For EFI However, we could probably navigate around it making that test to store an image and then boot it in a follow-up test. Alternatively, we could use the "Rescue the Fedora installation" and check that at least some of the installed content is there on the disk.
What do you think, @adamwill ?
This is getting even more complicated. I tried to enhance the do_bootloader method to be able to navigate into Troubleshooting and Boot the first drive, but even if I correctly select it and press Enter, the installed system does not boot but it switches back to the previous screen (as if Esc was pressed) and waits out the Check media and boot option so I end up booting from the USB again.
do_bootloader
On a regular VM, this works without any issues and I cannot reproduce it outside of openQA, which means it is not a general bug.
I don't love that approach anyway, I'd prefer to focus on something that works on UEFI, at least first.
Have you tested what happens on UEFI currently? In theory at least, on UEFI, we mark the new "Fedora" boot manager entry as the default, which should mean it takes priority over the USB stick on the next boot. But I don't know if edk2 respects that. I also don't know if we're actually successfully writing the UEFI boot entry such that it persists to the next boot and is used, or if that's not actually working and we're being saved by the fallback path magic. There's quite a few unknowns, it'd be nice to know what currently happens so we can reason from there.
Log in to comment on this ticket.