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
The 'rawhide' tag repo used to be just a symlink to the 'fXX-build'
one, but With the on-demand repo changes, that's no longer the
case. It looks like the 'fXX-build' repo gets regenerated more
often than 'rawhide' (which seems to regen every two hours), so
let's use 'fXX-build' instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's some ambiguity about the case of the ELN version string.
Currently it's "ELN", it's going to be "eln" soon. Let's just
always use case-insensitive comparisons.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're dropping the live user mode patch from g-i-s downstream
because it's just too hard to maintain, apparently. So on Rawhide
the live image will boot to the welcome screen as normal, but
running the installer will give you newui rather than webui. If
you need a language other than English you have to sort it out
at the desktop before running the installer.
On first boot, g-i-s will show *all* screens, not skipping
language, keyboard layout or timezone, because we did not see
those in the installer.
This adapts the tests to handle the new flow, and should still
work with the other flows.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Intentionally or not, a recent anaconda change made it so the
"text mode sucks, use VNC instead?" question is no longer ever
shown - https://bugzilla.redhat.com/show_bug.cgi?id=2293672 .
So, we should handle the flow where we just go straight to the
hub. If they decide this was intentional and kill the question
for good we can drop the path that handles it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We already try twice, but that seems to be not enough for the
annoying #2280840, we're often seeing failures.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're getting failures in the update network install tests today
which seem to be because we're using an image built with systemd
256 to install systemd 255. This is because systemd 256 has been
tagged but isn't in a compose yet, and we use the Rawhide tag
repo when building the installer image but we don't add it as an
additional repo for the install itself.
This is obviously a hole in the process, we should use the extra
repos, where appropriate, all the way through. So this makes us
use both the Rawhide tag repo (when doing a Rawhide install test)
and the workarounds repo (when there are workarounds) for network
install tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a workaround for
https://github.com/osbuild/images/issues/309 , the IoT installer
showing incomplete spokes in the main hub. We work around it by
visiting them all.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We're taking a long time to reach it on aarch64 on prod recently
for some reason. It's probably some weirdness with qemu/edk2. So
let's just bump the timeout as I don't have an easy fix on hand
and this won't hurt anything.
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 is tailored to the initial deployment of webUI in
Workstation live images only; we may need to tweak flows and
approaches as webUI goes further.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Upstream https://github.com/os-autoinst/openQA/pull/4973 requires
us to poke things here a bit. This only works with the newer
os-autoinst and openQA (there may be a way to conditionalize it
to work with both, but I can't be bothered figuring it out, let's
just update).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In today's F38 and Rawhide, changes to the persistent overlay
stuff result in a boot warning you have to spam through. Let's
handle this as a soft fail so we don't have floods of failed
tests till it's fixed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
What's supposed to happen here is the `do_bootloader` invocation
a few lines back boots to the installer, then here, we wait for
the install to complete and the system to reboot, and match the
bootloader again. However, on PXE installs, the bootloader screen
can hang around for quite a long time here, and if it does, we
can match it again before the installer starts up, and move on
too early. Hence the sleep.
It seems on current Rawhide 20 seconds isn't long enough - we're
still matching the installer bootloader after the sleep, see
e.g. https://openqa.stg.fedoraproject.org/tests/2431660#step/_boot_to_anaconda/3
This is causing the test to almost always fail (it'll only pass
if the install+reboot takes less than five minutes). Let's bump
it to 60 seconds and hope that's long enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This fails sometimes just because we're too early, or something.
Also with GNOME Shell 41rc, alt-f1 no longer works to open and
close the overview. super *does* seem to work in KDE these days,
so let's switch from alt-f1 to super everywhere.
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>
KDE has made it so you need to double-click icons on the desktop
now. Unfortunately this means a clunky conditional at least until
the update goes stable. When F33 is EOL we can reduce it to
just "if kde".
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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 consistency, let's just return to the desktop right away. We
also need to handle closing the overview before running installer
on live image boot.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Lately launching anaconda on the KDE live image seems pretty
unreliable and we're not sure why. My last attempt to fix it
doesn't seem to be working, here's another effort based on the
idea it might be caused by moving the mouse from the hidden
position to the icon and back again, let's try moving the mouse
close to the icon before we assert and click it...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE tests are quite frequently failing lately because anaconda
doesn't launch. I'm hoping this will help.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There is nothing inherently 'root'-y about these so it makes no
sense to prefix their names with 'root-'. And why change from
'console' to 'terminal' compared to the naming used in the
actual qemu command and the log files? It's just confusing.
Let's be consistent (except for using - instead of _ here...
but - is easier to type!)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a test for QA:Testcase_Anaconda_User_Interface_VNC -
the VNC install test case. It's implemented as a server/client
pair, with the server booting from the Server DVD image with
`inst.vnc` and the client booting from the desktop base disk
image, setting up networking, then running Boxes to connect to
the server and run the install.
There are various little tweaks to test loading and logic to
handle this, mostly pretty clear. We also move the workaround
for 'spurious auth prompt appears on desktop after you switch
away to a VT and back' out of the desktop update test and into
the `desktop_vt` helper function, since now this test can hit
it as well. We enhance _graphical_wait_login to handle the boot
loader if needed (it has never needed to until now).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
One of the test cases we didn't yet automate is:
https://fedoraproject.org/wiki/QA:Testcase_Kickstart_File_Path_Ks_Cfg
Now we have a PXE test, it's actually a good opportunity to test
that at the same time. I don't usually like combining tests like
this but in this case it sort of makes sense as otherwise we'd
have to have a whole parallel PXE install just to test this one
other detail. So, instead of doing an interactive PXE install as
we did at first, let's tweak the test to include a kickstart in
the initramfs and run the install from that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a whole wodge of stuff to support_server to make it
act as a PXE server, then adds a new test which boots from PXE
and so should hit the PXE server. We use the NFS install repo as
that can be relied on to work for a support_server install.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So, turns out new os-autoinst does *not* still accept the old
argument style for assert_and_click...and old os-autoinst
doesn't accept the new one. This adds a wrapper that handles
both, so our tests can work with old and new os-autoinst. We can
drop this once both deployments are on newer os-autoinst.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In the new os-autoinst I just sent to staging, the old style
doesn't work any more, breaks all tests. This style should also
work with the older os-autoinst on stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems 3 secs was a bit tight for recent Branched and Rawhide,
test was failing when the screen was just a bit slow to update
for some reason.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In https://bugzilla.redhat.com/show_bug.cgi?id=1669256 it became
obvious that there's a missing feature in the new installer test
for updates: the update is both used in the image build process
and built into the installer environment itself, but it is not
actually included in the installed package set. This can be a
problem if the update has a bug that manifests *only* at install
time if it is in the install transaction (which is exactly the
case there), because the test will not catch this, and nor will
any other test.
So this commit makes `support_server` set up the update repo and
serve it out via NFS when it's run in an update context, and
makes the actual update install test run parallel with it and
use that repository. This way the install should include the
package(s) from the update. (It also of course means the test
fails if an update breaks NFS or something like that, but hey,
we want to know that!)
A parallel commit for fedora_openqa is necessary to add the
required CURRREL setting for the updates-installer flavor.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There seems to be an issue in Rawhide ATM which can cause the
'beta nag' screen to take a very long time to appear. Bump the
timeout to avoid tests failing on this.
https://bugzilla.redhat.com/show_bug.cgi?id=1666112
Signed-off-by: Adam Williamson <awilliam@redhat.com>
