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.
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.
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/ 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?
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.
The following script, which depends on python3-apt, should help:
#!/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.
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.
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:
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/
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.
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?
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).
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))
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.
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.
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.
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
I wonder if you can find something to measure or improve the situation?
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.