We get Welcome Tour now, not gnome-initial-setup new user mode,
and it doesn't respect the dotfile g-i-s respected.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
In GNOME 40, the new-user mode of g-i-s is gone and we get the
welcome tour where we would previously have seen that. This
should handle that, I hope. I probably messed up somewhere.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
KDE in F34+ is now placing sleep, restart and shutdown buttons
right on the system menu, not in a submenu. So we need to sort of
tweak this logic. The approach here is: we count the GNOME
submenu as both a "power" and "leave" menu, so the needle to
enter it has both tags. KDE still has a "leave" submenu, but the
power options are not in a submenu any more, so the new "leave"
needle only has the leave tag, not the power tag. For "leave"
actions we just unconditionally expect the "leave" tag; for
power actions we first match on *either* the submenu tag (for
GNOME and earlier KDE) *or* the action tag, click whatever we
found, and then if we matched the submenu (not the action), we
assert and click the action. After that all paths should be in
sync again and we can continue.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is how our Pungi config has been set up since F32, so we
should match it here to be accurate.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR uses the Anaconda Blivet partitioning to recreate a partition
layout while preserving the content of the /home subvolume.
It also adds the postinstall test to check that the home has been
preserved.
This PR adds the `install_btrfs_upload` to install the btrfs based
image, the `btrfs_preserve_home_extras` to prepare and test the data
on the home partition, as well as the `custom_btrfs_preserve_home` that
uses the preinstalled btrfs image and uses its current partitioning to
preserve the home partition and the data on it.
Required because ppc64le has a PReP partition
before boot partition.
PReP partition must not be changed by this script.
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
OK, looked into it some more and ultimately we had problems here
because of https://bugzilla.redhat.com/show_bug.cgi?id=1908791
in fact. The password prompt was taking far longer than usual to
appear because pam_fprintd was failing because of that bug. That
should be fixed with next Firefox build, so I think it's best to
just leave this as it was, because in the usual course of events
it works fine and it saves having another needle to maintain.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...nope, wait_screen_change wasn't enough. Let's just assert the
needle. Not sure if the existing one will work, if not we'll add
one.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Sigh I hate this test. We seem to be typing root pw before the
terminal is ready for us:
https://openqa.fedoraproject.org/tests/745007#step/desktop_terminal/3
Let's try this. Hopefully it'll wait for the Password: prompt
before typing, without us having to actually add a needle...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Using .local is apparently Bad Form because it's reserved for
mDNS. However there doesn't appear to be any particularly Good
Form for what to call a test domain you never want to exist
outside of a closed system, apparently. Sigh. Let's try this.
Includes a bump to disk_ks version because the kickstarts on
that image also need to have this change applied.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is another known "fails due to no hardware" case:
https://bugzilla.redhat.com/show_bug.cgi?id=1894654
those are explicitly excluded from the release criterion, so a
soft failure is appropriate.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't *need* to log out from the desktop and reboot from the
DM here, that's not part of the test (we test those features
later using jim and jack). Now we don't black out the background
of test's session in KDE, the logout needle doesn't match, so
instead of redoing that needle all the time or re-adding the
solidify_wallpaper call just to make one needle match reliable,
let's just reboot from the console.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
solidify_wallpaper only does the current session, and does it in
a kind of painful way on each desktop. For apps_startstop this
is kinda okay, but for desktop_login it's slow and error-prone
to do this three times, every time. Let's replace it with a hack
that just replaces the actual wallpaper files with a solid black
PNG file. This only takes effect after a logout, but it should
affect all logins on all desktops once it's done. So long as
the base backgrounds package doesn't change layout too much.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This makes it so the `wait_still_screen` that comes at the end
of `type_very_safely` happens *after we hit enter*, not after
we type the password but before we hit enter. I'm hoping this
makes the 'set new password at login' more robust on aarch64, it
seems to be failing often.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This allows us to use assert_script_run, and be more reliable.
Same approach used in _do_install_and_reboot postinstall stuff.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Another aarch64 robustness fix...sometimes hitting enter at GDM
just doesn't seem to work, let's give it three tries if needed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This matches the wait in boot_to_login_screen. The needle can
match before the UI is really done loading, and if we don't wait
long enough we wind up hitting enter before GDM is really ready
for us. This seems to be affecting the test on aarch64 quite
badly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Typing into a desktop terminal is a lot less reliable than typing
into a VT. We're seeing failures here quite often on aarch64, so
let's try doing this stuff in a VT instead.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I tried to bump it before, but set it to 90, which is the default.
Sigh. So this is an actual bump. It looks like until 20201124 this
took about 80 seconds, now it's taking like 93.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The review for `btrfs_preserve_home` test case has revealed,
that the way how to reach the mountpoint textfield in the Anaconda
partitioning differs between various tests. This PR makes it the
easiest way possible, as is defined by `custom_with_swap` test
case mentioned in the review.
It seems the message got moved to anaconda.log in Rawhide. I
think it should be fine to just check both.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR add the installation test which uses Standard partitioning
with an ext4 filesystem to cover one of the new requirements as
described in issue #202.
Fixed after a review
It still seems to be broken in 233 and 233.1; I limited the
workaround to 232 at first as Cockpit are usually good at fixing
things very fast, but as this one has sat for a while, let's
leave it worked-around until we know it's fixed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
When Fedora went to BTRFS as a default, we lost the LVM based image to
run LVM resize tests with.
This PR introduces the `install_lvm.pm` installation test that creates
an LVM based qcow2 image to be used by follow-up tests.
I noticed a pattern lately of VNC tests failing on Rawhide when
we have a debug kernel (but passing with a regular kernel). On
closer investigation I think there's simply a screen blank
happening if the install process takes more than five minutes,
and that's more likely with a debug kernel. This extends the
loop we use to move the mouse every so often while waiting for
the install to complete (which is meant to defeat this sort of
thing) to also click the mouse, when we're a VNC client test. In
a quick check this seemed to help.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Update a needle with slightly different text rendering, and add
a workaround to hit tab three times rather than once on entering
the "Join a domain" screen, see
https://github.com/cockpit-project/cockpit/issues/14895 .
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The weird bug turned out to be caused by an internal DNS zone
in the new infra not being signed:
https://pagure.io/fedora-infrastructure/issue/9411
This is now resolved, so we can drop the workaround.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Revert "Regenerate grub.cfg for ppc64le Silverblue to boot (step 2)"
This reverts commit d384cfed30.
Revert "Regenerate grub.cfg for ppc64le Silverblue to boot, brc#1817004"
This reverts commit 8d7be9a227.
Not required anymore for f33 (only for f32)
And bad side effect for f33 (failure not analysed)
eg: https://openqa.stg.fedoraproject.org/tests/949783#step/_do_install_and_reboot/32
Keep correction to avoid warning in autoinst-log when ABRT var not defined.
Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
We've had this 'exception' for mcelog.service failing in here for
years. Looking into it, it seems to now be fixed:
https://bugzilla.redhat.com/show_bug.cgi?id=1526725
and hasn't happened in our official instances for years (I guess
because they're all Intel boxes). However, we have a similar case
on ppc64le with hcn-init.service failing spuriously:
https://bugzilla.redhat.com/show_bug.cgi?id=1894654
so I'm just converting it into a workaround for that instead. We
could wire this up to be more sophisticated, with some kind of
array or hash of services that are allowed to fail and more
complex checking code, but let's not bother unless/until it's
necessary.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
So, there's a problem with how we figure out the NetworkManager
connection to use in setup_tap_static: it expects the first
connection in the list to be the right one, but this is only
actually true so long as it's *active*. When we're in the tap
case, it's usually not going to actually *work* out of the box
on boot (or else we wouldn't need setup_tap_static at all...),
so some time after boot, NetworkManager gives up on it and marks
it as inactive. And after that, setup_tap_static won't work any
more.
I never noticed this as a problem before because usually we do
setup_tap_static before that point. But it seems in the vnc
client tests, on aarch64, desktop boot and login is slow enough
that by the time we switch to a VT and try to setup the network,
we're very close to that cutoff, and sometimes miss it.
This, I hope, avoids the problem by doing the network setup in
that test before we deal with the desktop login, then doing the
desktop login, then doing the actual VNC bits.
The alternative here would be to figure out a better way to do
setup_tap_static, but I can't.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems like this often fails when booting the desktop disk image
on aarch64 if we start typing right away.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It seems like it can be *really* slow on aarch64, since 218:
https://github.com/cockpit-project/cockpit/issues/14840
this should give it a total of 180 seconds on aarch64 (90 second
still screen timeout plus 30 second assert_screen timeout, with
1.5x scale).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
