IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since there's a release pending, this is a bit of future proofing
if win11 pops up in a future osinfo-db without accompanying
libosinfo firmware APIs landing
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Check it for test:/// URI too
* Move the whole logic into osdict.requires_firmware_efi
* Wrap it all in an exception handler the final API breaks us
* Add some coverage exclusions since this is currently untestable
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Windows 11 only supports EFI for installation, legacy BIOS is
discontinued as an option for new installs, unless you switch into
the console and run various regedit hacks in the installer.
This is not something we expect users to do, so osinfo-db will
report:
<firmware arch="x86_64" type="efi"/>
<firmware arch="x86_64" type="bios" supported="false"/>
for Windows 11.
When seeing 'bios' with supported=false, we need to prefer EFI
firmware no matter what.
For other OS we should stil prefer BIOS, because EFI blocks the usage of
internal qcow2 snapshots until some libvirt work is done to use the new
QMP snapshot commands.
Note this relies on a new API osinfo_os_get_complete_firmware_list
just added to libosinfo in version 1.10, so for most existing OS
distros this will be dormant functionality until they rebase to
latest libosinfo APIs.
The Windows 11 entry for osinfo-db will be the first that exposes
the metadata indicating lack of BIOS support.
Related: https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically over time it's been more likely that an issue is reported
for osinfo-db missing the usb-tablet annotation. So for example we
always enable it for the default 'generic' case. We also want to
enable it for osinfo's 'unknown' case too.
Rather than add another check for that, let's just drop the osinfo
checking entirely. Some very old OS don't support usb-tablet, but
specifying it for those cases doesn't cause issues AFAIK, and users
can override it with `--input none` if they want.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We are about to change the some defaults around os handling. Let's
start recommending the nicer named --osinfo more, since new error
messages are going to promote it a bit as well
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Have the UI push users more towards better defaults, by discouraging
the 'generic' entry and offering the 'linuxXXXX' entries when their
distro or OS version is not in the list.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Previously we tried to use a combination of distro class and version
number to produce a correct ordering that was independent of the
osinfo short ID. The original intent was to have correct ordering
for Windows entries in the virt-manager UI, since the short ID
values are all over the place.
Nowadays that doesn't really matter, since we weed out old
unsupported entries by default. And in the mean time, our current
sort method gives some weird results like interspersing silverblue
entries with fedora entries.
Using a natural/human sort is simpler and handles things pretty well.
Change the UI to sort by the OS label too which preserves some of
the good behavior of original method
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The canonical tool for this is `osinfo-query os`, which we still
reference in the man pages and in the list output.
However, we are about to make missing --os-variant fatal for common
usage, and I don't want to force users to install an extra tool just
to figure out what an acceptable --os-variant value is.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is from Gerd's suggestions here:
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
When the guest supports it, we should use virtio. qxl is on the way
out, and the benefits are marginal and add a security and maintenance
burden.
While here, check domcaps that qxl or virtio are actually available.
Modern qemu has device modules, so device support may not be installed.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Accidentally changed in
commit 302ef1f096
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Fri Nov 26 18:51:49 2021 +0000
virtinst/osdict: add a property for the OsinfoDb object
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we've removed all internal aliases, there is no longer any
reason to keep a cache of OS objects internally. We can directly
query the DB when we need it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Introduce a property for accessing the generic fallback Os object, which
will be useful in future refactoring.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The code comment suggests removing the aliases after a year. It has
now been three years, so it is time for them to go.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This would still be used for old osinfo (mid 2019), and only for
the case of installing 7+ year old RH distros. I think we can safely
delete it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Each OS may specify which kernel argument is needed to specify the
installation source; use it as primary source, falling back to the
current logic. This should help supporting new OSes OOTB.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
It's not impossible osinfo-db adds a 'generic' OS of its own, in
which case we will start misbehaving. Rework the way we implement
our synthetic 'generic' OS internally, using a stub Libosinfo.Os()
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit d52d9885c8 added a logic to
consider as EOL a distribution with no EOL date set and release date
earlier than 5 years from the current day. This was done because there
were (and still are, even if fewer now) many old OSes in osinfo-db with
no EOL date set, which were thus considered "supported". Sadly, OSes
that are still supported, like Windows 10, Windows Server 2012, or
earlier versions of RHEL/CentOS/OL 6/7, are now considered "EOL".
As a hack on top of the initial hack, extend the range from 5 years to
10 years: this will consider some of the aforementioned OSes as
supported, without adding too many other OSes.
Of course the long term solution is to make sure all the OSes in
osinfo-db that are EOL upstream have a EOL date set, so there is no more
need to arbitrary exclusion logic.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
-1 returned from osdict resource lookup means the value is unspecified.
When we encounter that value we should also check the 'all' arch
category, instead of stop processing.
This fixes some vcpus calculation for --os-variant rhel7.0 with
latest osdict
Signed-off-by: Cole Robinson <crobinso@redhat.com>
osinfo library doesn't return data for these with the fedora 32
version, so it's hard to get coverage testing. Since we aren't
even using this code yet anyways, let's remove it until it is needed
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Change the label for a generic OS to "Generic OS", and making it
translatable.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Similarly to what has been done for _device_filter(), let's add
"extra_args" parameter to support_* methods so we can pass them down to
_device_filter().
Only supports_virtio* methos would actually need the extra argument, but
let's be consistent here and add it to all supports_* methods.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add "extra_devs" to _device_filter() so we can pass a list of
devices which can be used by an OS but are not part of the distro / OS
itself.
By doing this, we also expand the _device_filter() check and take those
into account when they're passed.
That's exactly the case of pre-installable drivers for Microsoft
Windows.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a new method to get the devices which are supported when
taking advantage of a pre / post installable drivers.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
The post-installable drivers provided by osinfo-db are merely agents,
which are not a blocker for an installation to succeed using virtio &
having a bootable guest.
Let's add this method as a counter part of supports_unattended_drivers()
and use it in the future, when we re-work the installation code of
virt-install and are able to perform installations of MSIs.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
supported_unattended_drivers() was originally added as a way to tell
whether a guest could support pre & post installable drivers.
This is wrong for two reasons:
- virt-install cannot deal with post-installable drivers/agents;
- pre-installable drivers are the only ones needed in order to perform
an unattended installation taking advantage of virtio-win drivers;
Knowing that, let's only check for pre-installable drivers in
supported_unattended_drivers().
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
As some OSes, as Fedora, have variants (which we rely to be standardised
on osinfo-db side), let's select the most appropriate variant according
to the selected profile of the unattended installation.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some OSes, as Fedora, have variants (which we rely to be standardised on
osinfo-db side), which we can use to return the most generic tree
possible, in case no profile is specified, in order to avoid failing to
install a "Workstation" system because a "Server" variant tree was used.
https://bugzilla.redhat.com/show_bug.cgi?id=1749865
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a method which tells us whether pre & post installable drivers
are supported when performing unattended installations.
This is going to help us in the future in order to force virtio-win
usage when unattended installing guests which support it.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add two new methods to get the pre & post installable drivers'
location, returning a list of URLs (strings).
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add two new *private* methods to get the pre & post installable
drivers, returning a list of OsinfoDeviceDrivers;
Those are going to be used later on this series in order to get the
drivers' locations.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Some osed have multiple short-ids, like debian10 also has debianbuster.
Use the API if it's available. This will make it easier to remove
our back compat aliases eventually
Let's use identify_tree(), which is part of libosinfo v1.6.0 release,
instead of using guess_os_from_tree().
The API has been implemented on libosinfo in order to be consistent with
what was already done for medias.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of returning an OsinfoTree, let's be consistent with what we
already do in guess_os_from_iso() and return our internal _OsTree
object.
This change doesn't affect any code as the only place using it doesn't
care about the returned tree object.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similarly to the _OsMedia() class, let's create a _OsTree() class which,
at least for now, has only one method that returns the OsinfoTree
object.
Although this class & method are not extrictly needed, having them makes
the code more consistent.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add a way to get the OsinfoMedia from the _OsMedia class. It's
going to be needed in order to properly generate the command line for
the unattended installations, when doing an installation from a media.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
