#7405 [s390x] Latest cloud-base and (or) container images are failing for F28 and rawhide composes
Closed: Fixed by syeghiay. Opened by sinnykumari.

By looking into last few nightly composes for container and cloud on s390x, I observed that we never had all of the artifacts built successfully in a single compose.
For example:
* From Fedora-28-20180317.n.0 - cloud-base and container-minimal-base image built successfully. container-base image failed
* From Fedora-28-20180317.n.0 - cloud-base and container-base image built successfully. conatiner-minimal-base image failed.

Similar results from rest of the latest compose.

I did some local run of these images using imagefactory and each time following behavior has been seen:
* kernel.img and initrd files get downloaded, vm gets launched to start install process.
* vm boots and it reaches at

[  OK  ] Reached target System Initialization.
[  OK  ] Reached target Basic System.
[   35.891858] dracut-initqueue[817]: RTNETLINK answers: File exists
[   76.688981] random: crng init done
[  427.634076] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
---
[  625.922797] dracut-initqueue[817]: Warning: dracut-initqueue timeout - starting timeout scripts
[  625.923855] dracut-initqueue[817]: Warning: Could not boot.
         Starting Dracut Emergency Shell...
Warning: /dev/root does not exist
dracut:/# 

and vm install stops here.

Not sure what is the reason of this behavior. Can it be something related to network between s390x machine and koji ?


Point to note that imagefactory run with same configuration may work fine later on.

For example, few hours earlier imagefactory run failed while trying to build container-base image. koji-f28-build-25881314-base.ks and tdl-s390x.xml were taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=25881314 .

$ imagefactory --debug base_image --file-parameter install_script koji-f28-build-25881314-base.ks tdl-s390x.xml  --parameter offline_icicle true

Re-ran above imagefactory command few minutes back and image got built successfully this time.

Usually the timeout and "Warning: /dev/root does not exist" means that the installer wasn't able to download the install.img over the network. The cause can be incorrect network setup inside the VM (unlikely) or network issues on the connection between the VM and the install.img location (which should be a fedora infra server)

This has been fixed.

Metadata Update from @syeghiay:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata