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.
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.