On 6/27/20 10:57 AM, Stuart Henderson wrote:
On 2020-06-26, Marko Cupać <marko.cu...@mimar.rs> wrote:
On 2020-06-24, Aaron Mason <simplersolut...@gmail.com> wrote:
Auto filesystem repair is bad juju.
On 2020-06-25 11:17, Stuart Henderson wrote:
Nonsense. For many, the possible downsides of automatically running
fsck -y are much less a problem than the downsides of *not* running it.
Some time ago I wrote here on misc@ about read-only setup, where I
intended to modify rc(8) in order to be able to relink kernel before
mounting filesystems read-only, and - if I remember correctly - I was
warned never to modify rc(8) directly as it's considered as part of base
system, and I should only affect it with rc.local, which I did.
Is there a way to run fsck -y automatically without modifying rc(8)? Is
modifying rc(8) now supported?
No, you still need to modify rc to do that, so you need to remember to
reinstate it after updating. It would be nice if that wasn't needed but
diffs to make it configurable have never been approved.
20 years or so I worked on a network appliance based on FreeBSD.
It was required to come up after power failures no matter what.
We thought that this was the simplest way to harden the
system enough for our requirements:
We separated the boot environment from the runtime environment.
The initial root filesystem was never writable except during updates.
It was populated with the absolute minimumnecessary for
the system to come up capable of calling home.
During the transition to normal operation filesystems
containing the usual files were mounted over it
making it invisible and inaccessible.
The runtime filesystems could fail fsck during boot and the system could
be remotely repaired.
They could be refreshed via newfs and tarballs during boot if desired.
best,
Geoff Steckel
