I'm using some cheap soho router, but it is very limited in features and not supported anymore, so I want to change it for something better. I have some spare pcengines/apa board so I want to build small OPNsense-box, but I'm not sure if it can survive hard power-off (I mean not clean shutdown over web-interface, but simply pull the power cord off).
With my old crappy router I do not care about clean shutdown at all. I simply turn power off, and that's it. Maybe it is using some read-only fs? Anyway, it survives this hard treatment. What about OPNsense? What filesystem is it using? Can I simply power it off?
Just for comparison: openwrt is using ubifs/jffs2 overlayed over read-only squashfs, so it can easily survive hard reset. How is it with OPNsense? Don't I breake filesystem if I turn it off in hard way?
Yes, you can but no, you shouldn't pull the plug ;)
By default OPNsense uses UFS, but you can use ZFS if you really need to: https://forum.opnsense.org/index.php?topic=12267.0
The file system gets checked after a sudden power failure but repeated crashes is asking for trouble.
Bart...
You could set /var and /tmp to RAM. Then most write access is to memory and less problems with power loss.
Quote from: hbc on May 29, 2019, 01:23:03 PM
You could set /var and /tmp to RAM. Then most write access is to memory and less problems with power loss.
I don't think this is good advice. UFS corruptions can kill your kernel or system binaries with one unlucky unsolicited reboot.
Cheers,
Franco
Is there so many write access outside /var and /tmp?
For me it sounded, that he powers off by unplugging anyway. So a powerloss with using temp file systems is less likely to crash than a disk based one.
Does live system run config.xml import automatically? Then he could boot from USB stick into memory, auto import config from disk and everything is memory based. Every boot new system.
The classical way for UFS to shoot itself in the foot is metadata write lagging behind having newly written or partially rewritten files show a size of zero after a forced reboot. Sometimes this happens even on supposedly clean shutdowns, which is a bummer for reboot-after-upgrade scenarios and its ensuing aftermath.
/etc/tty being wiped to size zero was a classical annoyance because you wouldn't get your login prompt back to repair the system.
Another variety of corruption involves (partial?) corruption of file system data which can affect read-only data or files being lost.
Nowadays the firewall health check can give you a fair warning if the system comes back up, but if not there's no real way to recover within the scope of UFS other than an import+install to write a clean system back to the disk.
Cheers,
Franco