Prevent maas from changing kernel in the user supplied image

Users
1

Pain point: Maas during the deployment process installs a newer kernel than what we baked into our images, how can this be turned off??

I currently have a hacky script that runs at the end of the install to pretty much undo what maas is doing but it wastes a good 10-15 minutes per machine (because our image has a custom version of ZFS baked into it and changing the kernel by maas forces DKMS to rebuild it which is time consuming)

2

@dandruczyk, i don’t have all your answers, but i wouldn’t mind hearing (and understanding) all your issues and questions at once, in the context of what you’re doing.

by way of reference, see this post. if you want, you can sign up there for a Thursday slot, so i can understand what you’re doing and what your needs are for MAAS. no promises, as i’m only one of the roadmap influencers, but at least i’m asking.

3

Here’s the case: Our corporate policy says we need to patch machines on a cadence and keep them at set levels until the next patch cycle. I build the custom images for maas on this cadence with set levels of packages and kernel combinations, So when maas pulls the very latest kernel as part of the deployment, it forces me to write scripts that roll that back out wasting time on every machine.

This is compounded by the fact that some of our images have a very specific version of ZFS integrated with them, and when maas installs the kernel it wants, it causes DKMS to rebuild ZFS for that unwanted kernel (5-8+ minutes), and then the cleanup script pulls it out which triggers dkms to run again (another 5-8+ min delay)

What would solve this: When uploading an image, Being able to specify the kernel by it’s version and/or package name (i.e. 5.4.0-72-generic), versus, GA, HWE or EDGE, which installs the latest of either of those which breaks our requirements and greatly slows down the imaging process.

4

would you please share how you run script at the end of installation process?

5

Config: Maas 2.9.2 installed via snap
i do the following:
replace /var/snap/maas/current/preseeds/curtin_userdata_custom with one that has a few extra commands, one that fetches a tarball of scripts to run and another that extracts and runs those scripts and a third that cleans up
cat curtin_userdata_custom
#cloud-config
debconf_selections:
maas: |
{{for line in str(curtin_preseed).splitlines()}}
{{line}}
{{endfor}}

late_commands:
  01-maas: [wget, '--no-proxy', '{{node_disable_pxe_url}}', '--post-data', '{{node_disable_pxe_data}}', '-O', '/dev/null']
  02-fetch_preseed_scripts: ['curtin', 'in-target', '--', 'wget', '--no-proxy', 'https://<SOME_HTTPS_FILESERVER>/preseed/scripts/preseed_scripts.tar', '-P', '/root']
  03-run_preseed_scripts: ['curtin', 'in-target', '--', 'sh', '-c', 'cd /root ; tar xvf preseed_scripts.tar ; cd preseed ; for script in `ls *.sh` ; do ./${script} ; done 2>&1 |tee >/root/preseed_done_on_$(date +%Y%m%d-%H%M%S).log']
  04-cleanup_preseed: ['curtin', 'in-target', '--', 'sh', '-c', 'cd /root ; rm -rf preseed_scripts.tar preseed']

Those scripts are in a git repo that has a CI/CD job that tars them up and drops them onto the fileserver that all nodes being deployed can reach. The scripts have logic that matches based on simple criteria (hostname, domain name, kernel version, etc) that make whatever changes are needed.

These scripts run at the “end” of deployment within the target flesystem of the machine, prior to it rebooting, so they have 100% access to the system to make needed changes. It’s a hacky (IMHO) way to get around something that should be a feature (being able ot specify the EXACT kernel version, or class (hwe, edge, generic) that I want within maas.

1 Like
6

@dandruczyk, if you didn’t already add a feature request to “Features,” please do so. worth getting it in the list. and thanks a bunch for explaining your workaround. i feel like i have a few “tips, tricks, and traps” to catch up on ATM.

7