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>
We need minimal to be 18GB now, because we're booting from it for
the Workstation live image build test. Not doing a version bump
as they turn out to be a bit of a pain to deal with, I should
enhance that somehow.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
We need it bigger for the new 'update installer image' test,
and when changing it we must bump its version.
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>
Rawhide tests are failing as there isn't enough disk space in
this image to copy the whole Server DVD...
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>
This ensures that gnome-initial-setup will run in user mode on
first login as 'test' user for F26+, as it did for <=F25 and as
the tests expected (we can now remove the workaround I added
because this stopped happening with F26). Bump the image version
so the images get rebuilt.
...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>
Assumption createhdds executed on a PowerPC ppc64le host
to create the PowerPC specific images.
Detect current CPU arch of host machine to create virt-install images
only for supported architectures. (hardcoded lists)
hdds.json specific changes for PowerPC
* no desktop or kde images
Signed-off-by: Michel Normand <normand@linux.vnet.ibm.com>
'stable' means 'all current stable releases', and is used for
desktop and server as we need to ensure we have those images
available for all stable releases (including the '-3' release
while it's not EOL) for update testing. (Currently, F24 update
tests are all failing as the images are missing).
'current' means 'the current stable release' - it's the same as
'-1', but just easier to understand. It's used for support.
It seems like the installer images (in os/images) for the F26
Workstation tree somehow come from the OStree installer compose
rather than the network installer compose; install.img and
boot.iso are far larger than they should be, and match the size
of the OStree installer .iso . So instead of using those images
and bumping up the memory size to 4GiB, use the Everything tree
for F26 Workstation image builds and go back to 2GiB.
The updates.img is broken with current F26, and Radek claims the
bug is fixed. Let's see. Unfortunately I don't remember what I
put in the updates.img, so if I have to recreate it things could
get fun...
