[Pkg-sysvinit-devel] Bug#637087: Please set FSCKFIX=yes by default

[Roger Leigh]

On Thu, Feb 28, 2013 at 01:30:50PM +0000, Philip Hands wrote:
> I just upgraded a wheezy box, and was again asked if I wanted to keep
> my local FSCKFIX=yes option, or return to the (stupid) default.
> 
> That made me scratch my head, thinking:  wasn't there a bug about that?

Yes.  The reason for the prompt is probably the conversion of
rcS to a conffile, which was done partly to permit changing of
this (and other) defaults in the future.  I thought this was a
good idea for the medium term, but I've also got a lot of flak
about it for various reasons.

The current odd "only default to yes on arm arches" is not
ideal.  We should be using better criteria to make that
decision.

> On the other hand it seems that there's a wide consensus that, not only
> is it wrong as it is, but that it should be fixed -- DC11 was not the
> first time this subject has come up.

> The only concern raised in the bug itself was about fscking underlying
> media in a RAID.  This to me reads like an after-echo of a (long-ago
> fixed) bug in LVM, where pvscan could sometimes find one of the physical
> devices before its associated RAID device, and so bring up LVM only
> writing to one drive.

I raised this issue on #debian-devel a few times, and got
thoroughly roasted for even suggesting changing the default by
several people.  So I'm not sure of exactly what the consensus
is, or how grounded in reality the objections are at the
present time.  Personally, I'd be all for changing the default
if it's safe to do so.  And for new installs possibly even if
it's not safe, /if/ we can detect such situations and disable
it during installation (or even at runtime)--we could default
to "auto" and adjust the default if not configured.

> So, given the consensus for a fix, what needs to be done to actually
> make this happen, and is there any chance of it happening before the
> wheezy release?
> 
> I'd think that it would be OK to start with the new "yes" default for
> new installs, but might be argued that people that were upgrading should
> at least be warned of the change (not that most of them will know that
> they were suffering under the old default, and many of those that do
> know will get prompted because they've already set it to "yes" locally).
> 
> The fact that the /etc/default/rcS file is changing anyway, and so will
> prompt anyone who's already edited it, seems to make this a good time to
> fix this bug.
> 
> If it's deemed impossible for wheezy, what do we need to do so that it
> at least has a chance of being fixed for jessie.
> 
> Should it be reassigned to initscripts?  should the priority be raised?

I think it's unfortunately too late for wheezy, but certainly
on the cards for jessie.  I did try to get wider discussion on this
issue, but didn't change the default due to the very vocal objections
raised at the time.  I certainly would like to fix this properly,
perhaps after getting a concrete list of objections and trying to
address them if possible (and still valid).

We could
- alter FSCKFIX to be "auto" by default
- auto would itself default to "yes"
- auto would default to "no" if the system was found to be using
  RAID/LVM and/or was in a state which could be potentially
  dangerous.

The rules for this are entirely open for discussion.  Inputs for
deciding the default could be the absence of a console (i.e.
noninteractive) which is the current basis for the arm defaults
IIRC, though this isn't reliable to detect.  Any others?

As always, I'm happy for any better suggestions!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800