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.
We don't always get a smartd error any more, so add one for a
different error that's more consistent ATM.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The background seems to be different in different tests, even
the reduced area I tried most recently seems to be different in
some runs. So let's just match in the text area instead. This
captures some "Fedora" text so it should still notice if branding
is broken.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
The font of the identifier text got a bit smaller. I think it
looks kinda bad now, but it's not an outright bug, so just
living with it. I did file an upstream issue:
https://github.com/cockpit-project/cockpit/issues/15111
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There's a race issue with just treating it as a next button: it's
not in the same place as a next button. Sometimes in the g-i-s
code we actually get ahead of ourselves and click early, which
isn't really a problem when the buttons are all in the same
place, but if we click "Start Setup" in the middle of transition
to the Privacy screen - as in
https://openqa.fedoraproject.org/tests/745034#step/_graphical_wait_login/4
- the click effectively gets lost. So let's make it its own tag
and have the initial assert look for it too. That way we won't
match on it again in the main loop over "@nexts".
Signed-off-by: Adam Williamson <awilliam@redhat.com>
There seem to be some weird shenanigans going on with the pipe
bit here (it looks different on different test runs? what?) so
let's just match on the plain grey area. Should still be enough.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Just matching the Overview entry isn't really enough, the app
hasn't really run yet. This makes the test more robust and also
helps out on aarch64 desktop tests where the app window takes a
long time to appear.
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.
Styling on the KDE base disk image seems to have gone wrong
again, which throws this test off. We need to figure out what's
gone wrong in the base image, but it's a Friday night and I don't
want the test failing all weekend, and there's nothing wrong in
the *test itself*, so let's create some workaround needles and
figure it out next week.
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>
We've been getting failures lately on the first page load, I
think because Firefox is getting even more grindy on startup. So
turn the 'sleep' into a 'wait_still_screen', extend another wait,
and tweak the 'browser' needle so it only matches after the
bookmark bar has loaded rather than as soon as half the chrome
appears. Also make all the wait_still_screens use similarity 45
for consistency (flashing cursor could be there on any of them).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Dropped the use of this in the recent notification simplification,
but forgot to remove the needle. Should've run tox...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is the best option I can come up with to deal with #195.
Update notifications seem to have become transient in KDE lately
(even in F31 and F32, if I'm looking at these screenshots right).
This actually simplifies things a lot to do more or less the
same in the KDE and GNOME paths: open the 'permanent' store of
notifications (in GNOME you get to it by clicking on the clock,
in KDE via the systray) and then look for no notifications (live
path) or only an update notification (post-install path). We
only run this test for composes so we shouldn't need to worry
about anything older than F32, and I believe this should work
for KDE in F32 and F33. I left out click_unwanted_notifications
for now as I'm hoping it should be unnecessary, but we can add
it back in if necessary.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
