Read only rootfs


I’d like to use clear linux to develop something like a kiosk application on the Intel NUC platform. I’ve seen the live images use an overlayfs in a way that would suit my needs to make the rootfs read only.

So now I want to create my own variation of this. It looks like the live images somehow incorporate the file
/usr/share/clr-installer/iso_templates initrd_init_template that does the mount into their initrd. Can somehow explain how this special config ends up in the live image or point me to the command line that is used to create the image? There seems to be going on more than just using the yaml file for creating an image. What am I missing here?

Mounting rootfs has to be done earlier in the process than other mounts. This stackoverflow thread discusses the special considerations with using overlayfs for rootfs in a lot of detail:

You can look at the content of /boot and kernel cmdline from the live image to see the order the images get loaded in.

The Clear Linux installer mounts the rootfs with mounts a SquashFS for compressed readonly parts and then puts an overlayfs onto in ram/tmpfs for the writeable/disposable parts. Paging @mhorn to double check me.


Also new with systemd 242 is the ability for booting the system where the root file-system is setup as an OverlayFS mount with a root-only root directory with a writable TMPFS. In other words, the underlying root device is not modified albeit all changes lost at reboot. This behavior can be started with the systemd.volatile=overlay kernel command-line parameter. Systemd-nspawn also now supports this volatile overlay mode.

dracut rootovl


@Lucapz thank you for hinting me at those.

@puneetse Yes I have seen the squashfs and the stackexchange article. What was unclear to me is how the initrd of the live installer gets modified to include the mount command that causes this special mount setup. It turns out there are some things hardcoded to produce a special initrd when using the --iso option with clr-install. So that doesn’t help me much.

I have tried using the command line option by doing this
mkdir /etc/kernel
touch /etc/kernel/cmdline
echo “systemd.volatile=overlay” > /etc/kernel/cmdline
clr-boot-manager update

That configures the command line but it does not enable the overlay mount behaviour. Do I need to recreate the initrd? I am fairly new to dracut and modifying init systems in general. I am reading about it, but I already have some questions about how things are put together in clr-linux.

I am using the bootloader bundle and I have looked through its packages but I can’t really see how it all works together to boot my system. In particular I fail to understand how the bootloader is getting its initrd.

Can someone point me in the right direction here?

Ok I now found out that the contents of “/usr/lib/initrd.d/” will get copied to the boot partition and be appended as initrd parameters to the kernel command line by configuring some bootloader config file.

When using dracut to generate an image and use above mechanism to use the generated initramfs during boot then my system won’t boot anymore. The generated initramfs also appears to only contain a few kernel modules.

Am I understanding something wrong there?

I stumbled across the bootloader-extras bundle which seems to include some pre-built initramfs that uses systemd, is this maybe a starting point?

@puneetse You are correct in how the Installer ISO functions.

@hgdahmen The installer source is in GitHub here:

If you look in the isoutils folder, there is a good readme that explains how our ISO is created:

@mhorn I have already seen the relevant code as explained in my above answer. Sadly this doesn’t help me, because after checking the code I am still no wiser on how to modify a default Clear Linux install to use an initrd and exhibit the same behaviour and keep it after kernel updates and survive other things that swupd triggers.

There I won’t be able to help you. We create a new ISO image for each release.
Something like a Kiosk probably needs to be more static than a rolling update OS.