createhdds/support.ks

bootloader --location=mbr
network --bootproto=dhcp
url --url="https://download.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/"
#repo --name="epel" --baseurl="http://mirrors.kernel.org/fedora-epel/8/Everything/x86_64/"
# use epel to keep scsi-target-utils instead of targetcli
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
clearpart --all
autopart
rootpw weakpassword
poweroff

%packages
@core
scsi-target-utils
nfs-utils
dnsmasq
%end
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`
switch kickstart url to rocky source 2021-12-04 08:19:23 +00:00			`url --url="https://download.rockylinux.org/pub/rocky/8/BaseOS/x86_64/os/"`
			`#repo --name="epel" --baseurl="http://mirrors.kernel.org/fedora-epel/8/Everything/x86_64/"`
			`# use epel to keep scsi-target-utils instead of targetcli`
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			`lang en_US.UTF-8`
			`keyboard us`
			`timezone --utc America/New_York`
			`clearpart --all`
			`autopart`
			`rootpw weakpassword`
			`poweroff`

			`%packages`
			`@core`
			`scsi-target-utils`
			`nfs-utils`
			`dnsmasq`
			`%end`