# Root filesystem completely in RAM (only data mounts)

**URL:** https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904
**Category:** Development
**Created:** [May 13, 2020, 10:48pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904 "2020-05-13T22:48:33Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [May 13, 2020, 10:48pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/1 "2020-05-13T22:48:33Z")

</div>

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/mychanges.sb`]) 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: [https://www.slax.org/customize.php](https://www.slax.org/customize.php)

---

<div class="post-metadata">

### Author: ![Sunil](https://discuss.freedombox.org/user_avatar/discuss.freedombox.org/sunil/32/8_2.png) [@Sunil](https://discuss.freedombox.org/u/Sunil)
#### Post date: [May 14, 2020, 4:51pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/2 "2020-05-14T16:51:45Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [May 14, 2020, 6:54pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/3 "2020-05-14T18:54:59Z")

</div>

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

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [May 24, 2020, 10:19pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/4 "2020-05-24T22:19:36Z")

</div>

> [@Status NextCloud as App?](https://discuss.freedombox.org/t/status-nextcloud-as-app/894/22):
>
> Under **no circumstances** you should host it on the microSD! The syncing stresses the cards much so that you just have to wait for an fatal error that screws your system to hell.  
> Use `armbian-config` to move the **system** at once **to an usb-hdd** and **only boot from microSD**. And don’t forget a solution for **backup**.

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 [https://www.linux-live.org/](https://www.linux-live.org/) 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.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [June 7, 2020, 10:29am UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/5 "2020-06-07T10:29:09Z")

</div>

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](https://antixlinux.com) 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](https://download.tuxfamily.org/antix/docs-antiX-19/live-boot/persistence.html))

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?

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [June 7, 2020, 2:02pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/6 "2020-06-07T14:02:57Z")

</div>

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

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [June 12, 2020, 10:07pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/7 "2020-06-12T22:07:39Z")

</div>

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.

Nevertheless, 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. I didn’t find a minimal command line base .iso file, so it will first require uninstalling a lot of stuff.

EDIT:  
[debian - How do I remove and purge all packages installed by apt-get? - Stack Overflow](https://stackoverflow.com/questions/18189941/how-do-i-remove-and-purge-all-packages-installed-by-apt-get)

> The following script, which depends on `python3-apt`, should help:
> 
> ```auto
> #!/usr/bin/python3
> 
> import apt
> 
> cache = apt.cache.Cache()
> for package in cache:
> if (package.is_installed and
> package.candidate.priority not in ("required", "important")):
> print(package.name, end=" ")
> print()
> 
> ```

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

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [June 23, 2020, 8:56pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/8 "2020-06-23T20:56:56Z")

</div>

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. (Recipe at: [Evaluate providing F2FS images as well (#1905) · Issues · FreedomBox / FreedomBox · GitLab](https://salsa.debian.org/freedombox-team/freedombox/-/issues/1905) )

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

> Setting the journald’s [Storage=](https://www.freedesktop.org/software/systemd/man/journald.conf.html) 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:
> 
> ```auto
> [Journal]
> Storage=volatile
> 
> ```

---

<div class="post-metadata">

### Author: ![Sunil](https://discuss.freedombox.org/user_avatar/discuss.freedombox.org/sunil/32/8_2.png) [@Sunil](https://discuss.freedombox.org/u/Sunil)
#### Post date: [June 23, 2020, 9:14pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/9 "2020-06-23T21:14:43Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [February 27, 2021, 9:11pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/10 "2021-02-27T21:11:12Z")

</div>

Stumbled over a debian package to boot into a live system (likely also from sdcard).  
[https://packages.debian.org/buster/live-boot](https://packages.debian.org/buster/live-boot)

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [March 8, 2021, 2:19pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/11 "2021-03-08T14:19:47Z")

</div>

Um, the alioth links from the package are outdated, now the most current definite **“Debian Live Manual”** seems available in html here (salsa project links to them):  
[https://live-team.pages.debian.net/live-manual/](https://live-team.pages.debian.net/live-manual/)

It says the live-boot is designed to support unmodified stock debian packages (read “freedombox”) and provide persistence across reboots if there is a writable filesystem available in the system that is labeled `persistence`.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [March 24, 2021, 8:45am UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/12 "2021-03-24T08:45:05Z")

</div>

The antix and MX distros seemed hard to adjust for freedombox, that left live-boot package.

Other, possibly easier options to experiment, might be tools like system imager, remastersys, or refractasnapshot. But none seem part of the the debian packages either?

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [February 24, 2022, 3:14pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/13 "2022-02-24T15:14:14Z")

</div>

The Slax distribution that allows installing, running and maintaining stock Debian packages into RAM (from on-disk storage) has been upgraded to the current Debian stable (bullseye).

[https://www.slax.org](https://www.slax.org)

---

<div class="post-metadata">

### Author: ![Tido](https://discuss.freedombox.org/user_avatar/discuss.freedombox.org/tido/32/757_2.png) [@Tido](https://discuss.freedombox.org/u/Tido)
#### Post date: [February 24, 2022, 8:24pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/14 "2022-02-24T20:24:25Z")

</div>

What you want is to **reduce** writing to your SDcard, but you still want to be able to write on the SDcard I guess. Do you run PiHole, I heard this one writes a lot (or did in the past).  
I have two suggestion:  
Log2Ram and  
to set a time limit how often to write to the SDcard ( `commit=600` to flush data to the disk every 10 minutes (`/etc/fstab`))

> **[GitHub - azlux/log2ram: ramlog like for systemd (Put log into a ram folder)](https://github.com/azlux/log2ram)**
>
> ramlog like for systemd (Put log into a ram folder) - GitHub - azlux/log2ram: ramlog like for systemd (Put log into a ram folder)

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [February 24, 2022, 10:05pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/15 "2022-02-24T22:05:09Z")

</div>

I think sdcards are currently not suited at all to run freedombox on in a reliable way.

Log2ram or the above journalctl tweak don’t help much really.

> **[btrfs: excessive disk writes (amplification) (#2034) · Issues · FreedomBox /...](https://salsa.debian.org/freedombox-team/freedombox/-/issues/2034)**
>
> The idle writes to disk need to be reduced. (Long running precesses can be seen with iotop -a-\> and 2x left arrow key for sorting.)

The folder2ram.deb may be an option. Overlayfs does not seem to support saving changes back to disk, seems that’s why slax had to revert to compiling aufs into the kernel to make `savechanges` work anytime.

---

<div class="post-metadata">

### Author: ![Tido](https://discuss.freedombox.org/user_avatar/discuss.freedombox.org/tido/32/757_2.png) [@Tido](https://discuss.freedombox.org/u/Tido)
#### Post date: [February 25, 2022, 10:38pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/16 "2022-02-25T22:38:58Z")

</div>

Nick,  
This is a long issue.  
Is it really so terrible with brtfs or is it just a question of configuration?  
Have you heard about: fatrace - report system wide file access events. Detect what does wake up your harddisk - search for fatrace - I can only post 2 links.

Do you know armbian? There was a guy: TK who was really into performance and perfection. He took the time to go into details and find troubles some parts.  
Now this TK really liked btrfs. For example: [Some storage benchmarks on SBCs - Reviews, Tutorials, Hardware hacks - armbian forum](https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/)

The tipps I mention above are from armbian.

About the wear out of the SDcard, it is a long post, but if you start reading here it is not much, but quite into details: And besides that I really see no benefit : [Learning from DietPi! - Off-topic - armbian forum](https://forum.armbian.com/topic/6635-learning-from-dietpi/)

I wonder if you can find something to measure or improve the situation?

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [February 26, 2022, 11:41am UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/17 "2022-02-26T11:41:45Z")

</div>

> [@Tido](#):
>
> I wonder if you can find something to measure or improve the situation?

Guess, you could have found something mentioned for you even in the issue preview.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [February 26, 2022, 11:48am UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/18 "2022-02-26T11:48:46Z")

</div>

Your suggestion of possibly increasing the commit interval may be an option, I’m going to add it to the issue.

---

<div class="post-metadata">

### Author: ![Tido](https://discuss.freedombox.org/user_avatar/discuss.freedombox.org/tido/32/757_2.png) [@Tido](https://discuss.freedombox.org/u/Tido)
#### Post date: [February 27, 2022, 12:47pm UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/19 "2022-02-27T12:47:50Z")

</div>

> [@NickA](#):
>
> the commit interval may be an option

on my RPi 2 I just added commit=600 and it looks like this in /etc/fstab:

```auto
admin@freedombox:~$ cat /etc/fstab 
UUID=-de1f-4f14-8f1f-b1682018d905 / btrfs defaults,commit=600 0 1
UUID=-18a6-4b0a-af19-c5e637eebf88 /boot ext2 errors=remount-ro 0 2
UUID=-C4E7 /boot/firmware vfat errors=remount-ro 0 2
UUID=-de1f-4f14-8f1f-b1682018d905	/.snapshots	btrfs	subvol=.snapshots	0 1

```

After changing, before reboot do a check of your fstab:

```auto
sudo findmnt --verify --verbose

```

I did a reboot, the device came up, but no longterm testing.

---

<div class="post-metadata">

### Author: ![NickA](https://discuss.freedombox.org/letter_avatar_proxy/v4/letter/n/3ab097/32.png) [@NickA](https://discuss.freedombox.org/u/NickA)
#### Post date: [March 2, 2022, 4:02am UTC](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904/20 "2022-03-02T04:02:36Z")

</div>

As added to the issue, I think a longer commit interval can only aggregate: folding fluctuating writes, and sum up changes to write larger chunks. However, it is not well suited to get user data written to disk quickly and reliably.

[Next page](https://discuss.freedombox.org/t/root-filesystem-completely-in-ram-only-data-mounts/904.md?page=2)
