[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [SPAM] Re: Small tip proposal for headless systems boot resiliency
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.
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
>>> 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
>> 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.
Main Index |
Thread Index |