Project

General

Profile

Actions

action #166175

open

[qe-core][jeos][rpi] test fails in firstrun

Added by zluo 3 months ago. Updated about 1 month ago.

Status:
Workable
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

We didn't have the issue with useradd. Maybe there is a change which breaks this test?

Observation

openQA test in scenario sle-15-SP7-JeOS-for-RaspberryPi-aarch64-jeos-realhw-RPi@RPi3B fails in
firstrun

Test suite description

Run a test on real RPi hardware. To be used eg. with RPi4 machine.
Setup: https://confluence.suse.com/pages/viewpage.action?spaceKey=~dheidler&title=Hardware+Automation

Reproducible

Fails since (at least) Build 1.4

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by zluo 3 months ago

  • Assignee set to mloviska
Actions #2

Updated by mloviska 3 months ago

  • Assignee changed from mloviska to zluo

Hi @zluo, the test fails because the dependency job creates the user before https://openqa.suse.de/tests/15293595#step/firstrun/28. I do not see what can be done from jeos-firstboot test over here

Actions #3

Updated by zluo 3 months ago

  • Assignee changed from zluo to pherranz

@pherranz can you help to answer the question, ist this hdd image related issue #164144?
We didn't see firstrun was broken before at useradd, thanks!

Actions #4

Updated by pherranz 3 months ago

  • Assignee changed from pherranz to zluo

Well the image creation has remained the same AFAIK, I've just enabled the 15-SP7 tests, not changed the test itself. As I can see, the firstrun test is already being ran in the image creation, although the creation of the bernhard user is already done. Maybe it's redundant to run firstrun again?

Actions #5

Updated by zluo 3 months ago

for record:
it works for sles 15 sp6. So this is broken now.

We had an issue with partition label 'dos', that broke also some tests (I cannot recall where, but I think it is another related issue with kiwi template change?). And there is indeed another change in workflow for Selfinstaller for Micro 6.1.
A new user will be created extra for allowing to access to cockpit WebUI. We can compare with an issue on Tumbleweed: https://progress.opensuse.org/issues/165800

Actions #6

Updated by rfan1 3 months ago

  • Tags set to bugbusters
  • Target version set to QE-Core: Ready
Actions #7

Updated by rfan1 3 months ago

See more detail information at https://suse.slack.com/archives/C02CSAZLAR4/p1726045681992649

Will double confirm with Fabian once he is back from vacation

Actions #8

Updated by rfan1 3 months ago

  • Assignee changed from zluo to rfan1
Actions #9

Updated by rfan1 3 months ago

  • Status changed from New to In Progress
Actions #10

Updated by jlausuch 3 months ago

I would suggest to change the schedule.. instead of firstrun, execute boot_to_desktop or similar..

Actions #11

Updated by rfan1 3 months ago

  • Status changed from In Progress to Workable
  • Assignee deleted (rfan1)

I think we need to check if we can exclude the firstrun module then

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/20212

Actions #12

Updated by zluo 3 months ago

  • Assignee set to szarate

@szarate Please help to assign this ticket to someone who is enable or can solve this issue. This is blocking further testing, thanks!

Actions #13

Updated by openqa_review about 1 month ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: jeos-realhw-RPi@RPi3B
https://openqa.suse.de/tests/15822912#step/firstrun/1

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

Actions

Also available in: Atom PDF