It's not reliably in ELN (it's sometimes in the buildroot repo
but we shouldn't rely on that). We already pass --nomacboot to
the actual build command on ELN, so this should be OK.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We know we need these, but I can't get them created yet because
there's a bug in plasma-setup preventing us getting that far...
when we type in the language search box, we're typing Greek, for
some reason.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Can't get the rest because there appears to be a bug with the
keyboard layout; we're typing Greek.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Instead of adding the tags to the 'allow list', let's just add
the 'repeat_click' utility function to our list of functions we
look for when deciding what tags are actually used in the tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is broken with latest Firefox, but @stransky has requested
we ignore it and allow the update to go stable as it's a security
fix. To do this we have to remove this part of the test, or else
it will fail for all subsequent updates once we allow the Firefox
updates to go stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't need to match on the icon *and* the text. It seems
something changed in Rawhide recently which changed the spacing
between the icon and the text and made all these fail. Instead
of creating new needles, let's adjust these to only match on
the text.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I'm still seeing tests fail on this, e.g.
https://openqa.fedoraproject.org/tests/4053311 , despite our
existing attempt to handle the animation with waits. So let's try
something heavier duty: as well as waiting for still screen,
we'll retry a few times if the button still seems to be there.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE is switching to a Workstation-like model where the user and
root password screens in the installer are suppressed, and a
KDE-specific initial setup wizard runs on first boot. This adapts
to handle that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 9af30427e8. We
think we've got the bug fixed in edk2 too now, so let's revert
this and keep an eye out to make sure the hangs don't come back.
This seems to be going wrong quite often in the remote desktop
client test - we're getting 'lo' and trying to do a static config
on the loopback interface, which clearly isn't going to work.
This should either fix it or at least give us some idea why it's
going wrong (maybe we don't have any ethernet connections?)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All the blivet custom tests are failing because anaconda is
warning about /boot being too small. Let's bump the sizes to
something more modern. 2G is the current /boot/efi default, 1G
is the floor to avoid the warning for /boot it seems like.
For software RAID we have to go 1 higher than the size we really
want as it seems like some kinda RAID overhead means we get a
partition 1 MiB smaller than we requested:
https://bugzilla.redhat.com/show_bug.cgi?id=2419063
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We get quite a few failures where the getent passwd
'SAMDOM\Administrator' check just returns nothing for some
reason. It seems like it might be a network race or something,
and this magic wait looks like it helps after a few days testing
on staging, so let's try it in prod too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=2417734 is about a
bug we've seen with edk2 20250812 and later where VMs quite often
seem to hang on boot, or at least boot extremely slowly so the
test times out waiting for them to reach a login screen.
We found out in testing that using the smaller-sized edk2 images
seems to avoid the problem, so let's do that until it can be
fixed properly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We already try to only hit download once by dropping it out of
the tags after the first time we hit it, but because we need
this check_screen to catch when *both* apply and download are
visible, we will click download twice if both apply and download
are visible on later loop iterations. So, let's guard against
that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
