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).
Various things were being set in odd orders and not used right
later on, this is a general clean-up that solves that and makes
things a bit easier to read (I hope).
Whoops, that last commit just wasn't very good. We need to
re-open the libvirt connection and re-get the domain object,
and also we should catch errors while destroying and undefining
the domain...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This was just an oversight - we don't destroy and undefine the
'createhdds' domain on the path where the final retry to create
an image times out, we just wipe the temp file and exit. So we
leave a qemu process sitting around until createhdds runs again
(and, on openQA production, exhausting swap space).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The way this was done, when we ran `all` on a ppc host it wiped
all the x86_64 and i686 virt-install images, and when we ran
`all` on an x86_64 host it wiped all the ppc64 virt-install
images. Doing it this way avoids that.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
as today seems to be required to avoid createhdds to hang
on creation of disk_f25_minimal_2_ppc64le.img.tmp ...[13/22]
Trying to VNC connect, show anaconda menu stuck on
"Performing post-installation setup tasks"
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
