Bug 2103835 - failed to install server iso with virt-install due to the missing of isolinux in the media
Summary: failed to install server iso with virt-install due to the missing of isolinux...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: osinfo-db
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Victor Toso
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 2103834 2107440 (view as bug list)
Depends On:
Blocks: F37BetaBlocker 2092065
TreeView+ depends on / blocked
 
Reported: 2022-07-05 04:28 UTC by lnie
Modified: 2022-08-31 17:39 UTC (History)
15 users (show)

Fixed In Version: osinfo-db-20220727-3.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-31 17:39:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description lnie 2022-07-05 04:28:15 UTC
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:

Comment 1 Fedora Blocker Bugs Application 2022-07-05 04:32:25 UTC
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.

Comment 2 Adam Williamson 2022-07-05 06:08:55 UTC
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?

Comment 3 lnie 2022-07-05 07:30:14 UTC
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.

Comment 4 Adam Williamson 2022-07-05 15:57:29 UTC
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.

Comment 5 Daniel Berrangé 2022-07-06 08:09:35 UTC
(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 ?

Comment 6 Daniel Berrangé 2022-07-06 08:53:15 UTC
(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.

Comment 7 Daniel Berrangé 2022-07-06 08:57:25 UTC
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.

Comment 8 Daniel Berrangé 2022-07-15 12:52:06 UTC
*** Bug 2107440 has been marked as a duplicate of this bug. ***

Comment 9 Cole Robinson 2022-07-26 19:32:57 UTC
*** Bug 2103834 has been marked as a duplicate of this bug. ***

Comment 10 Ben Cotton 2022-08-09 13:19:59 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

Comment 11 Adam Williamson 2022-08-16 20:16:11 UTC
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.

Comment 12 Geraldo Simião 2022-08-17 02:48:40 UTC
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

Comment 13 lnie 2022-08-19 03:33:13 UTC
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

Comment 14 Luna Jernberg 2022-08-22 16:46:41 UTC
Betablocker +1

Comment 15 Adam Williamson 2022-08-22 16:50:36 UTC
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?

Comment 16 Adam Williamson 2022-08-22 16:52:07 UTC
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.

Comment 17 Adam Williamson 2022-08-22 16:56:06 UTC
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.

Comment 18 Daniel Berrangé 2022-08-22 17:03:21 UTC
(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

Comment 19 Daniel Berrangé 2022-08-22 17:05:09 UTC
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.

Comment 20 Geoffrey Marr 2022-08-22 21:23:26 UTC
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

Comment 21 Adam Williamson 2022-08-26 17:03:33 UTC
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.

Comment 22 Daniel Berrangé 2022-08-26 17:13:00 UTC
Re-assigning to Victor since he has been handling osinfo-db updates in Fedora

Comment 23 Fedora Update System 2022-08-26 19:56:17 UTC
FEDORA-2022-9df0b297cc has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-9df0b297cc

Comment 24 Fedora Update System 2022-08-27 17:07:30 UTC
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.

Comment 25 Adam Williamson 2022-08-29 17:13:12 UTC
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!

Comment 26 Fedora Update System 2022-08-29 21:08:17 UTC
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.

Comment 27 lnie 2022-08-30 02:55:09 UTC
(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.

Comment 28 Adam Williamson 2022-08-30 06:12:16 UTC
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?

Comment 29 lnie 2022-08-30 13:08:17 UTC
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?

Comment 30 Adam Williamson 2022-08-30 18:36:56 UTC
awesome, sounds great. Thanks!

Comment 31 Fedora Update System 2022-08-31 17:39:25 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.