The os detection is done by libosinfo. I believe that this would need to be fixed in osinfo-db.

for reference, see the upstream issue https://gitlab.com/libosinfo/osinfo-db/-/issues/87

> I believe that this would need to be fixed in osinfo-db.

The suggested fix is to use APIs introduced in v1.10.0 [0] to workaround the fact we can't guarantee that uniqueness response on ISO metadata alone.

[0] https://gitlab.com/libosinfo/libosinfo/-/merge_requests/128

> for reference, see the upstream issue https://gitlab.com/libosinfo/osinfo-db/-/issues/87

I just closed this one.

Jonathon, I think virt-install will need to work with this new APIs. It should probably fail instead of detecting the wrong OS version.

virt-install will need newer libosinfo than what we have in RHEL at the moment so I'm adding depends on the rebase bug.

Hi Victor, it doesn't seem like that will totally solve the issue. On my Fedora laptop for instance:

$ rpm -qa |grep osinfo
osinfo-db-tools-1.10.0-1.fc36.x86_64
libosinfo-1.10.0-1.fc36.x86_64
libosinfo-devel-1.10.0-1.fc36.x86_64
osinfo-db-20221018-1.fc36.noarch

$ osinfo-detect -a ~/work/iso/en-us_windows_server_2022_x64_dvd_620d7eac.iso 
Media is bootable.
#1: Media is an installer for OS 'Microsoft Windows Server 2016 (x86_64)'

$ osinfo-detect -a ~/work/iso/en-us_windows_server_2022_updated_oct_2022_x64_dvd_c5b651c9.iso 
Media is bootable.

If `osinfo-detect -a` doesn't report windows server 2022 for these isos, doesn't that indicate an issue in osinfo-db?

Hi Jonathon,

> If `osinfo-detect -a` doesn't report windows server 2022 for these isos, doesn't that indicate an issue in osinfo-db?

That's correct. Seems to be an issue in libosinfo where the internals of the API is not considering `derives-from`.
In this case, windows server 2022 derives from windows server 2019, which derives from windows server 2016 and only the last one is being reported back.

I'm working on a fix for libosinfo for that now, I'll update you here when is posted.

Thanks Victor,

I guess I'll leave this bug under virt-manager since I'll probably need to modify the libosinfo API usage. Should we also clone this bug to osinfo-db?

(In reply to Victor Toso from comment #4)
> That's correct. Seems to be an issue in libosinfo where the internals of the
> API is not considering `derives-from`.

`Derives-from` is not for osinfo media types... I've posted a patch updating osinfo-db.
https://gitlab.com/libosinfo/osinfo-db/-/merge_requests/529

(In reply to Jonathon Jongsma from comment #5)
> Should we also clone this bug to osinfo-db?

The fix will be covered by rebase bug 2135751 but this issue might be interesting to be included in the osinfo-db errata, so I'll clone it.
Thanks!

> I'm working on a fix for libosinfo for that now, I'll update you here when is posted.

libosinfo rebase is done: bug 2135755
osinfo-db rebase is done: bug 2135751

If one finds an Windows ISO that is not recognized, feel free to ping me or open a bug.
Cheers,

FYI, I did submit a patch upstream, but the proper approach is still under discussion: https://github.com/virt-manager/virt-manager/pull/465

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.