The VNC installation method has been replaced with a similar method
based on RDP. This PR uses the old mechanism and alters it for the
RDP method.
The test suite consists of two parts, a server and a client part.
The server is the real test on which Fedora Custom installation
is performed from the client via RDP.
The client is spinned off the pre-installed desktop image.
Fixes#345
VNC is gone in current Rawhide. As F41 is released now, we won't
hit these tests any more anywhere where they might work (we don't
get a Server DVD image for respins), so let's just drop the tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's no obvious reason we're not also running these tests on
updates, so let's do it. We have to skip the advisory and UEFI
post checks for desktop_login as the last step of that test is
shutting down the system.
We leave out desktop_login for now because of
https://gitlab.gnome.org/GNOME/gjs/-/issues/647
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit b3e5dd41cb.
Some testing on lab seems to indicate it's not needed any more,
at least several runs with the workarounds reverted have passed.
Will put them back if we hit failures.
This adds both the Gnome and the KDE tests to test the
Desktop Keyring. After a discussion with the Brno team,
how this could be tested without the need to rely on
external servers to log into, we set up a local FTP server,
we will log into it and remember the credentials and verify
that the credentials will be stored in the keyring correctly.
They use base disk images, and it's too fiddly to try and
arrange for the one the update test uses to be UEFI but the
other to be BIOS...let's just keep these on UEFI but kick up the
retry count :/
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reverts commit 508635ed1c and
the fix-up follow-up, because this causes the test to have a
different scenario which screws up gating. Argh. I guess we're
stuck restarting it forever. Let's bump the retry number even
higher instead.
There is a weird and annoying kernel bug ATM which makes entering
encryption passphrases into plymouth's graphical interface often
fail on UEFI VMs. Using a BIOS VM seems to avoid this, and the
bug is not getting fixed, so let's switch all these tests to
BIOS to avoid this annoying bug causing failures all the time,
especially for update tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This works more or less like testing side tags. We also fix up
some flow problems with this path (that also affect the side tag
case), and enable the package checks on this path - it's not too
hard really, we just need to write the updatepkgs file when we
set up the repo, which we can do with dnf repoquery.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When running these tests on updates we inherit the main disk
image from server_cockpit_default, which has the repo config,
but the actual repo data is on HDD_3 which is not inherited.
We need to re-download the updates here to ensure they're
available to the tests (the automatic update test installs the
dnf-automatic package, so it should pull it from the update repo
if it is part of the update being tested).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR builds on some elements of the current upgrade process,
such as upgrade_boot, upgrade_preinstall, upgrade_postinstall, but
replaces the upgrade_run with graphical_upgrade_run to use graphical
methods to upgrade the system.
This would not be possible without necessary settings, that are
performed by graphical_upgrade_prerequisites.
Works for both Gnome and KDE.
This PR partly solves the issue #301 when it adds the navigation
testing for Gnome. It uses the keyboard combinations to cycle through
running applications and checks that applications could be switched
accordingly. It also tests that you can switch between workspaces
and that you can move an applications to another workspace.
Somehow these two got completely scrambled, testing the wrong
things on the wrong images. Fix them to match the non-blivet
counterparts, which are correct.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The silverblue tests are flaky because of
https://github.com/fedora-silverblue/issue-tracker/issues/548 .
The desktop_upgrade_encrypted test is flaky on Rawhide (so, when
booting from F40 initially) since we switched to UEFI, not sure
if it's because of UEFI somehow or just a timing coincidence.
Am going to look into it, but for now this should save lots of
manual restarting.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ELN can't boot with Secure Boot enabled currently:
https://github.com/fedora-eln/eln/issues/183
Until that's resolved, let's go back to testing on BIOS (this is
easier than testing on non-SB UEFI for...reasons).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This essentially inverts the x86_64 machines so that '64bit' is
UEFI and instead of a variant 'uefi' machine we have a variant
'bios' machine that is BIOS. The point is to make UEFI testing
the default. We also enable Secure Boot in the UEFI testing,
and add a test of UEFI fallback booting on various products.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Anaconda has dropped the ability to interactively configure
additional repositories, so this test cannot work any more.
It's now possible only with inst.addrepo or a kickstart.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In current F40 and Rawhide, this test is frequently failing
because gnome-software is behaving weirdly at startup - the
third-party software dialog moves around even more than before,
the app seems to get stuck in the "not responding" state
briefly sometimes, and there's a very weird state it gets into
sometimes where the window is shorter than usual and clicks
don't seem to register in the right place. While I'm trying to
bisect these bugs, these magic voodoo incantations (tested on
the staging instance) seem to mostly work around the weird
behaviour, and setting RETRY=2 should backstop it a bit further.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's defaulting to 10Gi, which definitely has caused *some*
issues (the flatpak test fails because there isn't enough disk
space). I'm hoping this will turn out to explain why SB tests
have been generally so unreliable lately.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Per https://progress.opensuse.org/issues/151258 , PXEBOOT=once
doesn't work right in current os-autoinst. Now I look at it,
PXEBOOT is just pretty ropey in general; on UEFI and aarch64 it
doesn't actually do anything at all, we're actually just relying
on the default boot order there.
Since it doesn't seem like there's a practical way to make
PXEBOOT=once work as intended on all platforms, let's just drop
use of it and make it clear that we rely on the default boot
order: we hope that on first boot we'll get a PXE boot since no
local media are bootable, then on second boot we'll get a local
disk boot.
We set up a new IS_PXE variable to cue the couple of places where
the test logic needs to be different.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR tries to respond to issue #294.
On Silverblue, this will try:
* flatpak install
* flatpak remote-add
* flatpak list
* flatpak remotes
* flatpak remove
* flatpak update
and also it tests that a flatpak can be built.
It's super flaky ATM due to some GNOME/mesa bug(?) This will make
life easier till I have time to actually debug the issue.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Silverblue still has eog. It seems a bit excessive to bring back
the eog test just for Silverblue, so let's just disable loupe
until Silverblue has it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds a test for a new Image Viewer called Loupe.
It is based on the old Image Viewer test, newly reneedled
with some of the tests shortened, deleted or edited
as the new Image Viewer has a little bit less functions
compared to the previous one.
Add needles.
There's no obvious reason it'd ever give a different result on
KDE vs. Workstation, but since we added a matrix box for it on
both, we'd better run it on both.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The affected tests start after install_lvm_ext4, so we need to
bump HDDSIZEGB there, not in the downstream tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
With the 2G ESP change, we need bigger disks for these tests to
work correctly. On BIOS the test still just about works because
anaconda rounds the remaining space after BIOS boot partition
and /boot to 14G, but it seems fragile to rely on this. On UEFI
(aarch64), anaconda sees a max of 12G remaining after 2G ESP
and 1G /boot, so the test fails because we cannot size to 13G.
Give the test an extra 2G, this should be sufficient to make
sure it's valid on all platforms.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a Samba AD server test, and client enrolment tests via
sssd, Cockpit and kickstart. Requires the matching createhdds
commit to add the kickstart to the disk_ks image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Modularity will be retired in Fedora 39 and the modular repository
removed. Also, the upcoming version of DNF that is default in
Rawhide, does not support modularity, so the tests are currently
failing anyway.
This requires a change in the package we use for base_update_cli
because pandoc-common is not in ELN.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The ISO or HDD image won't be attached to the post-upgrade
tests, and these are not tests of the image anyway, they're
tests of the compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
