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>
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>
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>
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>
"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 reverts commit 8f53b9f5f8.
similar revert already done since a while in os-autoinst-distri-fedora
"e020b87 Drop the pseries-4.0 workaround for ppc64le"
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>
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>
This reverts commit 3f9cbd27d4.
I verified that related bug#1571860 is not present anymore on f29.
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
to avoid error like:
===
$~/createhdds/createhdds.py support
...
Traceback (most recent call last):
File "/root/createhdds/createhdds.py", line 821, in <module>
main()
File "/root/createhdds/createhdds.py", line 811, in main
args.func(args, hdds)
File "/root/createhdds/createhdds.py", line 701, in cli_image
img.create(args.textinst)
File "/root/createhdds/createhdds.py", line 291, in create
loctmp.format(fedoradir, str(self.release), variant, arch), "--name", "createhdds",
NameError: name 'variant' is not defined
===
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
Archive now has up to F27, we're not testing ppc64 any more, and
the old workaround is no longer needed.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
ppc64 (as opposed to ppc64le) was retired in Fedora 29. Tweaking
hdds.json to reflect this now is a bit awkward, so instead let's
leave it as-is, but add code to createhdds to not really include
a ppc64 image in the expected list if it's for F29 or later.
Once F28 goes EOL we can just drop all ppc64 from hdds.json and
lose this code.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
README was badly outdated, so give it a coat of paint. A person
trying to get up to speed on openQA was misled by the current
message into thinking something was wrong.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
...But also be careful not to treat them as 'unknown' either.
This avoids the ansible plays regenerating outdated images (we
try to avoid that and just have the cron job do it).
