Project

General

Profile

Actions
Copy link

action #158404

closed

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

Added by zluo 6 months ago. Updated 6 months 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 6 months 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 6 months ago

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

Updated by okurz 6 months ago

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

Updated by dheidler 6 months ago

  • Assignee set to dheidler
Actions
Copy link
 #6

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

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

Updated by openqa_review 6 months 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 6 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
Copy link
 #10

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

Also available in: Atom PDF