Project

General

Profile

Actions
Copy link

action #133547

closed

[qe-core][sle-micro-5.5][aarch64]test fails in disk_boot

Added by rfan1 9 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
zluo
Category:
Bugs in existing tests
Target version:
QA - QE-Core: Ready
Start date:
2023-07-31
Due date:
% Done:

0%

Estimated time:
Difficulty:
Tags:
bugbusters

Description

Observation

openQA test in scenario sle-micro-5.5-Default-aarch64-slem_combustion@aarch64 fails in
disk_boot

Test suite description

Extended test for combustion provisioning only

Reproducible

Fails since (at least) Build 7.1_1.3

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions
Copy link
 #1

Updated by zluo 9 months ago

  • Status changed from New to Workable
  • Assignee set to zluo

let me check this now

Actions
Copy link
 #2

Updated by zluo 9 months ago

As far I can say from https://openqa.suse.de/tests/11665776#step/disk_boot/6

There is a problem with disk which is in use at run time. After that it cannot start Combustion.

Actions
Copy link
 #3

Updated by zluo 9 months ago

  • Status changed from Workable to Rejected

Jose Lausuch told me a couple of days ago that condition of starting/scheduling sle-micro-5.5 is not ready yet, so please don't open any ticket for these tests for now. No single test passed through staging, so I won't spend time to investigate why these tests are broken

Actions
Copy link
 #4

Updated by rfan1 9 months ago

  • Status changed from Rejected to New
  • Assignee deleted (zluo)

The issue should be caused by corrupted https://openqa.suse.de/tests/11715358/asset/hdd/onlycombustion.qcow2 file. let me re-open this ticket.

Actions
Copy link
 #5

Updated by zluo 9 months ago

  • Status changed from New to Feedback
  • Assignee set to zluo
Actions
Copy link
 #6

Updated by rfan1 9 months ago

@zluo,
https://suse.slack.com/archives/C02CGKBCGT1/p1692167414273649

nevertheless the combustion or ignition tests were not really meant to be run outside of x86_64

okay, then wrong scheduling. Thanks for taking care of this!

Actions
Copy link
 #7

Updated by szarate 8 months ago

Zaoliang, does this happen if you do it on one of your raspberries?

Actions
Copy link
 #8

Updated by favogt 8 months ago

rfan1 wrote in #note-6:

nevertheless the combustion or ignition tests were not really meant to be run outside of x86_64

Why not?

Actions
Copy link
 #9

Updated by jlausuch 8 months ago

favogt wrote in #note-8:

rfan1 wrote in #note-6:

nevertheless the combustion or ignition tests were not really meant to be run outside of x86_64

Why not?

Probably because it needs some more work than for x86_64, however not impossible. Would be nice to have. Same in ALP.

Actions
Copy link
 #10

Updated by mloviska 8 months ago

favogt wrote in #note-8:

rfan1 wrote in #note-6:

nevertheless the combustion or ignition tests were not really meant to be run outside of x86_64

Why not?

Both configs are using a 3rd drive (vdc) to test partitioning and creating a new filesystem (ext4). IIRC, aarch64 could swap the labels thus it can lead to failure as this one

Actions
Copy link
 #11

Updated by jlausuch 8 months ago

I am ok to closing this ticket and create a new one for the implementation as new test enablement. Should be applicable to all transactional systems that we are testing (MicroOS, SLE Micro and ALP) and possibly to all architectures.

Actions
Copy link
 #12

Updated by favogt 8 months ago

mloviska wrote in #note-10:

favogt wrote in #note-8:

rfan1 wrote in #note-6:

nevertheless the combustion or ignition tests were not really meant to be run outside of x86_64

Why not?

Both configs are using a 3rd drive (vdc) to test partitioning and creating a new filesystem (ext4). IIRC, aarch64 could swap the labels thus it can lead to failure as this one

Which looks like either some QA or product bug (VM host or guest) and that should be investigated.

Actions
Copy link
 #13

Updated by zluo 4 months ago

  • Status changed from Feedback to Resolved

we don't have this issue anymore on sle-micro 6.0 : https://openqa.suse.de/tests/13225317

Actions
Copy link

Also available in: Atom PDF