createhdds/server.ks

bootloader --location=mbr
network --bootproto=dhcp
url --url="https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/"
lang en_US.UTF-8
keyboard us
timezone --utc America/New_York
clearpart --all
autopart
rootpw weakpassword
user --name=test --password=weakpassword --plaintext
poweroff
text

%packages
@^server-product-environment
plymouth-system-theme
%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`
feat: add temporary support for Rocky Linux 9 (#9) 2022-08-16 14:31:01 +00:00			`url --url="https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/"`
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`
			`user --name=test --password=weakpassword --plaintext`
			`poweroff`
Clean up 8.7 Beta, use text installation for kickstarts for lower memory and faster installation. (#13) 2023-01-06 00:05:21 +00:00			`text`
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
			`%packages`
			`@^server-product-environment`
Add plymouth-system-theme to server.ks (workaround #1933378) The bug where the bootsplash doesn't always clear is really playing havoc with F34 tests right now, and dealing with it by workaround needles isn't going so well. I'm hoping installing a real Plymouth theme might help, and in a quick trial run on lab it seems to, so let's try this. The bug is still a bug, but it's no good to us for update tests to randomly fail on it. Signed-off-by: Adam Williamson <awilliam@redhat.com> 2021-03-02 19:59:51 +00:00			`plymouth-system-theme`
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`