This test expects to pick up from freeipa_webui, but that test
is not fatal (i.e. it can fail and we still carry on to this
one). We should probably make them independent, but for now,
just check if 'test3' (one of the users freeipa_webui creates
and that this test requires) actually exists, at the start. If
not, we can just die right away.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This reduces duplication, but it also means that if the FreeIPA
web UI module fails, the password change module will pick up
from a point where Firefox is set up and won't fail in a bogus
way because it isn't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There are cases where we get logged back into the FreeIPA web UI
automatically by a stale kerberos ticket or something. If we're
logged in as the *right* user, let's just treat this as a soft
failure and continue with the test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems aarch64 needs 12 'down' key presses like ppc64, not 13
like x86_64. Tweak how this is done a bit; the ternary wasn't
elegant any more with the aarch64 change, so just get rid of it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This mouse placement is in the middle of where the 'install
addon' popover appears in Firefox, and that seems like it
sometimes causes the popover to immediately disappear in KDE.
This is pretty corner-case-y so I don't wanna report it as a
bug, let's just tweak the cursor hiding location and see if it
solves the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...I hope. This is necessary as we now have a case where it
needs to match post-install (aarch64 support_server, since
aarch64 is always UEFI).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This works around RHBZ #1552814, and it's not incorrect really
because the repo is always empty for Branched. I didn't do it
before because we might theoretically start using the repo for
Branched at some point in the future, and if we did that we'd
probably want it enabled for this test. But to get F28 update
tests working, let's just turn it off for now.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This doesn't really work, it needs a product with that explicit
version to make it work, apparently. I think I'd better just
take this out and read up again on how the wildcards work rather
than just messing around with it. I'll put it back if I can be
reasonably sure of making it work.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...as somehow a Workstation live install currently has the
desktop on tty3, I have no idea why (g-i-s not quitting right?)
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the best workaround I can think of for RHBZ #1553807 -
just check (in the 60 second 'move the mouse' loop) if anaconda
is still running, based on whether its icon is in the top bar
(on Workstation live installs only, obviously).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems with the long period of not doing anything and possibly
with very aggressive timeouts in Fedora 28, Workstation live
wants to blank the screen while we're installing. Stop it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Previous approach wouldn't work for tests that run after the
install test...let's just set a password from a chroot after
install completes. Don't really like this as it changes the
'real' install process a bit, but it's the least invasive short
term fix at least. We can maybe do something more sudo-y later
with a bit more thought.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's really INSTALL_NO_USER, not USER_LOGIN='false'. Also, we
need to make root_console work with no root password, sigh.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sigh, 'overloaded' product templates like that don't quite work.
So, let's try doing it a different way, in main.pm.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Workstation live installs for F28+ drop the user creation and
root password panes from anaconda, so we need to not try and
use them any more. But we still want the old behaviour for F27.
I'm hoping this approach will work, if not, we'll find out soon
enough. This removes the install_no_user test for F28+ as it
will no longer differ from the install_default test.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Atomic was renamed AtomicHost, and Workstation Ostree was renamed
AtomicWorkstation, for F28+. As we still have F26 and F27 images
which will have the Atomic name, we duplicate those templates,
but there should be no more 'Workstation Ostree' images, so we
just rename those templates to the new name.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In the most recent Rawhide compose, anaconda has changed how it
names volume groups (again), and now the VGs in openQA installs
have rather longer names. This winds up causing a problem for
this needle: the column where the 'Device Type' dropdown is
placed actually gets narrower (because the column to the right,
which has the volume group name in it, is wider), and so the
dropdown box is narrower, and the arrow protrudes into the area
which the needle expects not to have an arrow in it. So, let's
make the match area slightly narrower.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This adds a check that the default package set selection is
actually correct, where possible and appropriate, as part of
the `_software_selection` test. We do this by examining the
`packaging.log` log file and checking which environment group
was selected.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is currently broken, but openQA doesn't notice; we really
should. We could also check the default in other cases, but I
think that's less clear-cut, as it's kind of an anaconda design
choice, it's not mandated in Fedora requirements anywhere.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a problem with using `--releasever=rawhide` for upgrade
tests ATM - see #1531356 . To avoid this, we'll try using the
real Rawhide release number (which I'm adapting the scheduler
code to discover and pass in as `RAWREL`).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Rawhide has a bit of a problem where its 'description' of an
iSCSI disk is so long that the other columns that should appear
in the CONFIGURE MOUNT POINT dialog don't. This means our
device_sda_selected needle doesn't match, because the column
where 'sda' should appear isn't visible.
So add a soft-fail needle to cover this case; we know what the
description for the disk that's 'sda' in this case looks like,
so match on that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Time for an annual spring clean. Based on the admin UI's list
of needles that haven't been matched for a long time, but with
some manual tweaking (some are actually still needed).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
virtio graphics still seem to suffer from RHBZ#1403365, and also
os-autoinst believes they don't support snapshotting. So let's
try qxl for x86_64 UEFI. *That* may still suffer from #1403343,
but oh well, seems like we have no good choices here.
It looks like ppc64 also suffers from the Plymouth bug that's
affecting x86_64 UEFI + 'std' graphics, so let's use virtio
there - qxl apparently isn't available on ppc64 VMs, at least it
doesn't work in our deployment.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This somehow snuck in (in the wrong directory) with the ppc64
merges, but it's not needed. I've verified with the admin tab
for checking on needle use; this needle has never been matched,
and all the ppc64 text install tests match the non-variant
needle just fine. So I'm removing this unneeded variant.
The way GNOME Software displays an error after running into RHBZ
1314991 has changed, it seems, so we need a variant needle to
cope with that. Also, when an upgrade notification is visible,
the 'Restart & Update' button for doing a regular update is
shown in grey (not blue), so we need a variant needle to handle
that too.
