With CPUARCH being set up automatically from the system via the
platform.processor() function, on some machines an empty string
is returned and the script refuses to build any images.
According to the documentation for the platform module, this can
be an issue with some processors, that either return nothing
or return the same string as with platform.machine().
This PR adds the option to obtain the value from platform.machine()
if the first (and preferred) method returns nothing.
This should give our KDE disk image a package loadout more
similar to a live install, the typical way of installing KDE.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
With the new 2G EFI system partition size, the delete_partial
test that uses this disk image is failing. We've reported the
bug, but we don't want the test to fail the same way every day,
we want to catch any other bugs that show up. Tweaking the disk
image so it has a 6G and a 4G partition (instead of two 5G
partitions) and the test uses the 6G partition seems to work
around the problem, so let's do that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Otherwise they don't boot, see:
https://bugzilla.redhat.com/show_bug.cgi?id=2209760
This is fixed from F39 onwards (it will use MBR disklabels for
ppc64le installs by default), but since we're still building F37
and F38 disk images now, we need it here.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
`platform.processor()` seems to be returning '' a lot where it
wasn't before. Not sure why, but let's add a fallback to
`platform.machine()` to give us another shot at getting a value.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We ship updates pretty fast, and after seven days, there are
hundreds being installed on every update test. It's gotta be a
better tradeoff to just regen the base images more often.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Rawhide update tests are all failing ATM due to
https://bugzilla.redhat.com/show_bug.cgi?id=2164207 . This should
work around the problem by including the latest version of
python3-ptyprocess in the base image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need this to switch from root to test for the Cockpit tests,
since Cockpit stopped allowing login as root.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
kde-38.ks with the side repo containing a non-debug kernel was
another attempt to workaround #2133829, so let's drop that too.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I was actually already doing this for desktop only with a monkey
patch on the HDD workers which I'd forgotten about, bad me. Make
it 'official' and do it for KDE as well as desktop. This would
explain why we keep hitting bugs with this stuff in the KDE tests
but not the desktop ones...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I want to rebuild the KDE Rawhide images as tests are failing
on the oomd bug due to the size of the current update set, but
I want to get a non-debug kernel into the base image rather than
a debug one...this one just missed today's compose.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Now we want to test Rawhide, 14 days is a bit too long. After
13 days, Rawhide updates are absolutely piling up, and it can
cause the `dnf update` run at the start of update tests to time
out.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
After looking at the openQA side, I think I prefer this way of
doing things overall. If we use 'rawhide' in the filenames, we
have to use 'Rawhide' as the VERSION on openQA side, and that
involves quite a lot of surgery. If we can use the release number
as the VERSION on openQA side for Rawhide updates, that seems to
work better, and tie in better with Bodhi.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We don't need the release version conditional any more as we're
well past F31. Also this way it'll work for Rawhide.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This should fix the desktop_fprint test when running on upgrade
(not fresh install). No idea how the test ever worked, but I
think this is why it's been broken since January.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This more closely matches our usual installs, and fixes a problem
in the (under-review) GNOME Software tests.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Not sure why, but it's the plymouth theme that's breaking update
tests on ppc64le; if it's installed, typing into the VT after
boot doesn't change the screen. Removing the plymouth theme from
the base image fixes the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
upgrade_minimal_64bit for Rawhide needs it. Honestly I don't
remember the logic behind all these values any more, just hitting
this with a stick.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
They're qcow2 images, so this is more correct, and will make
os-autoinst's new backing format autodetection work correctly.
We make the `check` function rename existing images, for
convenience.
NOTE: this requires a matching change to the templates in
os-autoinst, and you will want to run the check function to
rename all existing images to avoid wasting a ton of time
recreating them.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Seems like 2G isn't enough in some cases, it's why the F34 server
and support image builds have been failing.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We want to run the desktop upgrade tests on aarch64; to do that,
we need the required base images to be built. We also need to
do the `console=tty0 quiet` boot args for the desktopencrypt
image so the decrypt prompt is visible on boot; to handle this,
we extend the existing hack for using a release-specific ks
to be more generic and allow for a more specific kickstart by
arch, release or both.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bit ugly but offhand can't think of a better way. We
are dropping plasma-workspace-wayland from the F33 KDE image to
try and avoid it using Plasma-on-Wayland as the default session,
which is #1960458.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The bug where the bootsplash doesn't always clear is really
playing havoc with F34 tests right now, and dealing with it by
workaround needles isn't going so well. I'm hoping installing a
real Plymouth theme might help, and in a quick trial run on lab
it seems to, so let's try this. The bug is still a bug, but it's
no good to us for update tests to randomly fail on it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
"current" is just a synonym for "-1" but made the code more
complex. Let's ditch it and just note in a comment that -1 is
CURRREL and -2 is PREVREL. We need minimal-uefi for aarch64 as
install_blivet_btrfs_preserve_home_uefi uses it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This PR adds the post-installation section that adds a file
in the /home space, which then can be checked by a `preserve_home`
post-installation test and prove that it was possible to
preserve home on btrfs layouts.
