QA (public) » openQA Project (public) » openQA Tests (public)

This is not related to bootloader changes for aarch64, the SUT is already booting.

If you check serial0.txt in the end...

[    0.005048] ITS@0x8080000: Unable to locate ITS domain handle
[    0.005087] ITS@0x8080000: Unable to locate ITS domain handle

Which could be already a starting point. If you look at the video, it stopped in the same screen for quite some time. and the SUT did not react to the test sending the esc key, (about 3 mins later)

Seems a bit sporadic, I would suggest to run the same scenario 100 times with memory dumps enabled... so that a developer could look at it, if it happens again...

I found today that TW has same issue: https://openqa.opensuse.org/tests/789009#step/first_boot/1

may be same problem with ppc64le snapshot 20181112: https://openqa.opensuse.org/tests/794116#step/first_boot/41

Same problem (?) on TW aarch64 with gnome only (kde is fine): https://openqa.opensuse.org/tests/795069

All the three last mentioned jobs seem to show the same problem but different to the original one: The getty login prompt shows up on the serial device (multiple times) so I suspect it's a different issue.

Very likely the abi break of mozjs60, that I 'cured' in openSUSE:Factory by rebuilding everything aginst mozjs60

Just executed, for ARM and PowerPC:

for ARCH in ARM PowerPC; do
 for pkg in $(dependson mozjs60); do
   osc rebuildpac openSUSE:Factory:${ARCH} $pkg -r standard;
 done;
done

both archs should thus have gnome-shell (and other consumers) rebuilt against mozjs60 with the new ABI

(I just triggered the same for libzypp, which also had an ABI break)

Here is a similar problem on aarch64, where the SUT seems to boot, but it does not reach the login prompt.
https://openqa.suse.de/tests/2261868#step/first_boot/6

We have timeout problem on first_boot on LTP on ipmi backend:
https://openqa.suse.de/tests/2262596#step/first_boot/2
Any idea what that caused?
Problem was with GRUB_TIMEOUT setting first to 300 (good for IPMI) and even with 900.
But maybe #31375 is more related to our issue.

@pvorel I think this is neither #42863, this ticket, nor #31375, rather its own, new thing. The 'ret' key in the grub screen does not have an effect. Better track as its own issue.

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

This bug is still referenced in a failing openQA test: minimal_x+uefi
https://openqa.suse.de/tests/2326139