Project

General

Profile

Actions

action #66200

open

[microos] MicroOS: test fails in bootloader_uefi

Added by lnussel almost 4 years ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Bugs in existing tests
Target version:
-
Start date:
2020-04-29
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario microos-15.2-MicroOS-Image-x86_64-microos@uefi fails in
bootloader_uefi

Test suite description

The test does not hit the correct line in MicroOS. I think it executes this one:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/8502b0059ec4e98c23f4e88fb1dce6b9fdd78a4b/lib/bootloader_setup.pm#L349

So doesn't hit "down" often enough.

The same would hit MicroOS for TW but uefi is not enabled there to test the kiwi images.

Reproducible

Fails since (at least) Build 11.1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by lnussel almost 4 years ago

  • Status changed from New to In Progress
  • Assignee set to lnussel

looking into it myself atm

Actions #2

Updated by lnussel almost 4 years ago

pretty messed up. bootloader.pm exists early if BOOT_HDD_IMAGE is set. bootloader_uefi does something though. So on JeOS there's an explicit path to load a differnt file jeos/grub2.pm in that case. Looks like bootloader_uefi is also used on aarch64 when booting from hard disks.
The code should be changed to also not be used on disk boots. Instead jeos/grub2.pm should be moved to a generic location that can then be reused by other products.

Actions #3

Updated by lnussel almost 4 years ago

will submit patch that switched the gfxboot detection to using needles as first step

Actions #4

Updated by lnussel almost 4 years ago

  • Assignee deleted (lnussel)
Actions #5

Updated by SLindoMansilla over 3 years ago

  • Subject changed from MicroOS: test fails in bootloader_uefi to [microos] MicroOS: test fails in bootloader_uefi
Actions #6

Updated by okurz over 2 years ago

This ticket was set to "Normal" priority but was not updated within the SLO period for "Normal" tickets (365 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives . Please consider picking up this ticket within the next 365 days or just set the ticket to the next lower priority of "Low" (no SLO related time period). This update was done as agreed within the SUSE QE Sync call 2021-09-01

Actions #7

Updated by maritawerner over 2 years ago

@lnussel: what is meant by microos here? The tumbleweed version of microos? The Leap version? Could we maybe label that correctly, or even close the ticket if it is irrelevant?

Actions #8

Updated by lnussel over 2 years ago

The description refers to microos-15.2-MicroOS and was fixed by adding yet another hack to the already crappy code https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10205.

The conclusion from discovering the issue is that the code needs improvement and refactoring to be less fragile as mentioned in #66200-2. That's also what https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10161 is about. However, looks like there was no interest in investing in cleaner code.

So even though the failure is not visible anymore the ticket is not irrelevant. May make sense to change category to improvement rather than handling as bug though.

Actions #9

Updated by slo-gin over 1 year ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #10

Updated by slo-gin about 1 month ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions

Also available in: Atom PDF