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.
This reverts commit 8f53b9f5f8.
similar revert already done since a while in os-autoinst-distri-fedora
"e020b87 Drop the pseries-4.0 workaround for ppc64le"
This is for
https://pagure.io/fedora-qa/os-autoinst-distri-fedora/issue/201 -
we're working around that by using the F32 image for now, but it
doesn't exist on aarch64 ATM. We'll have to remember to take
this out when that's fixed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Add a workaround repo to kde.ks to get the kde-settings that
will put F33 backgrounds in F33 images (hopefully). Remove an old
workaround repo from the desktop kickstarts that isn't needed
any more.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is causing us pain in the tests, so let's work around it
now rather than wait for the updates to go stable. Can remove
these once the updates are stable.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
2.0.0 went stable in F31, but it's kinda messed up, it provides
kde-settings, and when building this image, anaconda actually
prefers it over the 'real' kde-settings, which breaks the desktop
background among other things. 3.0.0 should fix it but it's still
in updates-testing, so let's forcibly exclude it for now.
We bumped it for the live image build update test, but I tweaked
that to use a separate scratch disk now, so the base image no
longer needs to be so big.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need this for upgrade tests now I fixed the upgrade test
scheduling so Rawhide upgrade tests run from Rawhide-1 and
Rawhide-2, not currrel and prevrel...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Some of the version config directives make it possible to wind
up with dupes - for instance, our config for the 'minimal' image
can result in multiple instances of VirtInstallImage for F31
appearing in the list, meaning we'll build the same image two
or more times in the same run. That's silly! Let's not do that.
Using a dict keyed on the release number and arch we wind up with
after interpreting the config file should avoid it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's only used for upgrade tests, and we don't test upgrading
from Branched, only from current stables.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is related to enabling update tests for KDE. While testing
that it transpired that the KDE disk image is missing various
stuff that is on the live image and systems installed from the
live image; this is because the kde-desktop-environment env
group doesn't by default include several groups and individual
packages that the live kickstart *does* include. So our current
disk image closely matches what you get if you do a network
install and pick the KDE env group and don't pick any option
groups, but that's not a very common thing to do, and it causes
problems for the tests (e.g. okular and firefox not being
there). I think it's reasonable to make the image resemble a
live install more closely; this is more convenient but I think
it's *also* more useful, as there are probably far more KDE
installs out there *with* these things than without them. More
KDE installs are probably done with the live than via network
install, and even KDE installs done via netinst may well have
these bits added subsequently.
Obviously, we bump the image version with this change, so we'll
need to update the scheduler and templates also.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
its correct type.
Previously, it was not possible to set the type of the partition via
the specific GUID. This commit adds support for adding the GUID into
the gtp_type of the partition description in hdds.json and this field
will be utilized in to code.
This commit adds support for boot options, that can be passed
from `hdds.json` to control the creation of the virtual
machines, such as enabling of EFI based machines, boot order
control, etc. It also adds EFI based machine to `hdds.json`
and adds a kickstart file for such machine.
We previously did a filter like the one for 'i686 on F31+' for
'ppc64 on F29+', only in a different place which was actually a
better place. That filter is now unneeded as F28 went EOL, so
drop it...but move the i686 F31+ filter into the same place, as
it's better done there than in create().
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This just isn't possible any more, we no longer produce all
the necessary bits to generate images for i686.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
