Bug 1143051 - [Build 20190723] openQA test fails in firstrun - system doesn't boot up anymore
[Build 20190723] openQA test fails in firstrun - system doesn't boot up anymore
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
https://openqa.opensuse.org/tests/989...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-26 14:22 UTC by Zaoliang Luo
Modified: 2019-12-19 14:18 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zaoliang Luo 2019-07-26 14:22:27 UTC
please my ticket as well. I checked this issue on o3:

https://progress.opensuse.org/issues/54623

100 test runs on O3:
https://openqa.opensuse.org/tests/991213#next_previous

We can see a lot of test runs just failed.
Normal the rebooting just take about 20 seconds, we have set timeout for 1000.
But I don't think this is timeout issue. 

Logs can be found at: https://openqa.opensuse.org/tests/989200#downloads
Unfortunately post_fail_hook doesn't work in this case so there is no logs than openqa logs available.



## Observation

openQA test in scenario opensuse-Tumbleweed-JeOS-for-kvm-and-xen-x86_64-jeos-extra@64bit_virtio-2G fails in
[firstrun](https://openqa.opensuse.org/tests/989200/modules/firstrun/steps/9)

## Test suite description
Same as jeos, plus some more tests.


## Reproducible

Fails since (at least) Build [20190311](https://openqa.opensuse.org/tests/877894)


## Expected result

Last good: (unknown) (or more recent)


## Further details

Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=JeOS-for-kvm-and-xen&machine=64bit_virtio-2G&test=jeos-extra&version=Tumbleweed)
Comment 1 Franck Bui 2019-12-17 07:54:59 UTC
I think firstrun is handled by the jeos folks so let's reassign this old bug accordingly.
Comment 2 Fabian Vogt 2019-12-19 14:18:00 UTC
(In reply to Franck Bui from comment #1)
> I think firstrun is handled by the jeos folks so let's reassign this old bug
> accordingly.

I debugged this a while ago and it was caused by systemd losing state during daemon-reloads triggered by btrfsmaintenance startup, so likely a dup of bug 1137373.

It's not reproducible for several months now, so let's close it as WORKSFORME.