Bug 2103835

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.