action #116704
closed[qe-core] nvme@uefi: boot from DVD post install instead of from HDD
0%
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
Updated by maritawerner about 2 years ago
- 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
Updated by okurz about 2 years ago
- Related to action #116914: [qe-core] recent uefi changes makes test fail added
Updated by okurz about 2 years ago
- Related to action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M added
Updated by okurz about 2 years ago
- Related to action #113794: Use prepared OVMF image with expected settings size:M added
Updated by okurz about 2 years ago
(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
Updated by tinita about 2 years 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:
https://openqa.opensuse.org/tests/2774231#step/grub_test/6
It says it can't boot from CD.
Updated by okurz about 2 years 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.
Updated by tinita about 2 years 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.
Updated by tinita about 2 years ago
I created this product bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1204067
Updated by tinita about 2 years 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:
NEEDLES_DIR=https://github.com/perlpunk/os-autoinst-needles-opensuse.git#remove-bootloader-needles
My newly created needles are matching 100% in both cases.
Updated by tinita about 2 years ago
Updated by tinita about 2 years 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
Updated by livdywan about 2 years ago
- Status changed from Feedback to Blocked
Blocked by the bugzilla ticket
Updated by tinita over 1 year ago
- 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.
Updated by okurz over 1 year ago
- 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.