On 6/27/20 10:57 AM, Stuart Henderson wrote:
> On 2020-06-26, Marko Cupać <marko.cupac@mimar.rs> wrote:
>>>> On 2020-06-24, Aaron Mason <simplersolution@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
No comments:
Post a Comment