Bug 1663157

Summary: RHEL-8 snap3/3.1 installation stuck (dots / configuring storage)
Product: Red Hat Enterprise Linux 8 Reporter: Jakub Krysl <jkrysl>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: dlehman, mkolman, sbueno, vtrefny
Target Milestone: rcKeywords: Regression, TestBlocker
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-15 01:21:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Comment 1 Jakub Krysl 2019-01-03 10:32:13 UTC
Setting to regression as compose RHEL-8.0-20181204.0 is working https://beaker.engineering.redhat.com/recipes/6358362#installation

Setting to TestBlocker, as this is quite unique server with 12* 10TB drives for VDO testing.

Note:
This seems to be very similar to BZ 1582233, which is already fixed.

Comment 2 Martin Kolman 2019-01-03 11:17:53 UTC
While it indeed seems visually similar to bug 1582233 I think this could really be a result of the specific storage setup. Maybe some operations just take so long on 120 TB of to either appear stuck or hit a timeout somewhere ? Adding Dave and Vojta from the storage team to CC.

Comment 3 Jakub Krysl 2019-01-08 09:05:52 UTC
We have another server that reproduces this, storageqe-82.lab.eng.brq.redhat.com. Job:
https://beaker.engineering.redhat.com/recipes/6369103

Both are SuperMicro with quite a lot of RAM, but storageqe-82 does not have such big storage.

It seems the main thing in common is NVMe m.2 boot drive.

Comment 4 Jakub Krysl 2019-01-08 09:43:08 UTC
Installation passed with newer nightly compose on storageqe-90: https://beaker.engineering.redhat.com/recipes/6374001 (kernel -58)

Could this be DUP of BZ 1663559?

Comment 5 Samantha N. Bueno 2019-03-15 01:21:59 UTC
(In reply to Jakub Krysl from comment #4)
> Installation passed with newer nightly compose on storageqe-90:
> https://beaker.engineering.redhat.com/recipes/6374001 (kernel -58)
> 
> Could this be DUP of BZ 1663559?

Hard for me to say. If this is no longer an issue, however, I'm going to go ahead and close this. Please feel free to re-open if the issue persists.