Attempting to use systemd.volatile=yes

I am new to Fedora (and indeed not an experienced Linux user). I am trying to get Fedora running such that it will be able to work on a read-only device (during development, we can switch whether it’s read-only or not).

I installed Fedora Workstation 39, and did basic configuration. At the moment this is on a VM, but will be on a physical machine once I get that working - but basically there’s a single (writeable) hard drive. Everything installs fine, I can boot and do all the normal stuff.

I then used grubby to try to add read-only:
grubby --args=“systemd.volatile=yes” --update-kernel DEFAULT

But then it won’t boot - I just get a spinning wheel forever if I try to boot.

  • Is there anything else I need to do to configure Fedora Workstation 39?
  • Are there any other editions or versions (even unsupported ones) which would work (I looked into Silverblue, but the issue there is the need to switch between ro and rw - whereas that appears to be ONLY ro)?

I did check that systemd.volatile appears to be available as a service - which it does.

Resources I was using:
Working with the GRUB 2 Boot Loader :: Fedora Docs (

systemd-volatile-root(8) — Arch manual pages (

Have you removed rhgb and quiet from the kernel command line so that you can see where the system hangs?
You may also want to turn on systemd debug logging in the kernel commanf line. See How to debug systemd problems :: Fedora Docs for the details.

If that does not lead you to fix the problem then you might want to start with a simpler system. For example install Fedora Minimal and see if you can get it to boot how you want.

When you use systemd.volatile=yes how are you setting up /etc and /var?
I’ve not used this feature and I’m not sure how you setup the boot state of /etc and /var.
Is it something you have to do with systemd-tmpfiles service?

Thank you for the reply.

I’m definitely going to try out removing those, and adding systemd debug logging.

Is Fedora Minimal an official version?

As for /etc and /var, the impression I got from the documentation was that it would handle creating those in RAM - but I will have a look at systemd-tmpfiles to check if that might be required.

it’s bare bones fedora, you can use it to start from a very basic build and work your way up.

I use it to build images of software I test and mount them in containers. But you can literally install it and add the groups you need.

I think it would be wise for you to build the image in the way you want like you are doing in a VM, but look into building it with podman . Since you are eventually going to deploy this image, which gives you the advantage of customization and security features you want with a good upgrade path, since you control the image.
Have a look at this from the Docs : Live ISO and PXE image reference :: Fedora Docs

Ah - I guess this is where I mention that I’m running on Intel.

So I’ve managed to see the boot log - and the issue is (currently) happening when it tries to run auditd.service. I have tried "mask"ing that service, so it can’t run - but it’s still trying to at boot.

I will have a look now, but if anyone can tell me how to prevent boot from trying to start that, it would help me out.

Did you rebuild the initrd after making that change? I suspect auditd is started up in there.

Remember that the code in the initrd runs first then there is a switch to the root file system and more services start.

I did this time - but it still fails once I set readonly to true. What’s interesting (to me - there may be an obvious reason for this) is that after I disabled auditd.service, and rebuilt initrd, I found no trace of “auditd” in the boot log - it isn’t until I set systemd.volatile to true that it fails.

I think tomorrow I will re-enable auditd.service, and look at the rules instead. Perhaps it’s trying to write to a folder which no longer exists because of the changes caused by volatile being true.