switch from virt-builder to virt-install (T813)
Summary:
We've kinda been having too much trouble with virt-builder
lately, mainly SELinux related issues due to how it does image
customization. It also produces images that differ in notable
ways from what a 'typical' install would give. virt-install
solves both these problems, and also gives us more flexibility
for storage configuration and post-install customization should
we need them in future.
The change isn't really too drastic, and the design is similar:
instead of virt-builder commands files, each image type now has
a kickstart file where all its customizations can be done.
There's also a single extra image dict key, 'variant', which
specifies which install tree variant to use for running the
install. It defaults to 'Everything' (for F24+) and 'Server'
(for <F24, as Everything wasn't installable until F24) but we
set it to 'Server' for the server images and 'Workstation' for
the desktop images, so those installs will use the correct
variant install class.
We run the installs in VNC. You can do it with a serial console
and log the output, but then anaconda gets clever and changes
several things in the installed system based on the fact that
you did the install over a serial console: it twiddles with
the kernel args and doesn't set graphical.target as the default.
We don't want any of that mess, so we do a VNC install.
The 'size' value is just a number of gigabytes for virt-install
images (as that's how the virt-install 'size' argument works).
This also drops some unused 32-bit images (we don't do 32-bit
KDE or Server upgrade tests, so there's no need to build those
images).
Test Plan:
Re-generate all affected images and re-run all tests
that use them, make sure they work. I am doing this on staging
at present. Note: this would render D911 unnecessary.
Reviewers: garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D917
2016-07-04 16:29:25 +00:00
|
|
|
bootloader --location=mbr
|
|
|
|
|
network --bootproto=dhcp
|
|
|
|
|
url --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch
|
|
|
|
|
repo --name=updates --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch
|
|
|
|
|
lang en_US.UTF-8
|
|
|
|
|
keyboard us
|
|
|
|
|
timezone --utc America/New_York
|
|
|
|
|
clearpart --all
|
|
|
|
|
autopart
|
|
|
|
|
rootpw --plaintext weakpassword
|
2022-07-13 01:13:36 +00:00
|
|
|
user --name=test --password=weakpassword --plaintext --groups wheel
|
2017-10-21 00:37:38 +00:00
|
|
|
firstboot --enable
|
switch from virt-builder to virt-install (T813)
Summary:
We've kinda been having too much trouble with virt-builder
lately, mainly SELinux related issues due to how it does image
customization. It also produces images that differ in notable
ways from what a 'typical' install would give. virt-install
solves both these problems, and also gives us more flexibility
for storage configuration and post-install customization should
we need them in future.
The change isn't really too drastic, and the design is similar:
instead of virt-builder commands files, each image type now has
a kickstart file where all its customizations can be done.
There's also a single extra image dict key, 'variant', which
specifies which install tree variant to use for running the
install. It defaults to 'Everything' (for F24+) and 'Server'
(for <F24, as Everything wasn't installable until F24) but we
set it to 'Server' for the server images and 'Workstation' for
the desktop images, so those installs will use the correct
variant install class.
We run the installs in VNC. You can do it with a serial console
and log the output, but then anaconda gets clever and changes
several things in the installed system based on the fact that
you did the install over a serial console: it twiddles with
the kernel args and doesn't set graphical.target as the default.
We don't want any of that mess, so we do a VNC install.
The 'size' value is just a number of gigabytes for virt-install
images (as that's how the virt-install 'size' argument works).
This also drops some unused 32-bit images (we don't do 32-bit
KDE or Server upgrade tests, so there's no need to build those
images).
Test Plan:
Re-generate all affected images and re-run all tests
that use them, make sure they work. I am doing this on staging
at present. Note: this would render D911 unnecessary.
Reviewers: garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D917
2016-07-04 16:29:25 +00:00
|
|
|
poweroff
|
|
|
|
|
|
|
|
|
|
%packages
|
|
|
|
|
@^workstation-product-environment
|
2020-05-09 16:14:46 +00:00
|
|
|
-selinux-policy-minimum
|
2023-02-01 23:12:20 +00:00
|
|
|
# FIXME: this is a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=2158891
|
|
|
|
|
# can be dropped when https://bodhi.fedoraproject.org/updates/FEDORA-2023-4021d4c044
|
|
|
|
|
# is stable
|
|
|
|
|
cracklib-dicts
|
switch from virt-builder to virt-install (T813)
Summary:
We've kinda been having too much trouble with virt-builder
lately, mainly SELinux related issues due to how it does image
customization. It also produces images that differ in notable
ways from what a 'typical' install would give. virt-install
solves both these problems, and also gives us more flexibility
for storage configuration and post-install customization should
we need them in future.
The change isn't really too drastic, and the design is similar:
instead of virt-builder commands files, each image type now has
a kickstart file where all its customizations can be done.
There's also a single extra image dict key, 'variant', which
specifies which install tree variant to use for running the
install. It defaults to 'Everything' (for F24+) and 'Server'
(for <F24, as Everything wasn't installable until F24) but we
set it to 'Server' for the server images and 'Workstation' for
the desktop images, so those installs will use the correct
variant install class.
We run the installs in VNC. You can do it with a serial console
and log the output, but then anaconda gets clever and changes
several things in the installed system based on the fact that
you did the install over a serial console: it twiddles with
the kernel args and doesn't set graphical.target as the default.
We don't want any of that mess, so we do a VNC install.
The 'size' value is just a number of gigabytes for virt-install
images (as that's how the virt-install 'size' argument works).
This also drops some unused 32-bit images (we don't do 32-bit
KDE or Server upgrade tests, so there's no need to build those
images).
Test Plan:
Re-generate all affected images and re-run all tests
that use them, make sure they work. I am doing this on staging
at present. Note: this would render D911 unnecessary.
Reviewers: garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D917
2016-07-04 16:29:25 +00:00
|
|
|
%end
|
2020-12-04 14:04:29 +00:00
|
|
|
|
|
|
|
|
%post
|
2022-07-15 00:10:30 +00:00
|
|
|
authselect enable-feature with-fingerprint
|
2020-12-04 14:04:29 +00:00
|
|
|
touch $INSTALL_ROOT/home/home_preserved
|
|
|
|
|
%end
|
