action #116704
closed
[qe-core] nvme@uefi: boot from DVD post install instead of from HDD
Added by dimstar over 1 year ago.
Updated about 1 year ago.
Category:
Bugs in existing tests
Description
Observation¶
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
grub_test
Test suite description¶
Maintainer: rbrown@suse.de; Basic installation test to confirm that installing and booting to an nvme as your root disk works
Reproducible¶
Fails since (at least) Build 20220915
Expected result¶
Last good: 20220914 (or more recent)
Further details¶
Always latest result in this scenario: latest
- Subject changed from nvme@uefi: boot from DVD post install instead of from HDD to [qe-core] nvme@uefi: boot from DVD post install instead of from HDD
- Related to action #116914: [qe-core] recent uefi changes makes test fail added
- Related to action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M added
- Related to action #113794: Use prepared OVMF image with expected settings size:M added
(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
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.
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.
I ran a test with the downgraded and with the current package:
I tested with the branch that removes all old grub2-tw needles:
NEEDLES_DIR=https://github.com/perlpunk/os-autoinst-needles-opensuse.git#remove-bootloader-needles
My newly created needles are matching 100% in both cases.
- Status changed from New to Feedback
- Assignee set to tinita
- Target version set to Ready
- Status changed from Feedback to Blocked
Blocked by the bugzilla ticket
- Tags set to reactive work
- Status changed from Blocked to Feedback
@dimstar Could you run the previously failing tests on openqaworker19?
I upgraded there to ovmf-202202-150400.5.5.1.src which has several patches that might fix the issues.
The original linked tests are delete by now, so I'm not sure how to test.
- Status changed from Feedback to Resolved
With #111992#note-67 I have upgraded all o3 workers. As tinita verified the bugfix with a job from the originally reported test scenario I think we are good here.
Also available in: Atom
PDF