How to customise images

Errors or typos? Topics missing? Hard to read? Let us know.

This section explains how to build tailored solutions for your infrastructure:

  • Build custom images: Build images that match your specifications. Utilise our suite of tools to create an environment that meets your needs.

  • Build an Ubuntu image: Embrace the power of open-source with a custom Ubuntu image. Optimise your system for performance, security, or development – the choice is yours.

  • Build a RHEL 7 image: Stability meets customisation. Create a Red Hat Enterprise Linux 7 image that brings the robustness of enterprise-grade Linux to your tailored requirements.

  • Build a RHEL 8 image: Leverage the latest in system stability and innovation with a custom Red Hat Enterprise Linux 8 image. Ensure your infrastructure is ready for tomorrow’s challenges.

  • Build a CentOS 7 image: Enjoy the reliability of a community-driven enterprise platform. Customize a CentOS 7 image for consistency and performance in your network.

  • Build an ESXi image: Virtualise your environment with a custom ESXi image. Create a streamlined virtual machine platform that integrates seamlessly with your hardware and software ecosystem.

  • Build a Windows image: Combine the familiarity of Windows with the precision of custom configuration. Design a Windows image that aligns with your business processes and user requirements.

I believe that the example in “How to create other kinds of custom images” is incorrect, as there is no base_name specification and the name doesn’t have a “/” in in to denote the type of image.

After struggling with this issue for a little while, I submitted a bug, and I’ve posted changes to your document based on the answers received in that process.

There may be more edits required, however…

Thanks

~~ Charles

thanks! crowd-sourced doc is my favorite. lmk what other changes you become aware of, or just dive in.

looking to clarify a few things here. in this section about custom ubuntu images, it mentions

MAAS uses the kernel, initramfs, and SquashFS to perform network booting which allows commissioning, testing, and deployments. When deploying Ubuntu MAAS uses the same version of Ubuntu to network boot into and perform the deployment. This ensures there are no compatibility issues. Other operating systems use the Ubuntu version selected for the ephemeral environment for deployment.

Currently MAAS only allows custom images to be loaded as a single TGZ or DD.GZ, there is no way to upload a kernel, initrd, and rootfs as separate files. Even if MAAS was modified to allow the kernel, initrd, and rootfs as separate files MAAS requires cloud-initramfs-copymods and cloud-initramfs-rooturl to be included in the initrd. It is difficult for MAAS to detect if these scripts are missing and even harder for users to debug if they are missing.

my questions are:

  1. does this kernel/boot situation only apply to custom ubuntu images? does the same apply for custom centos/rhel/rocky images? does maas install the kernel, etc. that is used in the ubuntu ephemeral environment when deploying rhel like OSes?
  2. do we only need the root filesystem when building custom images with packer? the rocky8 build calls the default scripts in the root level of the repo. the tar-root script only mounts the root volume. but in the ubuntu packer build, you mount /boot/efi. do custom rocky builds also need this partition mounted to produce a working system?
  3. does the efi or boot partition need to be provisioned at the very start of the disk, like in the first 2048 sectors or so, or does that not matter?

what we’re seeing at the moment is maas laying down partitions but no viable grub config gets installed, causing failed deploys for rocky 8 images. i believe the same happened for default ubuntu provisioning with no special partitioning, as well.

answer to 1 is, i believe, yes. 2 and 3, i dunno, but i’ll ask someone.

1 Like

related to this, there’s a chunk that deals with xfs in the centos 7 curtin preseed sample.

is this still required, and if i want to use it with a custom image, is there another attribute to use instead of release? it looks like for custom images, release is set to nothing.

what maas variables are available to use for logic here? or maybe i’m overthinking it and should just omit that part, since it doesn’t apply.

it’s never bad to ask questions, @rockpapergoat! overthinking usually doesn’t apply to networking and operating system images, tbh. let me see if i can engage the MAAS custom image expert this morning.

  1. No, when deploying a custom image MAAS netboots the machine using a stock Ubuntu image for the ephemeral system, then it installs to the disk whatever bootloader/kernel is in the custom image.
  2. For TGZ images (like CentOS, Rocky and other RHEL-flavors), you usually don’t need the EFI partition contents (only the mountpoint) in the custom image. During installation Curtin is going to call dnf/yum in the target system to install and configure grub, to copy files to the EFI partition and to rebuild the initramfs. (I’m going to check why the Ubuntu template mounts this partition, it might be a leftover from the development)
  3. The EFI system partition (ESP) can be anywhere in the disk, but it’s a common practice to put it in the very start of the disk to avoid moving it in case you need to repartition the disk later. It must use FAT32 as filesystem, and it’s also common practice to make it at least 512MB.

It comes down to whether your custom image is affected by the issue that wrapper fixes. If your image is based on CentOS 7 and you plan to use XFS in a system deployed with it, then yes, you need a preseed similar to this. There’s no need to test for the release, the preseed file will only match your image (you should name it curtin_userdata_custom_amd64_$IMAGENAME).

1 Like

Hey! The section Upload the RHEL8 image to MAAS has an incorrect command. The command is missing the \ at the end of the first line.