Root filesystem completely in RAM (only data mounts)

Unfortunately, I have to confirm that sdcards and flash storage fail (wasn’t the first time), so I looked if the root filesystem could be run completely from RAM in a satisfying a way.

“toram” seems to be a valid boot parameter but only valid for install media and does not support any persistence.

A while ago I came across the slax live distro which allows packages to nicely run in ram.

Now, it’s got a completely rewritten system to boot, install, and configure (now Debian !) packages into ram, and persist everything back into .sb “slax bundle” files. These files (created with savechanges [/alternative/place/for/]) can then get selectively loaded and unloaded into ram, directly on the next boot, or during runtime.

It struck me as the most advanced versatile ram system I had seen, so would like to ask what others think about running from ram for speed and wear-less system operation.

A how-to-use walk through and technical info is available here:

1 Like

Making a read-only filesystem writable with a overlay mount should be straight forward enough. However, Flushing to changes disk seems like an explicit step in this system. This may not suite FreedomBox well where database will be updated with the expectations that changes will be synced to the disk immediately.

Which database do you mean? plinth? It could maybe trigger to save the changes after a package install or (re)configuration.

A HDD or SSD might not be available in all cases. The (arm) flash images could be read-only “live-images”, though, or using ramlog, and a separate data drive.

And with enough ram, of course copy the root filesystem into ram.

@sunil I’m still not sure what you were referring to above. But if you just meant all configuration and general user-data (web-app databases), then I’d picture all this to be mounted directly (reside on a writable data partition).
If it’s on SSD the logs can also reside on it, but otherwise it would be better to only save the logs to disk on log-rotation and shutdowns, to avoid disk spin-ups.

In the case of a crash, the user-data would be protected by the combined database and filesystem’s consistence guarantees.

While (ram) root filesystem changes are lost and get reset on the next boot.

I don’t know the exact reasons why ram systems don’t write changes to disk continuously, but only do it on some kind of savechanges requests. I guess it has to do with loosing the speed improvements and being able to guarantee a consistent state after crashes.

Your idea of just using an overlay fs with flushing support seems interesting, Unfortunately, I don’t know the reason why slax uses bundle files to save changes, either. Maybe to support adding and removing them for booting individually (e.g. for corresponding .deb packages or config changes). And to be able to add them up in a file that fits onto a FAT fs.

Revisiting, I’ve found slax also supports writing the changed files directly to a filesysem in a /slax/changes/ directory. And, that there exists which uses aufs3, and is from the same author as slax. So, he seems aware of overlay solutions and there are likely good reasons for the slax implementation.

Is this still supported: Can freedombox still run with sysvinit?

Problem: The stable release of Slax live system is based on Debian 9 (stretch), and too old for a reasonable Freedombox.

So, I found the Antix derivative distribution and it installs debian nicely into filesystem container files, i.e. a “frugal install” which can boot toram with persistence=root. (see Antix persistence options)

However, Antix is a minimal distro with support for old computers and installs Debian with sysvinit instead of systemd. Can freedombox still work with that?

If that helps, antix already came out with a sid release supporting runit.

For the record, it worked well to do a minimal Antix “frugal install” by booting its -net.iso with the kernel boot paramater frugal=root.

However, installing systemd-sysv seems to require removing some package pinning that has been put into place to keep antix free of systemd.

The sister distribution MX Linux uses the same live system with support for frugal=root from antix, and here the boot menu readily offers to boot with systemd. However, I didn’t find a minimal command line .iso file, so it will first require uninstalling a lot of stuff.

The freedombox package itself is available for installing in both distros, though.

Thanks to the nice surprise that a used board did actually have a tiny real M.2 SSD installed instead of a soldered eMMC, my current need has changed. It’s not to disable all writes anymore.

Still related, though:

  • Debian/testing is to support installing and booting F2FS, which might even extent the possible SDCard usage time (until it stops working) already sufficiently without completely disabling all writes, if the card is of good quality and large enough.

  • Thanks to @sunil! For letting me know how to disable log writes.
    It may still help somebody else:

Setting the journald’s Storage= option to volatile or none is a good way to ensure that logs are not written to disk. This should work for not just FreedomBox daemon, but also other daemons that log to journald or syslog. This change can be done by dropping a file /etc/systemd/journald.conf.d/my.conf with contents:

1 Like

Supporting other init systems other than systemd is a lot of work. Some of the features of systemd that we currently rely on:

  • Security sandboxing of various services.
  • Multiple (or custom) instances of services.
  • Easy fixes to default shipped init files.

systemd should run fine even on minimal distributions.