Re: Small tip proposal for headless systems boot resiliency

[Erik Berls <cyber%ono-sendai.com@localhost>]

Chiming in late on this:
Instead of just trying heroics or additional path to set up networking,
etc, how about a "booted_cleanly" that critical processes can depend on?
Then the current proposed scheme can blindly try to bring the system back
up, but anything critical can gate.


On Tue, Dec 31, 2013 at 1:03 PM, Christos Zoulas 
<christos%astron.com@localhost>wrote:

> In article <20131231185326.GA7267%netbsd.org@localhost>,
> David Holland  <dholland-tech%netbsd.org@localhost> wrote:
> >On Tue, Dec 31, 2013 at 07:24:40PM +0100, M wrote:
> > > Regarding filesystem issues, it seems fair to use rc.conf settings
> > > and some scripting rather than modifying fstab (it may be read and
> > > parsed by others). And it may help recovering for most common boot
> > > issues.
> >
> >Adding something to the options column of fstab (akin to the existing
> >"noauto") should not cause a problem in this regard, and it makes more
> >sense to put this setting there than tucked away somewhere else.
>
> Absolutely, what people are asking for is to change:
>
>         fs_spec fs_file fs_vfstype fs_mntops fs_freq fs_passno
>
> to:
>
>         fs_spec fs_file fs_vfstype fs_mntops fs_fsckops fs_freq fs_passno
>
> This could be implemented without too much hassle in many different ways.
> A hacky way would be to use a separator such as : to split between the
> mount and fsck options in fs_mntops and have both in the same string.
>
> Since fs_freq and fs_passno are just integers, we can detect old and
> new fstab files so we don't have to put fs_fsckops last.
>
> christos
>
>