Now we want to test Rawhide, 14 days is a bit too long. After
13 days, Rawhide updates are absolutely piling up, and it can
cause the `dnf update` run at the start of update tests to time
out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
After looking at the openQA side, I think I prefer this way of
doing things overall. If we use 'rawhide' in the filenames, we
have to use 'Rawhide' as the VERSION on openQA side, and that
involves quite a lot of surgery. If we can use the release number
as the VERSION on openQA side for Rawhide updates, that seems to
work better, and tie in better with Bodhi.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't need the release version conditional any more as we're
well past F31. Also this way it'll work for Rawhide.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should fix the desktop_fprint test when running on upgrade
(not fresh install). No idea how the test ever worked, but I
think this is why it's been broken since January.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This more closely matches our usual installs, and fixes a problem
in the (under-review) GNOME Software tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Not sure why, but it's the plymouth theme that's breaking update
tests on ppc64le; if it's installed, typing into the VT after
boot doesn't change the screen. Removing the plymouth theme from
the base image fixes the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
upgrade_minimal_64bit for Rawhide needs it. Honestly I don't
remember the logic behind all these values any more, just hitting
this with a stick.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
They're qcow2 images, so this is more correct, and will make
os-autoinst's new backing format autodetection work correctly.
We make the `check` function rename existing images, for
convenience.
NOTE: this requires a matching change to the templates in
os-autoinst, and you will want to run the check function to
rename all existing images to avoid wasting a ton of time
recreating them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems like 2G isn't enough in some cases, it's why the F34 server
and support image builds have been failing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We want to run the desktop upgrade tests on aarch64; to do that,
we need the required base images to be built. We also need to
do the `console=tty0 quiet` boot args for the desktopencrypt
image so the decrypt prompt is visible on boot; to handle this,
we extend the existing hack for using a release-specific ks
to be more generic and allow for a more specific kickstart by
arch, release or both.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bit ugly but offhand can't think of a better way. We
are dropping plasma-workspace-wayland from the F33 KDE image to
try and avoid it using Plasma-on-Wayland as the default session,
which is #1960458.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The bug where the bootsplash doesn't always clear is really
playing havoc with F34 tests right now, and dealing with it by
workaround needles isn't going so well. I'm hoping installing a
real Plymouth theme might help, and in a quick trial run on lab
it seems to, so let's try this. The bug is still a bug, but it's
no good to us for update tests to randomly fail on it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
"current" is just a synonym for "-1" but made the code more
complex. Let's ditch it and just note in a comment that -1 is
CURRREL and -2 is PREVREL. We need minimal-uefi for aarch64 as
install_blivet_btrfs_preserve_home_uefi uses it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds the post-installation section that adds a file
in the /home space, which then can be checked by a `preserve_home`
post-installation test and prove that it was possible to
preserve home on btrfs layouts.
This reverts commit 8f53b9f5f8.
similar revert already done since a while in os-autoinst-distri-fedora
"e020b87 Drop the pseries-4.0 workaround for ppc64le"
This is for
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/201 -
we're working around that by using the F32 image for now, but it
doesn't exist on aarch64 ATM. We'll have to remember to take
this out when that's fixed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Add a workaround repo to kde.ks to get the kde-settings that
will put F33 backgrounds in F33 images (hopefully). Remove an old
workaround repo from the desktop kickstarts that isn't needed
any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is causing us pain in the tests, so let's work around it
now rather than wait for the updates to go stable. Can remove
these once the updates are stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2.0.0 went stable in F31, but it's kinda messed up, it provides
kde-settings, and when building this image, anaconda actually
prefers it over the 'real' kde-settings, which breaks the desktop
background among other things. 3.0.0 should fix it but it's still
in updates-testing, so let's forcibly exclude it for now.
We bumped it for the live image build update test, but I tweaked
that to use a separate scratch disk now, so the base image no
longer needs to be so big.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need this for upgrade tests now I fixed the upgrade test
scheduling so Rawhide upgrade tests run from Rawhide-1 and
Rawhide-2, not currrel and prevrel...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Some of the version config directives make it possible to wind
up with dupes - for instance, our config for the 'minimal' image
can result in multiple instances of VirtInstallImage for F31
appearing in the list, meaning we'll build the same image two
or more times in the same run. That's silly! Let's not do that.
Using a dict keyed on the release number and arch we wind up with
after interpreting the config file should avoid it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
