We're moving most tests from BIOS to UEFI boot. The backing
images need to be moved accordingly. Instead of a sole UEFI
minimal image, we now have a sole BIOS minimal image.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Well, the longer timeout isn't really helping. The aarch64 builds
just fail a lot and I don't really know why. Drop it to 4500, as
I really did see it take 4000 seconds on one successful manual
attempt...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I think aarch64 desktop images are often failing to build because
it takes longer than the timeout, so let's bump it a bit.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Inexplicably, the grub issue has somehow started affecting F39
server images. Even though neither grub2 nor xfsprogs changed
at all in F39. I can't explain it, but it's nearly midnight and
I don't want to wake up to a wall of failed tests, so we're
trying this. The repo has a build of grub2 with the patch put
back, just like in Rawhide.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
All tests that use the Server base image are failing on Rawhide
now because of 2259266. This should regen the image using a side
repo with a grub2 build with the required patch put back in and
hopefully solve the problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
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>
