[qe-core] nvme@uefi: boot from DVD post install instead of from HDD
There seems to be a change on the backend that somehow triggers the system to boot from the DVD again after the installation just completed - previous runs were automatically booting from the HDD after setup.
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-nvme@uefi fails in
Test suite description¶
Maintainer: email@example.com; Basic installation test to confirm that installing and booting to an nvme as your root disk works
Fails since (at least) Build 20220915
Last good: 20220914 (or more recent)
Always latest result in this scenario: latest
(Oliver Kurz) that one is interesting. I thought only machines which use QEMUVGA=qxl/virtio would need the 800x600 vars so why should uefi-usb need it?
(Dominique Leuenberger) good question - the xfce-live one worked in snapshot 0919 after rerunning it with the 800x600, i.e. https://openqa.opensuse.org/tests/2702855#settings, sounds like there is more to it than just the resolution
#6 Updated by tinita about 2 months ago
So the problem is that with the upgraded ovmf package the reboot after installation tries to boot from the installation medium again.
Compare https://openqa.opensuse.org/tests/2773339#step/grub_test/2 and https://openqa.opensuse.org/tests/2663884#step/grub_test/1
Marius suggested to explicitly eject the installation medium.
I tried that but it fails differently now:
It says it can't boot from CD.
#7 Updated by okurz about 2 months ago
Discussed in weekly SUSE QE Tools unblock 2022-10-05. https://openqa.opensuse.org/tests/2774231 shows a failed attempt using the upgraded system package OVMF vars file, not the custom 800x600 variant, plus trying to eject the boot medium working around a problem that the installed HDD is not automatically booted. https://openqa.opensuse.org/tests/2774231#step/grub_test/2 shows what looks like a stale HDD entry so might be product bug or a real problem within the ovmf firmware image. I suggest you actually report a bug about that on bugzilla.opensuse.org referencing the "last good" ovmf firmware image rpm file vs. first bad. Valid workaround is likely still to downgrade the package on openQA workers.
#8 Updated by tinita about 2 months ago
We had a video session together and scheduled a test to have a closer look at the boot problem: https://openqa.opensuse.org/tests/2774887
It shows that booting from hard disk after the installation simply is broken, although according to the tianocore menu it appears in the boot order on top.
#9 Updated by tinita about 2 months ago
I created this product bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1204067
#10 Updated by tinita about 2 months ago
I ran a test with the downgraded and with the current package:
- current: https://openqa.opensuse.org/tests/2778306#step/bootloader_start/2
- downgraded: https://openqa.opensuse.org/tests/2778580#step/bootloader_start/2
I tested with the branch that removes all old grub2-tw needles:
My newly created needles are matching 100% in both cases.
#12 Updated by tinita about 2 months ago
- Status changed from New to Feedback
- Assignee set to tinita
- Target version set to Ready
I downgraded qemu-ovmf-x86_64 on all workers again.
We are waiting for feedback on https://bugzilla.opensuse.org/show_bug.cgi?id=1204067