Re: [SPAM] Re: Small tip proposal for headless systems boot resiliency

[mathieu%lubrano.at@localhost]

Hi Erik,

whatever brings a headless or remote system online look good to me. In a safe 
fashion, of course.
Plus, your proposal avoid editing the fstab file.

Bye,
Mathieu Lubrano.

3 mars 2014 03:06 "Erik Berls"  a écrit: 

> 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 wrote:
> 
> 
>> In article ,
>> David Holland   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
>> 
>