Re: Small tip proposal for headless systems boot resiliency

Le 31 d=E9c. 2013 =E0 00:59, Dave McGuire a =E9crit :

> On 12/30/2013 06:46 PM, Mathieu Lubrano wrote:
>> The headless systems, or boxes that may be far away are a pain to get
>> back online if stuck during the boot sequence... (embedded/headless
>> do not have IP-KVM or remote control).
>>=20
>>=20
>> * The point is : with a headless system you want it back online,
>> really. Even if it needs maintenance, you need a ssh or whatever to
>> get your hands dirty. So don't stop the boot sequence. If it's
>> damaged beyond basic/rescue usability, it makes no difference
>> anyway.
>=20
>  This is, to put it simply, very dangerous.
>=20
>  In fact it DOES make a difference, potentially a very large one.  If
> I've, say, put a NetBSD system in an industrial control environment
> (which is not an unlikely thing to do, and not even an unlikely thing
> for ME to do), and it's damaged so it's "partially" functional, I'd
> rather have it STOP COMPLETELY than, say, become confused and drive a
> gantry crane in the wrong direction.
>=20
>  If something like this is done, it should be a configurable option.

Right, it makes sense to be safe in embedded systems and stop right =
away. Even for large servers (DB) you want to stop and fall back to a =
shell and manual fsck.=20
But for many hosted systems, or headless systems you shouldn't stop the =
boot sequence for "minor" issues. Hands on operations may be avoided =
this way (think at colocation, VPS, old Servers and PCs revived with =
NetBSD...).

So like passing special arguments with fsck_flags, a "headless" flag or =
something like that in rc.conf, with a safe default setting (no change =
to the current behavior), seems fine to me.

I assumed it should be discussed from both "embedded" and "user" (like =
sysadmin) point of view, hence the cross-post...

>=20
>                -Dave
>=20
> --=20
> Dave McGuire, AK4HZ
> New Kensington, PA
>=20