action #40127
closed[sle][functional][medium][fast][u] test fails in bootloader_uefi - need adption, boot from hard disk doesn't work
Added by zluo over 5 years ago. Updated over 5 years ago.
0%
Description
compared with successful test run: https://openqa.suse.de/tests/1688122#step/bootloader_uefi/2 which is installation selected.
But in current test we see it boots from hard disk which is not working. Please check and adapt the test code.
Observation¶
openQA test in scenario sle-12-SP4-Server-DVD-aarch64-cryptlvm+activate_existing+force_recompute@aarch64 fails in
bootloader_uefi
Reproducible¶
Fails since (at least) Build 0351 (current job)
Suggestions¶
- try to reproduce locally
- re-run the test with reverted PR from mitiao (https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5598)
Expected result¶
Last good: 0243 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by mgriessmeier over 5 years ago
might be related to #39695 and introduced by https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5598
Updated by mgriessmeier over 5 years ago
- Related to action #39695: [sle][migration][sle12sp4]online_migration_setup failed on aarch64 that need handle_uefi_boot_disk_workaround added
Updated by mgriessmeier over 5 years ago
- Subject changed from [sle][functional]test fails in bootloader_uefi - need adption, boot from hard disk doesn't work to [sle][functional][fast][u] test fails in bootloader_uefi - need adption, boot from hard disk doesn't work
- Due date set to 2018-08-28
- Status changed from New to Workable
- Priority changed from Normal to High
Updated by mgriessmeier over 5 years ago
might be also worth a look on https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5563 and ask richie for support
Updated by SLindoMansilla over 5 years ago
- Subject changed from [sle][functional][fast][u] test fails in bootloader_uefi - need adption, boot from hard disk doesn't work to [sle][functional][medium][fast][u] test fails in bootloader_uefi - need adption, boot from hard disk doesn't work
- Estimated time set to 5.00 h
- Difficulty set to medium
Updated by mgriessmeier over 5 years ago
jorauch wrote:
Taking a look
any findings? :)
Updated by mgriessmeier over 5 years ago
- Due date changed from 2018-08-28 to 2018-09-11
- Status changed from Workable to In Progress
moving to next sprint, @jojo could you please continue on this one once you're back?
Updated by jorauch over 5 years ago
mgriessmeier wrote:
jorauch wrote:
Taking a look
any findings? :)
I cannot reproduce it locally since the job won't start due to too old version of some perl stuff on the worker
Should we set it to blocked until Sergio returns?
zypper in perl-Mojo-IOLoop-ReadWriteProcess=0.23-lp150.13.1
Updated by mgriessmeier over 5 years ago
jorauch wrote:
mgriessmeier wrote:
jorauch wrote:
Taking a look
any findings? :)
I cannot reproduce it locally since the job won't start due to too old version of some perl stuff on the worker
Should we set it to blocked until Sergio returns?
could you ask Santi about the outdated perl stuff?
Updated by jorauch over 5 years ago
Finally this is reproducible:
http://pinky.arch.suse.de/tests/1422
Will check tomorrow the mentioned PR
Updated by jorauch over 5 years ago
Even with the reverted commit it is not working:
http://pinky.arch.suse.de/tests/1426
Updated by jorauch over 5 years ago
Actually it is not booting from the iso but from the system
Updated by szarate over 5 years ago
While looking at this with jrauch we found out that BOOTFROM=d is needed, as the UEFI_PFLASH variables come with the bootorder from an already installed system, so in this case... either BOOTFROM=d or use UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin but always you can check the manpage of qemu :) which helped us to figure it out
Updated by jorauch over 5 years ago
Will go for the UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin way since it feels more natural.
Working setting:
UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin
UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-%ARCH%-vars.bin (?)
Broken Setting:
UEFI_PFLASH_VARS=sle-12-SP4-aarch64-Build0366-Server-DVD@aarch64-gnome-encrypted-uefi-vars.qcow2
UEFI_PFLASH_VARS=%DISTRI%-%VERSION%-%ARCH%-Build%BUILD%-%FLAVOR%@%MACHINE%-%DESKTOP%-encrypted-uefi-vars.qcow2
Updated by rpalethorpe over 5 years ago
Or you can use BOOTFROM=cdrom. If it overrides the bootorder stored in the vars file then you don't need to change the vars file. However I think this is controlled by the UEFI firmware and I am not entirely sure what behaviour to expect.
To be honest, I don't like the idea of using a blank vars file on a system where an OS is supposed to be already installed just because it is not realistic. So I would only recommend that as a last resort.
UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-%ARCH%-vars.bin
This file name is decided by the firmware package. Unfortunately only the ARM firmware starts with aavmf IIRC, see the machine definitions.
Updated by jorauch over 5 years ago
- Status changed from In Progress to Feedback
I added BOOTFROM=cdrom to the testsuite, now we need to wait for a verification
Updated by jorauch over 5 years ago
- Status changed from Feedback to Resolved
Worked in the new build and did not break other architectures:
https://openqa.suse.de/tests/2023497#
Considering this as resolved
Updated by mgriessmeier over 5 years ago
- Status changed from Resolved to Workable
Thanks for that, but I'm going to reopen that - there are still 4 testsuites around which are missing the BOOTFROM=cdrom
https://openqa.suse.de/tests/2023588
https://openqa.suse.de/tests/2023508
https://openqa.suse.de/tests/2023509
https://openqa.suse.de/tests/2023490
Updated by jorauch over 5 years ago
- Status changed from Workable to Feedback
That would be the test suites:
- lvm+cancel_existing_cryptlvm
- cryptlvm+cancel_existing
- cryptlvm+activate_existing+import_users
- cryptlvm+activate_existing
Added the BOOTFROM=cdrom there
Waiting for next build to verify nothing is broken
Updated by jorauch over 5 years ago
- Status changed from Feedback to Resolved
Also works on latest build, now considering this as resolved
Updated by mgriessmeier over 5 years ago
- Status changed from Resolved to In Progress
jorauch wrote:
Also works on latest build, now considering this as resolved
doesn't look like working for me...
well initially it works, but the reboot after installation doesnt because it tries to boot again from cdrom - so I think it's related to your fix
https://openqa.suse.de/tests/2031194
https://openqa.suse.de/tests/2029209
https://openqa.suse.de/tests/2031195
https://openqa.suse.de/tests/2029221
please check again
Updated by jorauch over 5 years ago
x86: https://openqa.suse.de/tests/2029889#
Works just fine, so this is still an architecture specific problem and not broken in general by adding BOOTFROM=cdrom
Sadly we cannot see which entry is booted on the video
Updated by okurz over 5 years ago
- Related to action #36408: [sle][functional][u][aarch64][hard][sporadic][fast] test fails in bootloader_uefi - Grub not shown added
Updated by okurz over 5 years ago
#36408 is at least related after oorlov reopened it :)
Updated by jorauch over 5 years ago
I don't think so, since #36408 is about the firmware taking too long to boot (which can imho barely be fixed on test side) this is about either booting in the wrong medium (if mgriessmeier is right) or booting cryptlvm on aarch64 being broken (if I am correct)
Updated by jorauch over 5 years ago
According to the logs (https://openqa.suse.de/tests/2029202/file/serial0.txt):
>>> SUSE Linux Enterprise 12 SP4 installation program v5.1.14.0 (c) 1996-2018 SUSE LLC <<<
Starting udev... [ 6.030318] alua: device handler registered
(Lower quarter, definitely the second boot process)
Mgriessmeier is right here and we need to adapt grub_test for aarch64 and cryptlvm
Updated by mgriessmeier over 5 years ago
- Due date changed from 2018-09-11 to 2018-09-25
Updated by jorauch over 5 years ago
- Target version deleted (
Milestone 19)
Line #58 is the problem, we need another branch for this specific case or we somehow change the 'else' to an 'else except is UEFI'
Updated by jorauch over 5 years ago
Also the needle content of inst-bootmenu varies between the architectures
For UEFI we already have a boot mechanism that presses up, but it is not applied since it comes after the bootfrom=d branch -> the BOOTFROM=cdrom changed the behaviour here
-> either we go back one step and try to adapt the uefi variables (best when generating them)
-> or we accept the new behaviour and work around it
It looks to me that we are only lucky on the other architectures that the harddisk is selected by default and we have bad luck on aarch64.
For a workaround we would need to identify the specific variables that determine these suites and add another branch in handle_installer_medium_bootup
Updated by jorauch over 5 years ago
- Status changed from In Progress to Feedback
Updated by jorauch over 5 years ago
- Status changed from Feedback to In Progress
Something is still very messed up:
http://pinky.arch.suse.de/tests/1446#step/grub_test/4
Updated by jorauch over 5 years ago
This is the reason for the messup:
https://progress.opensuse.org/issues/11948
Need to use handle_uefi_boot_disk_workaround without breaking stuff
Updated by jorauch over 5 years ago
- Status changed from In Progress to Feedback
PR updated:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5756
Waiting for merge, then this can be closed
Updated by okurz over 5 years ago
- Status changed from Feedback to Workable
- Assignee deleted (
jorauch)
I think someone else should pick this up as long as jorauch is unavailable.
Updated by dheidler over 5 years ago
New version of PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5821
Updated by dheidler over 5 years ago
- Status changed from Workable to In Progress
Updated by SLindoMansilla over 5 years ago
- Due date changed from 2018-09-25 to 2018-10-09
- Status changed from In Progress to Feedback
Moving to sprint 27. Waiting for review of PR.
Updated by dheidler over 5 years ago
- Status changed from Feedback to Resolved
Verification: https://openqa.suse.de/tests/2104056#step/grub_test/2
Updated by okurz over 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: cryptlvm+cancel_existing
https://openqa.suse.de/tests/2163827
Updated by okurz over 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: cryptlvm+cancel_existing
https://openqa.suse.de/tests/2212543