Project

General

Profile

Actions

action #158404

closed

[qe-core][jeos]test fails in prepare_firstboot

Added by zluo 2 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Regressions/Crashes
Target version:
Start date:
2024-04-02
Due date:
2024-04-17
% Done:

0%

Estimated time:

Description

Can you help to check the hardware please?

Observation

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

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 2.5

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by okurz 2 months ago

  • Tags set to infra, rpi
  • Category set to Regressions/Crashes
  • Priority changed from Normal to High
  • Target version set to Ready
Actions #2

Updated by okurz 2 months ago

  • Tags changed from infra, rpi to infra, rpi, reactive work
Actions #3

Updated by okurz 2 months ago

  • Priority changed from High to Urgent
Actions #4

Updated by dheidler 2 months ago

  • Assignee set to dheidler
Actions #6

Updated by dheidler 2 months ago

  • Status changed from New to Feedback

Running the test again doesn't raise the same issue: https://openqa.suse.de/tests/13924015

The empty serial log at the broken test (not even the bootloader messages show up) suggests that the SUT was not powered on.
The additions to the shelly script might make this visible in the future:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19008

Actions #7

Updated by livdywan 2 months ago

  • Status changed from Feedback to In Progress

dheidler wrote in #note-6:

Running the test again doesn't raise the same issue: https://openqa.suse.de/tests/13924015

The empty serial log at the broken test (not even the bootloader messages show up) suggests that the SUT was not powered on.
The additions to the shelly script might make this visible in the future:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/19008

Please remember we can't have an urgent ticket in feedback. You need to confirm that the priority should in fact be lower, or implement mitigations to allow that

Actions #8

Updated by openqa_review 2 months ago

  • Due date set to 2024-04-17

Setting due date based on mean cycle time of SUSE QE Tools

Actions #9

Updated by livdywan 2 months ago ยท Edited

How about we confirm how reproducible this is? https://openqa.suse.de/tests/overview?build=poo%23158404 There's barely any jobs running and this is a 15min job so it should be fine to run those (openqa-clone-job --repeat 1
00 --within-instance https://openqa.suse.de/tests/13919749 _GROUP=0 BUILD=poo#1584
04
)

Actions #10

Updated by dheidler 2 months ago

  • Status changed from In Progress to Resolved
  • Priority changed from Urgent to High

I wouldn't run that many jobs as it would wear down the sd cards.

But the working test at https://openqa.suse.de/tests/13924015 shows that is was just a tmp issue.
So I guess we can remove the urgency - especially as the PR making the power cycling more verbose is now merged.

As the PR is not really necessary, I guess we can resolve this one.

Actions

Also available in: Atom PDF