Project

General

Profile

Actions
Copy link

action #158404

closed

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

Added by zluo 28 days ago. Updated 25 days ago.

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

0%

Estimated time:
Tags:
infra, reactive work, rpi

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
Copy link
 #1

Updated by okurz 28 days ago

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

Updated by okurz 28 days ago

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

Updated by okurz 28 days ago

  • Priority changed from High to Urgent
Actions
Copy link
 #4

Updated by dheidler 28 days ago

  • Assignee set to dheidler
Actions
Copy link
 #6

Updated by dheidler 27 days 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
Copy link
 #7

Updated by livdywan 27 days 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
Copy link
 #8

Updated by openqa_review 27 days ago

  • Due date set to 2024-04-17

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

Actions
Copy link
 #9

Updated by livdywan 27 days 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
Copy link
 #10

Updated by dheidler 25 days 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
Copy link

Also available in: Atom PDF