This is all about
https://bugzilla.redhat.com/show_bug.cgi?id=2417493 . That is
causing KDE and i3 install tests to fail very often. It also
affects uefi_no_fallback because that needs to at least launch
the installer.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The new vkcube --validate test fails on Fedora 42:
https://bugzilla.redhat.com/show_bug.cgi?id=2418077
while we wait for a response to that bug, let's go with treating
this as a soft failure. We use an md5sum check to try and ensure
that the output is *exactly* what we're expecting; if there are
any unexpected messages, we'll still fail.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a follow-up to the recent broken mesa update kerfuffle:
https://discussion.fedoraproject.org/t/173585
one outcome of that is we determined the vulkan layer validation
check actually works in a VM with llvmpipe. The command we run
here completes successfully with mesa 25.2.7-3.fc43, but crashes
with mesa 25.2.7-2.fc43. So it seems like a good idea to add this
test. I'll probably backfill a manual test case and add it to the
wiki matrix later.
I gave it a generic name in case we come up with more similar
checks we can add later. I've asked airlied for any suggestions
he might have.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This test is currently failing quite often on KDE:
https://bugzilla.redhat.com/show_bug.cgi?id=2404267
To mitigate the flakiness, let's set RETRY to 3, using a variable
to target it as tightly as we can.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
To try and mitigate flakes from
https://bugzilla.redhat.com/show_bug.cgi?id=2417493 let's bump
the RETRY value for this flavor, so we'll retry the install test
several times if we hit the slitherer crash.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Lately quite a lot of tests are failing here on GNOME because we
don't type terminal properly (we wind up with 'trminal' or
'teminal' usually). At first I thought my os-autoinst typing
delay change might be causing this, but it actually seems to have
started before I deployed that, so no idea what's going on. Let's
click instead of typing, to avoid the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The remote repository for testing flatpaks has changed.
Now, it not only contains the x86_64 version of the application,
but also the aarch64 version.
The commit numbers of the specific application version have changed,
too, therefore we need to update this file and also make the difference
between the architectures.
Fixes: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/461
The failure message here isn't very helpful unless you know what
is going on and where to look for the errors. Let's improve it
so packagers have a better chance of understanding failures.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In https://bugzilla.redhat.com/show_bug.cgi?id=2417302 it seems
like the post-install chpasswd we use to set the root password
on install paths where the installer doesn't let us do it can
cause /etc/shadow to have the wrong SELinux context, which can
then cause denials later, at least with new shadow-utils. This
should avoid the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's still going through gating tests but I want to be able to
start restarting other failures with the fix.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Thanks to @jlinton , who worked out that the repeated inputs on
aarch64 seem to be caused by the relatively lengthy delay on
key down that we get when typing very slowly. Typing a bit faster
is actually more reliable in this case. I'm working on an
os-autoinst tweak that would avoid the lengthy key holds when
typing very slowly, which would allow us to revert this.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't have a Silverblue disk image AFAIK, so let's just run
the ISO tests on aarch64 for composes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
No reason these should only be run on the x86_64 live. Also
refactor the remote_desktop_client test to share the code for
opening a connection in GNOME Connections with the RDP install
test. The shared code is a combination of the two which should be
more robust than the previous remote_desktop_client version, which
was relying far too much on timings working out. This caused it to
fail often on x86_64 as well as on aarch64.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Basically, add them all to aarch64. This also turns some on for
ppc64le which isn't really intended, but we aren't using ppc64le
ATM and it keeps things simple. I'll probably send a PR to get
rid of the ppc64le stuff at some point.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Run the remaining kiwi_build tests on aarch64 - container and
the KDE and Workstation lives. Also do the install test, for the
lives.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
As discussed in #447 I don't think these are serving a purpose
any more. Let's try dropping them and see how it looks.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When openQA connects the iso files, it emulates the CD-ROM drive.
In the past, issues were reported that an ISO burnt to a flash drive
would not boot properly. Forcing openQA to emulate a USB flash drive
when booting and installing a system could help us catch these issue
in the future.
However, there is a small problem here. When booting from an emulated
optical drive or USB stick, openQA gives it boot priority throughout
the life of the VM. For optical install tests this isn't a problem
because anaconda automatically ejects the 'disc' at the end of the
install process, but there's no equivalent for USB, so if we just
reboot after install, we boot back to the installer.
To resolve this, after install, we go to a console, cleanly stop the
system with `systemctl halt`, then disconnect the USB stick from the
VM using a qmp command that is now exposed by os-autoinst.
Fixes: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/34
Extending the wait to 3 seconds in the utils.pm function probably
wasn't necessary; the problem is we were reimplementing it in
_do_install_and_reboot but without the wait. Let's revert the
wait to 3 seconds and use the function.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Since we switched to building i3 with Kiwi (I think), it's being
properly identified, so we need to add it here for the test to
pass.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We do upgrade_desktop rather than encrypted because of
https://bugzilla.redhat.com/show_bug.cgi?id=2392684 (which I
still haven't managed to figure out the cause of).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
10 seconds isn't enough, the aarch64 upgrade tests often fail
because they're still Refreshing Data after 10 seconds, then
the ignore button appears but we already quit looking for it.
Let's wait 150 seconds for *either* the ignore button *or* the
UI to appear, if the UI appears we're done instantly, if the
ignore button appears, click it and wait for the UI.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need to disable these sockets as well or resolved pops right
back up and interferes with dnsmasq, now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Previously the name of the application was ExtremeTuxRacer,
but it was changed to extremetuxracer. The application could
not be installed, so this should fix it.
As requested by @kparal in
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/417 ,
this matches the modified test case by creating the EFI system
partition and /boot partition on RAID devices, as well as the
root partition. Also let's make them a bit bigger; if we leave
the value at 512 they actually get created 511MB big (dunno why)
and anaconda complains. Anyway, bigger sizes are prudent these
days.
We also need to create a BIOS boot partition on the second disk
in the BIOS test now. Apparently if /boot is RAID-ed, there has
to be a BIOS boot partition on each disk. This is a bit of an
ugly implementation, oh well.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
INSTALL_RETRY was introduced to try and retry live installs five
times to mitigate the effects of
https://bugzilla.redhat.com/show_bug.cgi?id=2329581 . That bug is
fixed, but we *do* still have some flakiness in live install
tests; we still occasionally hit the thing where install just
stalls for no obvious reason, we sometimes hit
https://bugzilla.redhat.com/show_bug.cgi?id=2402533 , and
(especially on KDE due to
https://bugzilla.redhat.com/show_bug.cgi?id=2404262 ) we sometimes
get failures caused by mistyping in language select or user
creation.
So let's keep INSTALL_RETRY around, and use it on more tests -
these are all webUI install tests that run on the live images -
but drop it to 1, 5 is probably overkill for the current known
issues.
Also, let's define it for all flavors. In the initial commit I
wrote that if it was not defined, RETRY would be set empty, but
that's not true. What actually happens is RETRY gets set to the
literal string %INSTALL_RETRY%, which is goofy. openQA still
seems to interpret it as "don't retry", which is good, but let's
avoid it.
Also move the workstation_live_iso definition into the flavors
with all the others, I don't know/remember why only that one
was in products.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The previous needle commit did not solve the situation with
routing, the error seems to be there still. However, the search
test was failing because of expired needles. This commit adds
the replacements to make that test finally pass.
Just accepting page 2 isn't enough to fix the test, as lots of
later parts of it expect that we're on page 1. So let's try and
handle that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
