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.

Bug 1749865

Summary: virt-install should pick up the most generic tree when using `--install os`
Product: Red Hat Enterprise Linux 8 Reporter: Katerina Koukiou <kkoukiou>
Component: virt-managerAssignee: Fabiano Fidêncio <fidencio>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.1CC: fidencio, jsuchane, juzhou, mzhan, tzheng, xiaodwan
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-manager-2.2.1-3.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 16:00:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1780529    
Bug Blocks:    
Attachments:
Description Flags
screenshot-1 for URL customize none

Description Katerina Koukiou 2019-09-06 15:44:26 UTC 
Description of problem:

When creating a guest with `virt-install --install os=fedora-29` the Workstation tree will be used.
Instead I would expect that the most generic tree will be used which in this case it's the Everything tree, and the user can select if they want Workstation or Server right after.

Version-Release number of selected component (if applicable):
2.2.1

How reproducible:
Always

Steps to Reproduce:
1. virt-install --name fedora-29 --install os=fedora-29

Actual results:
$ virt-install --name fedora-29 --install os=fedora29
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Workstation/x86_64/os
...

Expected results:
https://download.fedoraproject.org/pub/fedora/linux/releases/29/Everything/x86_64/os
should be used instead.
Comment 1 zhoujunqin 2019-09-09 07:10:41 UTC 
I can reproduce with:
virt-manager-2.2.1-2.el8.noarch
virt-install-2.2.1-2.el8.noarch

Steps:
$ virt-install --name fedora-29 --install os=fedora29
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Workstation/x86_64/os
Using fedora29 default --memory 2048
Using fedora29 default --disk size=20

Starting install...
...

Result: The Workstation tree is used.

A workaround: We can customize the install tree during installation, see screenshot-1, thanks
Comment 2 zhoujunqin 2019-09-09 07:11:19 UTC 
Created attachment 1613018 [details]
screenshot-1 for URL customize
Comment 3 Fabiano Fidêncio 2019-09-09 07:45:08 UTC 
We have PR opened for this issue: https://github.com/virt-manager/virt-manager/pull/51
Comment 4 Fabiano Fidêncio 2019-09-11 21:12:02 UTC 
master:
  0f1acc9f8f392eaf5edd30
  d6d97c658771f75d2a1fdf
Comment 6 zhoujunqin 2019-12-06 09:33:57 UTC 
I can reproduce with package:
virt-install-2.2.1-2.el8.noarch
virt-manager-2.2.1-2.el8.noarch

Details please see Comment 1.

Then try to verify with new build:
virt-manager-2.2.1-3.el8.noarch
virt-install-2.2.1-3.el8.noarch
libvirt-4.5.0-36.module+el8.2.0+4817+92ef2d83.x86_64
osinfo-db-20190611-1.el8.noarch
osinfo-db-tools-1.5.0-4.el8.x86_64

Steps:
Scenario-1: Install a fedora29 os with default profile.

# virt-install --name fedora-29-unattend --install os=fedora29 --unattend 
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os
Using fedora29 default --memory 2048
Using fedora29 default --disk size=20

Starting install...
WARNING  Using unattended profile 'desktop'
...

Result: The "Server" tree is used: https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os

Scenario-2: Install a fedora29 os with 'jeos' profile.

# # virt-install --name fedora-29-jeos --install os=fedora29 --unattend profile=jeos,admin-password-file=/tmp/admin-password-file,user-password-file=/tmp/user-password-file
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os
Using fedora29 default --memory 2048
Using fedora29 default --disk size=20

Starting install...
...

Result: The "Server" tree is used, it's as expected.

Scenario-3: Install a fedora29 os with 'desktop' profile.

# virt-install --name fedora-29-desktop --install os=fedora29 --unattend profile=desktop
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Workstation/x86_64/os
Using fedora29 default --memory 2048
Using fedora29 default --disk size=20

Starting install...
...

Result: The "Workstation" tree is used, it's as expected.




@Fabiano Fidêncio, Please help me have a look of result for Scenario-1.

If I don't set value for "profile", virt-install will default to 'desktop' from manual page.

# man virt-install
           profile=
               Choose which libosinfo unattended profile to use. Most distros have a 'desktop' and a 'jeos' profile. virt-install will default to 'desktop' if this is unspecified.

It conflicts with the code or the content should be updated.

# vim /usr/share/virt-manager/virtinst/osdict.py

595     def _get_generic_location(self, treelist, arch, profile):
596         if not hasattr(Libosinfo.Tree, "get_os_variants"):
597             for tree in treelist:
...
607         elif not profile:
608             profile = "Everything"

And there is no 'Everything' related URL in file:/usr/share/osinfo/os/fedoraproject.org/fedora-29.xml
How about I file a bug against "osinfo-db" to request, thanks.
Comment 7 Fabiano Fidêncio 2019-12-06 09:58:55 UTC 
(In reply to zhoujunqin from comment #6)
> I can reproduce with package:
> virt-install-2.2.1-2.el8.noarch
> virt-manager-2.2.1-2.el8.noarch
> 
> Details please see Comment 1.
> 
> Then try to verify with new build:
> virt-manager-2.2.1-3.el8.noarch
> virt-install-2.2.1-3.el8.noarch
> libvirt-4.5.0-36.module+el8.2.0+4817+92ef2d83.x86_64
> osinfo-db-20190611-1.el8.noarch
> osinfo-db-tools-1.5.0-4.el8.x86_64
> 
> Steps:
> Scenario-1: Install a fedora29 os with default profile.
> 
> # virt-install --name fedora-29-unattend --install os=fedora29 --unattend 
> Using fedora29 --location
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/
> x86_64/os
> Using fedora29 default --memory 2048
> Using fedora29 default --disk size=20
> 
> Starting install...
> WARNING  Using unattended profile 'desktop'

Yes, this is wrong. And it should be solved on osinfo-db, by adding the needed information there.

> ...
> 
> Result: The "Server" tree is used:
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/
> x86_64/os
> 
> Scenario-2: Install a fedora29 os with 'jeos' profile.
> 
> # # virt-install --name fedora-29-jeos --install os=fedora29 --unattend
> profile=jeos,admin-password-file=/tmp/admin-password-file,user-password-
> file=/tmp/user-password-file
> Using fedora29 --location
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/
> x86_64/os
> Using fedora29 default --memory 2048
> Using fedora29 default --disk size=20
> 
> Starting install...
> ...
> 
> Result: The "Server" tree is used, it's as expected.

This is right!

> 
> Scenario-3: Install a fedora29 os with 'desktop' profile.
> 
> # virt-install --name fedora-29-desktop --install os=fedora29 --unattend
> profile=desktop
> Using fedora29 --location
> https://download.fedoraproject.org/pub/fedora/linux/releases/29/Workstation/
> x86_64/os
> Using fedora29 default --memory 2048
> Using fedora29 default --disk size=20
> 
> Starting install...
> ...
> 
> Result: The "Workstation" tree is used, it's as expected.
> 

This is also right!

> 
> 
> 
> @Fabiano Fidêncio, Please help me have a look of result for Scenario-1.
> 
> If I don't set value for "profile", virt-install will default to 'desktop'
> from manual page.
> 
> # man virt-install
>            profile=
>                Choose which libosinfo unattended profile to use. Most
> distros have a 'desktop' and a 'jeos' profile. virt-install will default to
> 'desktop' if this is unspecified.
> 
> It conflicts with the code or the content should be updated.
> 
> # vim /usr/share/virt-manager/virtinst/osdict.py
> 
> 595     def _get_generic_location(self, treelist, arch, profile):
> 596         if not hasattr(Libosinfo.Tree, "get_os_variants"):
> 597             for tree in treelist:
> ...
> 607         elif not profile:
> 608             profile = "Everything"
> 
> And there is no 'Everything' related URL in
> file:/usr/share/osinfo/os/fedoraproject.org/fedora-29.xml
> How about I file a bug against "osinfo-db" to request, thanks.

So, it does not conflict as:
- Everything has the suitable packages for doing a Workstation installation;
- Fedora decided to not provide Workstation trees anymore, resulting on apps having to use th "Everything" one.

As mentioned above and suggested by you. we should have an up-to-date osinfo-db there.

I've created a bug asking for osinfo-db rebase (https://bugzilla.redhat.com/show_bug.cgi?id=1780529) and my plan is:
- Do a build right now with the new osinfo-db;
- Do another build, by the last possible moment, updating osinfo-db again in order to ensure we have the most relevant updates there;

Does this sound reasonable?

Thanks a lot for bringing this up.
Comment 8 zhoujunqin 2019-12-06 10:48:08 UTC 
Hi Fabiano Fidêncio,
Your answer is very clear for me, I agree.

> - Do a build right now with the new osinfo-db;

I can use it to verify this bug.

> - Do another build, by the last possible moment, updating osinfo-db again in order to ensure we have the most relevant updates there;

Yes, we can also use this version when we do regression testing, thanks.
Comment 9 zhoujunqin 2019-12-13 03:34:36 UTC 
Verify with latest osinfo-db version again:
virt-manager-2.2.1-3.el8.noarch
virt-install-2.2.1-3.el8.noarch
osinfo-db-20191125-1.el8.noarch

Steps:
Scenario-1: Install a fedora29 os with default profile.

# virt-install --name fedora-29-unattend --install os=fedora29 --unattend 
Using fedora29 --location https://download.fedoraproject.org/pub/fedora/linux/releases/29/Everything/x86_64/os
Using fedora29 default --memory 2048
Using fedora29 default --disk size=20

Starting install...
WARNING  Using unattended profile 'desktop'
Retrieving file vmlinuz...                                  | 8.2 MB  00:02     
Retrieving file initrd.img...                               |  63 MB  00:18     
Allocating 'fedora-29-unattend.qcow2'                       |  20 GB  00:00     
Gtk-Message: 11:30:48.124: Failed to load module "pk-gtk-module"
Gtk-Message: 11:30:48.130: Failed to load module "pk-gtk-module"

Result: The "Everything" tree is used, and it uses unattended profile 'desktop'" by default, it's as expected.

And another two scenarios are PASS in Comment 6.

So I move this bug from ON_QA to VERIFIED.
Comment 11 errata-xmlrpc 2020-04-28 16:00:39 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1697