Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
+++ This bug was initially created as a clone of Bug #1970881 +++
Description of problem:
One of ours rhel-8 virt-install tests fails on rhel-9 when rhel-9 boot.iso is given to the --location argument
Simply using following command ends in a validation error
virt-install --location /var/lib/libvirt/images/boot.iso
ERROR Error validating install location: Could not find an installable distribution at URL '/var/lib/libvirt/images/boot.iso'
The location must be the root directory of an install tree.
See virt-install man page for various distro examples.
When tried with rhel-8 boot.iso it works
virt-install --location /var/lib/libvirt/images/RHEL-8.5.0-20210611.n.0-BaseOS-x86_64-boot.iso
Using default --name rhel8
Using rhel8-unknown default --memory 1536
Using rhel8-unknown default --disk size=20
WARNING Graphics requested but DISPLAY is not set. Not running virt-viewer.
WARNING No console to launch for the guest, defaulting to --wait -1
Starting install...
When the rhel-9 is given to the --cdrom argument it all works fine, but --extra-args can't be used then.
According to the manpage isoinfo is used to probe the iso, and isoinfo seems to work fine.
[root@kvm-04-guest06 images]# isoinfo -p -i /var/lib/libvirt/images/boot.iso
Path table starts at block 28, size 94
1: 1 14
2: 1 16 EFI
3: 1 19 IMAGES
4: 1 1b ISOLINUX
5: 2 17 BOOT
6: 3 1a PXEBOOT
7: 5 18 FONTS
[root@kvm-04-guest06 images]# isoinfo -p -i /var/lib/libvirt/images/RHEL-8.5.0-20210611.n.0-BaseOS-x86_64-boot.iso
Path table starts at block 21, size 94
1: 1 1d
2: 1 21 EFI
3: 1 1e IMAGES
4: 1 20 ISOLINUX
5: 2 22 BOOT
6: 3 1f PXEBOOT
7: 5 23 FONTS
I am not sure whether this is expected or whether the issue lies in virt-install / the boot.iso itself
Version-Release number of selected component (if applicable):
RHEL-9.0.0-20210610.2 < system used as well as boot.iso
virt-manager-3.2.0-4
How reproducible:
I tried it on 3 different systems with same result
Steps to Reproduce:
1. virt-install --location /path/to/rhel9/boot.iso
Actual results:
Could not find an installable distribution at URL '/path/to/rhel9/boot.iso'
Expected results:
--location is useable with rhel-9 iso
--- Additional comment from Andrea Bolognani on 2021-06-14 17:14:35 UTC ---
This seems to work fine on my Fedora 34 machine with
virt-install-3.2.0-3.fc34.noarch
osinfo-db-20210531-1.fc34.noarch
using
RHEL-9.0.0-20210613.d.4-x86_64-dvd1.iso
as the installation media.
@fidencio is it possible that the reporter is missing
https://gitlab.com/libosinfo/osinfo-db/-/commit/fc9fadf2400da2970fff8b317eebc73c9e9a1782
or some other similar commit? AFAICT the compose they're using has
osinfo-db-20210312-2.el9.noarch
which should be new enough, but perhaps I'm missing something?
--- Additional comment from Fabiano Fidêncio on 2021-06-14 19:02:27 UTC ---
I'd be interested to know:
* A link to the problematic ISO
* The ouput of `isoinfo -d -i /path/to/iso`
Best Regards,
--- Additional comment from Petr Zatko on 2021-06-15 05:29:33 UTC ---
Fabiano,
The problematic iso is http://download.eng.bos.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.0.0-20210610.2/compose/BaseOS/x86_64/iso/RHEL-9.0.0-20210610.2-BaseOS-x86_64-boot.iso
[root@kvm-08-guest38 test]# isoinfo -d -i ./RHEL-9.0.0-20210610.2-BaseOS-x86_64-boot.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: RHEL-9-0-0-BaseOS-x86_64
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.5.4 2021.01.30.150001, LIBISOBURN-1.5.4, LIBISOFS-1.5.4, LIBBURN-1.5.4
Application id:
Copyright File id:
Abstract File id:
Bibliographic File id:
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 360344
El Torito VD version 1 found, boot catalog is in sector 40
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 1648 5704
I tried the RHEL-9.0.0-20210613.d.4-x86_64-dvd1.iso mentioned in comment 1 and it works fine.
And the compose indeed has osinfo-db-20210312-2.el9.noarch
--- Additional comment from Fabiano Fidêncio on 2021-06-15 06:18:19 UTC ---
Okay, the problem is clear now.
The problematic ISO
```
[root@kvm-08-guest38 test]# isoinfo -d -i ./RHEL-9.0.0-20210610.2-BaseOS-x86_64-boot.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: RHEL-9-0-0-BaseOS-x86_64
Volume set id:
Publisher id:
```
A good ISO:
```
fidencio@quino /tmp $ isoinfo -d -i RHEL-9.0.0-20210610.2-x86_64-dvd1.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: RHEL-9-0-0-BaseOS-x86_64
Volume set id:
Publisher id:
```
And this is what osinfo-db expects, from https://gitlab.com/libosinfo/osinfo-db/-/blob/master/data/os/redhat.com/rhel-9.0.xml.in#L48-51:
```
<iso>
<system-id>LINUX</system-id>
<volume-id>RHEL-9-0-(([0-9]|[1-9][0-9])-)?BaseOS-x86_64</volume-id>
</iso>
```
The fact they dropped the LINUX from the system-id is a regression that should be treated by the team that takes care of generating those ISOs.
We can clearly see that for 8.5 ISOs it's still present:\
```
fidencio@quino /tmp $ isoinfo -d -i RHEL-8.5.0-20210609.n.3-BaseOS-x86_64-boot.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: RHEL-8-5-0-BaseOS-x86_64
Volume set id:
Publisher id:
```
We can, of course, work this around on osinfo-db. But I'd take the osinfo-db change as a change to work the regression around, not as the proper fix. The proper fix should come from the team generating those images and we better talk to them, while I'll prepare an osinfo-db patch.
--- Additional comment from Fabiano Fidêncio on 2021-06-15 06:32:31 UTC ---
And here we have the proposed upstream patch for osinfo-db: https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/316
Without the patch:
fidencio@quino ~/src/upstream/osinfo-db $ osinfo-detect http://download.eng.bos.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.0.0-20210610.2/compose/BaseOS/x86_64/iso/RHEL-9.0.0-20210610.2-BaseOS-x86_64-boot.iso
Media is bootable.
With the patch:
fidencio@quino ~/src/upstream/osinfo-db $ osinfo-detect http://download.eng.bos.redhat.com/rhel-9/composes/RHEL-9/RHEL-9.0.0-20210610.2/compose/BaseOS/x86_64/iso/RHEL-9.0.0-20210610.2-BaseOS-x86_64-boot.iso
Media is bootable.
Media is an installer for OS 'Red Hat Enterprise Linux 9.0 (x86_64)'
--- Additional comment from Fabiano Fidêncio on 2021-06-15 06:35:13 UTC ---
Petr, I've moved this on to osinfo-db and I have assigned it to myself.
I'd really ask your help so we can have it cloned to the right component, to the team that's responsible for generating the ISOs.
Best Regards,
AFAICT, the metadata information change is a side effect of using different tools for building the ISOs.
The metadata shows the main DVD iso is created by genisoimage
$ isoinfo -d -i RHEL-9.0.0-20210614.6-x86_64-dvd1.iso
CD-ROM is in ISO 9660 format
System id: LINUX
Volume id: RHEL-9-0-0-BaseOS-x86_64
Volume set id:
Publisher id:
Data preparer id:
Application id: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
While the boot iso is created by xorriso
$ isoinfo -d -i RHEL-9.0.0-20210614.6-BaseOS-x86_64-boot.iso
CD-ROM is in ISO 9660 format
System id:
Volume id: RHEL-9-0-0-BaseOS-x86_64
Volume set id:
Publisher id:
Data preparer id: XORRISO-1.5.4 2021.01.30.150001, LIBISOBURN-1.5.4, LIBISOFS-1.5.4, LIBBURN-1.5.4
It appears that 'genisoimage' will default to writing the 'System id: LINUX' while 'xorriso' does not do this.
I don't have a particular opinion on whether having 'System id: LINUX' is good or not, but I think we ought to be consistent across the ISOs generated. ie use xorriso for all or use genisoimage for all, not a mixture like we see today
*** Bug 2019387 has been marked as a duplicate of this bug. ***
Comment 10RHEL Program Management
2022-12-15 07:30:46 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 11Red Hat Bugzilla
2023-09-18 00:27:35 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days