Hopefully https://bugzilla.redhat.com/show_bug.cgi?id=2133829
is fully resolved/worked around by now, and we shouldn't need
these any more. We could drop back to 2G but let's just do
3G for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was from F35 era when Cloud_Base worked on UEFI on Rawhide
but not F33 or F34. Now F34 is EOL, we can just follow the same
policy for every release (run two tests on both BIOS and UEFI,
the rest only on UEFI).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is getting messy, but even the install_default_upload test
is failing out with 3G now. Let's try putting 4G here so it
reaches that test and see how that goes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We keep running into 2119970 and it's really a pain restarting
tests manually all the time. So let's just retry the affected
tests three times. Big hammer time!
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Looking through more openQA failures I saw other desktop update
tests which were clearly caused by OOM kills, so let's give all
the desktop tests we run on updates 4G for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're seeing a lot of failures recently in desktop_browser caused
by the browser or desktop getting OOM killed. I've filed a bug
on this: https://bugzilla.redhat.com/show_bug.cgi?id=2133829
but we need to try and work around it, having the test failing
constantly is no good. Let's see if 4G of RAM is enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We see tests periodically come up incomplete with this:
"Migrate to file failed, it has been running for more than 240 seconds"
Turns out there's a setting for this, so...let's set it. I don't
think there's really a bug here, just when our workers are busy,
these migrations can take longer than expected.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Workstation tests on Rawhide are getting OOM killed. Let's see
if this helps. All the other arches have this much already, and
the worker hosts can handle it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We have it at 20G for Workstation live, but not for KDE live or
for the update Workstation or KDE products. We just hit an issue
today where anaconda thinks 10G isn't enough space for a KDE
live install after a grub2 update (which I think only bumped
the required space veeery slightly, but enough to throw anaconda
over the limit). Let's just go up to 15G for all GNOME and KDE
cases where we're not at 20G.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
OK, so we can't have parallel tests on different machines, so
we can't have iot_zezere_server on 64bit and iot_zezere_ignition
on uefi. We need both to be on uefi. So, let's try using the
minimal-uefi image that we build for upgrade tests instead. It's
built for -1 (which is the same as CURRREL) on x86_64 and aarch64
so it should be there when we need it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It boots the 'support' disk image, not the image created by
install_default_upload, and that disk image is only set up for
BIOS boot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's best to keep the test name consistent unless we *really*
have to change it; that way the "past runs" history in openQA
still works and the name doesn't change in resultsdb and CI
messages.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The PR introduces an improved logic to the desktop_printing.pm
that allows to use the USE_CUPS variable in templates to trigger
the installation of cups-pdf prior to the actual test.
The cups-pdf is then used as an alternative PDF printer
instead the built-in Save As PDF method.
Workstation has replaced gedit with gnome-text-editor in Rawhide,
so this is no longer useful. We will replace it with a test suite
for gnome-text-editor.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
With qxl it hits a weird bug where running startx a second time
after snapshot restore tends to crash. This is affecting updates
so let's force it to virtio. Hopefully the kernel build with
virtio fix will succeed so I can just revert all this messing
around soon.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's totally broken in Rawhide, so let's use qxl or another
fallback temporarily. Hopefully not too many other bugs show up
with this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We dropped memtest from the images. We may replace it with
something better at some point, but until that day, let's drop
this test so it's not uselessly failing all the time.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're changing these to be named `foo.qcow2` not `foo.img` due
to a change in qemu and os-autoinst to do with backing file
format detection.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As suggested by @kparal, this adds a test that specifies an
additional repository using a metalink. The repository contains
a single package, 'testpackage', that supplements glibc (so it
should always get installed). The test runs an install then
checks that testpackage got installed.
We also deduplicate a pair of needles which were matching on the
same anaconda UI feature (an "add" button) and use that same
needle in this test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test for fingerprint-based login, as requested by
@benzea in #223. We use the fprintd dummy device to let us
simulate scanning a fingerprint, and check various scenarios
recommended by @benzea.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR fixes issue #188. It adds a test suite to test basic
functionality of Evince and brings the following features:
* test scripts for various Evince functions.
* needles to support the Evince test scripts
* new template variables `TESTPATH` and `POSTINSTALL_LOAD_ALL` (see
below)
* new logic in `main.py` (see below)
The new variables and the new logic make it easier to create test
suites for post-installation tests. If TESTPATH is used, OpenQA
will take all tests mentioned in POSTINSTALL from that specified
TESTPATH. If both TESTPATH and POSTINSTALL_LOAD_ALL are used, then
OpenQA will run all tests it can find at the TESTPATH location.
If POSTINSTALL and POSTINSTALL_LOAD_ALL are set simultaneously,
then only POSTINSTALL will be taken into account and OpenQA will
only load tests mentioned there.
Cloud images are now BIOS/UEFI hybrid in Rawhide (but not F33
or F34), so we want to run the Cloud tests on UEFI as well, but
only on Rawhide.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds a new test that automates the above mentioned test case.
It starts the installation in text mode using the `install_text` test
case, which it interrupts using the Anaconda crash trigger.
When the crash happens, it goes through the process of reporting
the bug to Bugzilla, checks that Bugzilla sends a positive
confirmation of the action, but also performs some REST API
calls to do a proper check and then it closes the bug to clean up.
This PR automates the mentioned testcase to test that Help can be
displayed in Anaconda during the installation. It navigates through
the available Help screens and if it can see it, it finishes.
This test runs after `install_default_upload` to override the
installation defaults defined for all primary tests.
Delete a duplicated needle.
Reformat list extensions to make it nicer.
Get rid of wrong export and an empty line.
Delete empty line.
Use _boot_to_anaconda for booting and move subroutine accordingly.
Add variable to templates.fif.json
Delete trailing whitespace.
Fix calling the pretest.
Move help checking to another place.
For Cloud, we want to run these tests directly on the disk image
from the compose. But for other flavors, they are run on a disk
image produced by install_default_upload, so the test suites
specify HDD_1. This causes a problem as the value from the test
suite is used as the filename when downloading the image, but
that file name does not change between composes, so instead of
downloading the image to be tested for each compose, we just
wound up downloading it one time and then re-using that same
file every day.
Solving this is a bit tricky for reasons explained in the
fedora_openqa commit, but this is the best option I could think
of. The scheduler has been changed to schedule the downloaded
image as HDD_2_URL, not HDD_1_URL; so now in the templates we just
override the HDD_1 value for the Cloud flavors to "%HDD_2%",
meaning to take the value of HDD_2 (which will be parsed from
HDD_2_URL). We do not actually attach HDD_2 at all, it's only
used to be copied to HDD_1.
We also explicitly set DEPLOY_UPLOAD_TEST to "" for all flavors
(it was only set for one before), just for clarity.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test that just fails if any one of a given list of
unwanted packages is installed. This was a request for the
Workstation edition from @catanzaro so I've just implemented it
for Workstation so far, but it's designed to be easily extended
to cover other subvariants too if we want.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the same thing we did for install_resize_lvm, to address
issue #201. We just didn't get around to doing it for the blivet
test yet. We also change the HDDSIZEGB for the parent test to
15GB so the resizing stuff actually works in both resize tests;
ever since we changed this the install_resize_lvm test has not
been working properly, it hasn't actually been doing any resize.
Also drop the swap partition stuff from that test as it's for
sure no longer needed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds a test that uses the Blivet interface to create an LVM
layout with ext4 filesystem as well as a postinstall test that checks
that the LVM layout has been created correctly.
This PR introduces a test case that uses the Blivet partitioning
tool to create a standard partitioning layout with / and /boot
(and specific partitions for UEFI and ARM64) using ext4 as
the selected filesystem.
It also adds a postinstallation test to check that the partitions
have been created correctly.
KDE netinst installs more packages than before, now, so it needs
more space. After investigation this is not a bug, it is intended.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR uses the Anaconda Blivet partitioning to recreate a partition
layout while preserving the content of the /home subvolume.
It also adds the postinstall test to check that the home has been
preserved.
This PR adds the `install_btrfs_upload` to install the btrfs based
image, the `btrfs_preserve_home_extras` to prepare and test the data
on the home partition, as well as the `custom_btrfs_preserve_home` that
uses the preinstalled btrfs image and uses its current partitioning to
preserve the home partition and the data on it.
Using .local is apparently Bad Form because it's reserved for
mDNS. However there doesn't appear to be any particularly Good
Form for what to call a test domain you never want to exist
outside of a closed system, apparently. Sigh. Let's try this.
Includes a bump to disk_ks version because the kickstarts on
that image also need to have this change applied.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR add the installation test which uses Standard partitioning
with an ext4 filesystem to cover one of the new requirements as
described in issue #202.
Fixed after a review
When Fedora went to BTRFS as a default, we lost the LVM based image to
run LVM resize tests with.
This PR introduces the `install_lvm.pm` installation test that creates
an LVM based qcow2 image to be used by follow-up tests.
Per https://pagure.io/fedora-qa/issue/650 , we dropped these
from the wiki, and I agree with @kparal that it doesn't make much
sense to run them any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Setting HDD_1 to %HDD_2% is broken in recent openQA:
https://github.com/os-autoinst/openQA/pull/3309#issuecomment-721906935
I count this as a bug, but we can solve it like this, I think -
we don't actually need to set this test up so carefully to only
have the disk image as HDD_1 and no HDD_2, we can actually just
let the disk image be HDD_2 and have an empty disk as HDD_1 and
the test still works, qemu will boot from the second disk and we
can upload it and everything's fine. So let's just go with that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
These tests assume the desktop base disk image has an ext4-on-LVM
layout, but from F33 onwards it doesn't, it uses btrfs as that's
the new distro default.
We need a proper fix for this, but for now, just make the test
use the F32 disk image. This buys us six months at least.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We have variant versions of several of the base tests which exist
to account for differences in required variable settings to run
essentially the same test in different situations. By twiddling
the variables a little, including inventing a new variable
defined in the flavors and substituted into the test suites so
the same test suite can have a different START_AFTER_TEST when
run on different flavors, I think we can unite them all and make
this a lot simpler.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So, there's a problem with how we figure out the NetworkManager
connection to use in setup_tap_static: it expects the first
connection in the list to be the right one, but this is only
actually true so long as it's *active*. When we're in the tap
case, it's usually not going to actually *work* out of the box
on boot (or else we wouldn't need setup_tap_static at all...),
so some time after boot, NetworkManager gives up on it and marks
it as inactive. And after that, setup_tap_static won't work any
more.
I never noticed this as a problem before because usually we do
setup_tap_static before that point. But it seems in the vnc
client tests, on aarch64, desktop boot and login is slow enough
that by the time we switch to a VT and try to setup the network,
we're very close to that cutoff, and sometimes miss it.
This, I hope, avoids the problem by doing the network setup in
that test before we deal with the desktop login, then doing the
desktop login, then doing the actual VNC bits.
The alternative here would be to figure out a better way to do
setup_tap_static, but I can't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This sets us up to test the release-blocking aarch64 disk images
(Minimal, Server and Workstation). It also allows for testing
armhfp disk images on aarch64 worker hosts (though my testing of
that isn't going too well so far), and fixes the initial-setup
handling for a change upstream ('use password' is now the default
so we don't need to choose it). We rewire disk image deployment
test loading to work through the generic loader code rather than
using ENTRYPOINT, as it allows us to more gracefully handle
graphical (Workstation) vs. console (Server, Minimal), moving
the code for handling console initial-setup to a helper function
just like the code for gnome-initial-setup and having _console_
wait_login call it when appropriate. We also tweak desktop_vt a
bit because now we need to switch from a console running as test
to a desktop, which breaks the assumption that the highest
numbered session of user test is the desktop...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should work even if the ifcfg plugin is not present (hi,
CoreOS) or 'predictable' (har) network names are on.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In Fedora 33, we generally no longer include a disk-based swap
partition by default (instead swap-on-ZRAM is used, see
https://fedoraproject.org/wiki/Changes/SwapOnZRAM ). This tweaks
our tests to account for that. In tests that aren't to do with
swap at all, we stop including a swap partition in order to be
closer to the default layout. We replace the old _no_swap blivet
and custom tests with _with_swap tests that, as the name implies,
*explicitly include* a swap partition, and adjust the postinstall
test to check the disk swap partition is there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bit complex to automate, because we cannot really use
the production Zezere server (provision.fedoraproject.org) as
the test case shows, as we'd have to solve authentication and
we also don't really want to constantly keep registering new
hosts to it that are going to disappear and never be seen again.
So, instead we'll do it by setting up our *own* Zezere, and
provisioning our IoT system in that. We run two tests. The
'ignition' test is the actual IoT 'device'; all it really does
is boot up, sit around, and wait to be provisioned. The 'server'
test first sets up a Zezere server, then logs into it, adds an
ssh key, claims the IoT device, provisions it, and connects to
it to create a special file which tells the 'ignition' test
everything worked and it can close out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is to make the infra folks happy, apparently using 10.0.x.x
and 10.1.x.x is causing conflicts since our actual infra network
uses those ranges too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Since systemd-246~rc1-1.fc33, network install images crash if
booted with only 2GiB of RAM. No-one seems to be fixing this
as a matter of urgency, so let's just bump the tests to 3GiB at
least for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://fedoraproject.org/wiki/Changes/SwapOnZRAM changes things
a lot here. No swap on disk is now the default case, making these
tests obsolete. We'll probably want to test various different
configurations around ZRAM swap instead - ZRAM swap *and* disk
swap, disk swap only, all swaps disabled - but that's a more
complex change that will need a ticket and a PR, so for now let's
just cut these tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test that automates
https://fedoraproject.org/wiki/QA:Testcase_Clevis. It requires
os-autoinst-4.6-18.20200623git5038d8c or newer, and a worker
host in the 'tpm' class which is set up to have an instance of
swtpm running at /tmp/mytpmX , where X is the worker instance
number, for each worker. The Fedora infrastructure ansible
plays have been updated to handle this via an instantiated
systemd service, which other instances can also adopt.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds new variant test suites for several of the base tests
to run them on Cloud disk images. We can't re-use the existing
test suites because they have `START_AFTER_TEST` defined and
there's no viable way to undefine it (there are things you can
do to override the value, but you can't just unset it). Also
add a stray test we weren't running on aarch64, and correct some
priorities.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a pair of tests, one which does almost all the work
from the test case, the other just a client test to check that
we can connect to an HTTP server running in a container on the
host. We also have to bump the _console_wait_login timeout on
this path a bit as we're booting a disk image that was installed
with DHCP working, but we change the network setup so DHCP does
not work any more, and the system spends quite some time trying
to bring the network up on boot before eventually giving up and
proceeding.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I started out trying to fix os-release for the recent change to
add "Prerelease" tags to the VERSION and PRETTY_NAME fields, then
things spiralled. It got me thinking about the awkward DEVELOPMENT
variable we use, so I decided to get rid of it and refactor the
few things that use it. I refactored the anaconda prerelease tag
check, and wrote a new giant comment that gives details about
exactly how anaconda decides whether to show those tags, to give
context to our choices about when to expect them. This check now
uses a new LABEL variable the scheduler now sets. I also wound up
creating new UP1REL and UP2REL vars to define the 'source' release
for upgrade tests, separate from CURRREL and PREVREL, which are
now never lies - they really are the current stable and previous
stable release, even for update upgrade tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a new test that implementsQA:Testcase_desktop_login
on both GNOME and KDE.
While working on this, we realized that the "desktop_clean"
needles were really "app menu" needles, and for KDE, this was
a duplication with the new "system menu" needles, because on KDE
the app menu and the system menu are the same. So I (Adam)
started to de-duplicate that, but also realized that "app menu
button" is a much more accurate name for these needles, so I was
renaming the old desktop_clean needles to app_menu_button. That
led me to the realization that "check_desktop_clean" is itself a
dumb name, because we don't (at least, any more, way back in the
mists of time we may have done) do anything to check that the
desktop is "clean" - we're really just asserting that we're at a
desktop *at all*. While thinking *that* through, I *also* realized
that the whole "open the overview and look for the app grid icon"
workaround it did is no longer necessary, because GNOME doesn't
use a translucent top bar any more. That went away in GNOME 3.32,
which is in Fedora 30, our oldest supported release.
So I threw that away, renamed the function "check_desktop",
cleaned up all the needle naming and tagging, and also added an
app menu needle for GNOME in Japanese because we were missing
one (the Japanese tests have been using the "app grid icon"
workaround the whole time).
