Project

General

Profile

Actions

action #116704

closed

[qe-core] nvme@uefi: boot from DVD post install instead of from HDD

Added by dimstar about 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
Start date:
2022-09-16
Due date:
% Done:

0%

Estimated time:
Difficulty:

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


Related issues 3 (1 open2 closed)

Related to openQA Tests - action #116914: [qe-core] recent uefi changes makes test failWorkable2022-09-21

Actions
Related to openQA Project - action #111992: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:MResolvedtinita2022-06-03

Actions
Related to openQA Project - action #113794: Use prepared OVMF image with expected settings size:MResolvedtinita2022-06-03

Actions
Actions #1

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
Actions #2

Updated by okurz about 2 years ago

  • Related to action #116914: [qe-core] recent uefi changes makes test fail added
Actions #3

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
Actions #4

Updated by okurz about 2 years ago

  • Related to action #113794: Use prepared OVMF image with expected settings size:M added
Actions #5

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

Actions #6

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.

Actions #7

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.

Actions #8

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.

Actions #9

Updated by tinita about 2 years ago

I created this product bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1204067

Actions #10

Updated by tinita about 2 years ago

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.

Actions #12

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

Actions #13

Updated by livdywan almost 2 years ago

  • Status changed from Feedback to Blocked

Blocked by the bugzilla ticket

Actions #14

Updated by okurz almost 2 years ago

  • Tags set to reactive work
Actions #15

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.

Actions #16

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.

Actions

Also available in: Atom PDF