Hide Forgot
Description of problem: Installing Fedora-Server-dvd-x86_64-Rawhide-20220704.n.0.iso with virt-install failed with "Couldn't find kernel for install tree",as there is no isolinux path while virt-install fetches vmlinuz and initrd.img from that path The latest workable media I can tell is Fedora-Server-dvd-x86_64-Rawhide-20220614.n.0.iso This breaks all the fedora-release-autotest testcases for virtualization. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Proposed as a Blocker for 37-final by Fedora user lnie using the blocker tracking app because: This seems affects: The installer must be able to complete an installation using all supported interfaces.
If the problem really is virt-install expecting to find the files in isolinux, this will need to be fixed in virt-install, as we are not using syslinux/isolinux any more so that directory is not going to be there. However, looking at the virt-manager source, I don't see it looking for 'isolinux' for anything except Mandriva/Mageia. Are you sure it's doing that?
Thanks for your information,I'm gonna to reassign to virt-manager. Actually,I'm sure until you propose the doubt.I clone the virt-manager source,and locate the error message,and have the code print the "kpath" and "ipath",it prints "isolinux/vmlinuz" for kernel path and "isolinux/initrd.img" for initrd path,the workable media has isolinux,while the "broken" media dosn't. However,I didn't look at the code deeply. Let's see what the maintainers will say.
Oh, well with that info I definitely agree that seems like the problem. Just makes me wonder where it gets those paths from. virt-manager folks, the change here is https://bugzilla.redhat.com/show_bug.cgi?id=2092065 - we're now building x86_64 images with grub2 as the bootloader for BIOS as well as UEFI, there is no use of syslinux/isolinux any more, so whatever is relying on these files to be in the tree should not be. Presumably it could use the ones from pxelinux/ instead.
(In reply to Adam Williamson from comment #4) > Oh, well with that info I definitely agree that seems like the problem. Just > makes me wonder where it gets those paths from. They come from the libosinfo database https://gitlab.com/libosinfo/osinfo-db/-/blob/ad74fb68437f5f91f733fecc3db479c97f31797f/data/os/fedoraproject.org/fedora-rawhide.xml.in#L25 <media arch="x86_64"> <iso> <volume-id>Fedora-.*-dvd-x86_64-rawh</volume-id> </iso> <kernel>isolinux/vmlinuz</kernel> <initrd>isolinux/initrd.img</initrd> </media> > virt-manager folks, the change here is > https://bugzilla.redhat.com/show_bug.cgi?id=2092065 - we're now building > x86_64 images with grub2 as the bootloader for BIOS as well as UEFI, there > is no use of syslinux/isolinux any more, so whatever is relying on these > files to be in the tree should not be. Presumably it could use the ones from > pxelinux/ instead. What, if any, was the difference between the files in isolinux/ and images/pxeboot historically ?
(In reply to Daniel Berrangé from comment #5) > > virt-manager folks, the change here is > > https://bugzilla.redhat.com/show_bug.cgi?id=2092065 - we're now building > > x86_64 images with grub2 as the bootloader for BIOS as well as UEFI, there > > is no use of syslinux/isolinux any more, so whatever is relying on these > > files to be in the tree should not be. Presumably it could use the ones from > > pxelinux/ instead. > > What, if any, was the difference between the files in isolinux/ and > images/pxeboot historically ? Looking at F36, I see they are 100% identical in content, so the change in paths is trivial.
Fix posted upstream at https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/481 We should probably update osinfo-db content in stable fedora branches too.
*** Bug 2107440 has been marked as a duplicate of this bug. ***
*** Bug 2103834 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.
I think this got solved? The commit was merged upstream, and a new release has gone stable for F35, F36, and F37/Rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2022-393d56c08c https://bodhi.fedoraproject.org/updates/FEDORA-2022-f6999232be https://bodhi.fedoraproject.org/updates/FEDORA-2022-ce99b1606b Also, building images for openQA is working, which uses virt-install, so that implies this got fixed. I'm gonna close it, please re-open if there are still issues.
I tested this ISO -> Fedora-Server-dvd-x86_64-37-20220816.n.0.iso and it worked fine to install both with virt-manager and with the virt-install command line: virt-install --name deleteme37 --memory 2048 --vcpus 2 --disk size=8 --cdrom ~/ISOs/Fedora-Server-dvd-x86_64-37-20220816.n.0.iso
Sorry for the delay reply,I was pretty busy with other stuff.Please note that --cdrom param works even without the osinfo-db update. fedora-release-autotest needs to use --extra-args which is supposed to be used together with --location param Here is the reproducer command : virt-install --connect qemu:///system --name FT --ram=2048 --vcpus=2 --location=/var/lib/libvirt/images/$image_name --disk path=/var/lib/libvirt/images/test.qcow2,size=15,format=qcow2,device=disk,bus=virtio,perms=rw,cache=writethrough --network network=default,model=virtio --extra-args="inst.ks=https://lnie.fedorapeople.org/beaker-kvm-install.ks" f36 update works,however f37 and rawhide doesn't.The command still failed with "Couldn't find kernel for install tree" on f37,while there is a new libvirt bug on rawhide ：https://bugzilla.redhat.com/show_bug.cgi?id=2119633
Betablocker +1
lnie: createhdds does not use `--cdrom`. It uses commands like this: virt-install --disk size=20,path=disk_f37_desktop_4_x86_64.qcow2.tmp --os-variant fedora-unknown -x inst.ks=file:/desktop.ks --initrd-inject /home/adamw/local/createhdds/desktop.ks --location https://download.fedoraproject.org/pub/fedora/linux/releases/37/Everything/x86_64/os/ --name createhdds --memory 3072 --noreboot --wait -1 --debug --graphics vnc --noautoconsole --network user are you passing `--location` with the value being an ISO name?
The man page says this: --location allows things like --extra-args for kernel arguments, and using --initrd-inject. If you want to use those options with CDROM media, you can pass the ISO to --location as well which works for some, but not all, CDROM media. I guess that may be a different code path which the patch didn't fix.
OK, so one problem I see here: the upstream patch changed `fedora-rawhide.xml.in`, but there is no `fedora-37.xml.in` and it didn't change `fedora-unknown.xml.in`. So the change likely doesn't apply to Branched. Upstream needs to add a fedora-37.xml.in which treats this the same as Rawhide.
(In reply to Adam Williamson from comment #17) > OK, so one problem I see here: the upstream patch changed > `fedora-rawhide.xml.in`, but there is no `fedora-37.xml.in` and it didn't > change `fedora-unknown.xml.in`. So the change likely doesn't apply to > Branched. Opps, thanks for pointing that out, sent the obvious fix : https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/501 > Upstream needs to add a fedora-37.xml.in which treats this the > same as Rawhide. Yep, we need to get that prepped
BTW, if you want to test the change locally, then copy /usr/share/osinfo/os/fedoraproject.org/fedora-unknown.xml to /etc/osinfo/os/fedoraproject.org/fedora-unknown.xml and make the initrd/kernel path change in that copied file, and it'll override the RPM provided version for virt-install.
Discussed during the 2022-08-22 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Beta)" was made as a violation of the virtualization criteria per kparal's comment on the ticket. We also note its impact on important test systems (anaconda CI and fedora-release-autotest). [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-08-22/f37-blocker-review.2022-08-22-16.01.txt
Daniel, can we please get a downstream build with the change? This is an F37 Beta blocker, so we need it fixed (and we also need to know if the follow-up problem - https://bugzilla.redhat.com/show_bug.cgi?id=2119633 - also exists on F37.
Re-assigning to Victor since he has been handling osinfo-db updates in Fedora
FEDORA-2022-9df0b297cc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9df0b297cc
FEDORA-2022-9df0b297cc has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-9df0b297cc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9df0b297cc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
lnie: so by setting to VERIFIED I guess you mean this is fixed with the update? Did you run into https://bugzilla.redhat.com/show_bug.cgi?id=2119633 on F37 too? If so, should we propose that one as a blocker? Thanks!
FEDORA-2022-bf0a4da0e8 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-bf0a4da0e8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-bf0a4da0e8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Adam Williamson from comment #25) > lnie: so by setting to VERIFIED I guess you mean this is fixed with the > update? Did you run into https://bugzilla.redhat.com/show_bug.cgi?id=2119633 > on F37 too? If so, should we propose that one as a blocker? > > Thanks! Er,yes,this bug is fixed,and I didn't see #2119633 on 37,otherwise I would propose that one as a f37 blocker. I think we are supposed to give VERIFIED to this bug even if I run into #2119633 on f37. Sorry for the confusing anyway.
Yep that's right, but I just wanted to check on the overall situation. So with this update, it all works properly on F37, it sounds like?
I also checked --cdrom and other options before I set VERIFIED,I think that's enough.But after saw your comment,I played with it for a while again and didn't see any bug,I guess we can safely say that it all works properly?
awesome, sounds great. Thanks!
FEDORA-2022-bf0a4da0e8 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.