action #66200

[microos] MicroOS: test fails in bootloader_uefi

Added by lnussel about 2 years ago. Updated 4 months ago.

In Progress
Bugs in existing tests
Target version:
Start date:
Due date:
% Done:


Estimated time:



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

Test suite description

The test does not hit the correct line in MicroOS. I think it executes this one:

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.


Fails since (at least) Build 11.1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest


#1 Updated by lnussel about 2 years ago

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

looking into it myself atm

#2 Updated by lnussel about 2 years ago

pretty messed up. 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/ 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/ should be moved to a generic location that can then be reused by other products.

#3 Updated by lnussel about 2 years ago

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

#4 Updated by lnussel about 2 years ago

  • Assignee deleted (lnussel)

#5 Updated by SLindoMansilla almost 2 years ago

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

#6 Updated by okurz 9 months ago

This ticket was set to "Normal" priority but was not updated within the SLO period for "Normal" tickets (365 days) as described on . 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

#7 Updated by maritawerner 4 months 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?

#8 Updated by lnussel 4 months ago

The description refers to microos-15.2-MicroOS and was fixed by adding yet another hack to the already crappy code

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 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.

Also available in: Atom PDF