Bug 1707389

When I install fedora 30 via virt-install on a fedora 29 host 
I get the following error:

[    8.430263] dracut-initqueue[859]:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
[    8.430360] dracut-initqueue[859]:                                  Dload  Upload   Total   Spent    Left  Speed
[    8.925254] random: crng init done
[    8.925257] random: 7 urandom warning(s) missed due to ratelimiting
100  355M  100  355M    0     0   193M      0  0:00:01  0:00:01 --:--:--  193M
[   10.380433] dracut-initqueue[859]: losetup: cannot find an unused loop device: No such device
[   10.381147] dracut-initqueue[859]: losetup: /tmp/curl_fetch_url1/install.img: failed to use device: No such device
[   10.382993] dracut-initqueue[859]: mount: /run/initramfs/squashfs: can't find in /etc/fstab.
[   10.383220] dracut: FATAL: Failed to find a root filesystem in /tmp/curl_fetch_url1/install.img.
[   10.383227] dracut: Refusing to continue
[   10.416359] dracut-initqueue[859]: RTNETLINK answers: File exists
[   10.575848] printk: systemd-shutdow: 23 output lines suppressed due to ratelimiting
[   10.581250] systemd-shutdown[1]: Syncing filesystems and block devices.
[   10.581500] systemd-shutdown[1]: Sending SIGTERM to remaining processes...
[   10.591371] systemd-journald[211]: Received SIGTERM from PID 1 (systemd-shutdow).
[   10.656100] systemd-shutdown[1]: Sending SIGKILL to remaining processes...
[   10.657432] systemd-shutdown[1]: Unmounting file systems.
[   10.657890] [1296]: Remounting '/var/lib/nfs/rpc_pipefs' read-only in with options '(null)'.
[   10.658354] [1297]: Unmounting '/var/lib/nfs/rpc_pipefs'.
[   10.658840] [1298]: Remounting '/' read-only in with options 'size=1006200k,nr_inodes=251550'.
[   10.659223] systemd-shutdown[1]: All filesystems unmounted.
[   10.659226] systemd-shutdown[1]: Deactivating swaps.
[   10.659236] systemd-shutdown[1]: All swaps deactivated.
[   10.659238] systemd-shutdown[1]: Detaching loop devices.
[   10.659298] systemd-shutdown[1]: All loop devices detach


Machine Type = IBM z 
 
---boot type---
virt-install
 
--- cmdline used to launch install---
virt-install --name s38kvm12 --disk size=12,cache=none,io=native --memory=2048 --vcpus=2 --location  https://download.fedoraproject.org/pub/fedora-secondary/releases/30/Server/s390x/os --initrd-inject=/home/cborntra/s38kvm12.ks --extra-args 
 

If I do not use a kickstart file installation works.

The same kickstart file and command line does work fine with a f29 installation source.

---Install repository type---
Internet repository
 
---Install repository Location---
https://download.fedoraproject.org/pub/fedora-secondary/releases/30/Server/s390x/os
 
---Point of failure---
Other failure during installation (stage 1)

even trivial kickstart files like
---
text
----

will be enough to trigger the failure.


Fyi ... 
... the kickstart file itself does not matter. Even an incredible simple one (just containing one line) is enough. It seems that just the existence of a kickstart file is triggering the problem.

As the system shuts down after that (and it does not write any data on the disk) I can not provide any further data.

The problem is really simple to reproduce:
1. Have Fedora29 on the host (with kvm and virt-install)
2. run
virt-install --name test --disk size=12 --memory=2048 --vcpus=2 --location https://download.fedoraproject.org/pub/fedora-secondary/releases/30/Server/s390x/os --initrd-inject=/home/cborntra/test.ks --extra-args "inst.ks=file:///test.ks"


Using
https://download.fedoraproject.org/pub/fedora-secondary/releases/29/Server/s390x/os
instead of 
https://download.fedoraproject.org/pub/fedora-secondary/releases/30/Server/s390x/os
works fine ....

Created attachment 1565159 [details]
sample kickstart file that matches the command line

Thanks for the report. I haven't seen problems when kickstart is accessed over http from a remote location, so this might be related to the injected ks file.

I couldn't reproduce the failure on my ppc64le F-30 workstation, so I wonder if this is really s390x specific.

can't reproduce on a RHEL 8 host (which is a z/VM guest), I wonder if it could be some timing issue, 

[   10.380433] dracut-initqueue[859]: losetup: cannot find an unused loop device: No such device

points to a problem with loop devices in the kernel.

------- Comment From cborntra.com 2019-05-14 11:18 EDT-------
Turns out that I can only reproduce this with a user on the host, with root it seems to work. Will investigate if this is a timing issue or a setup problem,

------- Comment From cborntra.com 2019-05-17 07:19 EDT-------
So I reinstalled the host and now the problem is gone. So I guess it is
a. some configuration issue that is now solved
b. really a timing issue

Thanks for the update.

Created attachment 1587367 [details]
install log

I'm running into the same bug while installing f30 on x86 vm via 

virt-install --connect qemu:///system --name fedora --ram 5000 --arch x86_64 --os-type linux --os-variant fedora28 --disk fedora.qcow2,size=15 --location=https://dl.fedoraproject.org/pub/fedora/linux/releases/30/Everything/x86_64/os --initrd-inject ./f30-x86_64.ks --extra-args=inst.ks=file:/f30-x86_64.ks console=ttyS0 rd.debug rd.shell --nographics --boot uefi --check path_in_use=off

Please see install.log attached.

Using f29 url in --location works as expected

Thanks for the details. Lets reopen it, assign to dracut and drop the s390x specifics. Because it sounds like something is wrong with the dracut environment, the stage2 image downloaded too fast/early?

Created attachment 1587368 [details]
lsmod

I tried this in the emergency shell:

dracut:/# losetup -f
losetup: cannot find an unused loop device: No such device
dracut:/# modprobe loop
[  922.012119] loop: module loaded
dracut:/# losetup -f
/dev/loop0

looks like loop module isn't loaded (see lsmod attached)

Hmm, could it be a missing dependency between some systemd units?

As a workaround I've aded "rd.driver.pre=loop" (note driver has to be loaded as part of .pre) to my cmdline, i.e: 

virt-install --connect qemu:///system --name fedora --ram 5000 --arch x86_64 --os-type linux --os-variant fedora28 --disk fedora.qcow2,size=15 --location=http://192.168.122.1:8000/30/x86_64 --initrd-inject ./f30-x86_64.ks --extra-args=inst.ks=file:/f30-x86_64.ks console=ttyS0 rd.driver.pre=loop rd.debug rd.shell --nographics --boot uefi --check path_in_use=off

works for both f30 and rawhide

This is not limited to x86_64 as I've reproduced it on aarch64 (VM via libvirt), fair to assume other architectures are affected too...

Uff, getting it now all the time when trying to create installer image for rawhide on s390x with lorax in a rawhide chroot, host is an up-to-date F-30.
On the F-30 host issuing "losetup -f" loads the loop module and returns /dev/loop0. I think I need to pass /dev/loop-control to the chroot somehow ...

So the case with chroot is caused by using the nspawn mode in mock, all works well in classic chroot mode.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

hit same issue when  kickstart install Fedora 31 released

'''
 dracut-initqueue[860]: losetup: cannot find an unused loop device: No such device
'''

I just encountered this with Fedora 33 beta.  I’m using virt-install similar to comments 10 and 15.  Adding rd.driver.pre=loop to --extra-args allows the installation to complete.

Please update the version to Fedora 33.

moving to F-33 ...

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.