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

Philip Hands phil at hands.com
Thu Feb 28 13:30:50 UTC 2013


Package: initscripts
Version: 2.88dsf-41
Followup-For: Bug #637087

Hi,

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?

The bug is against sysvinit, while it might be thought that it should be
against initscripts (given that's what owns /etc/default/rcS) but it's
all the same thing really -- that does make it hard to discover that
this is an already reported problem (I only found it because I knew I'd
already commented on the bug, so kept looking).

It's also only wishlist, which probably means that there's always
something more improtant on the team's TODO lists.

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.

If we imagine that there is still some way of getting oneself into a
situation where one might be fscking half a RAID1, it seems to me that
the fsck -a is going to be pretty unhelpful anyway, so the -y won't
actually make things much worse, and the misconfiguration that's
allowing that device confusion to happen is likely to kill the system
long before an fsck -y was actually going to happen (I got bitten by the
old LVM bug -- it time-warped the server back about a year when the
RAID resynced, of course copying bad data over good)

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?

It seems a shame to leave something so simple unfixed because of
inertia, or perhaps because everyone in the team thinks someone else is
better placed to make the final decision.

So, if you have a good reason for not fixing this bug, please speak up.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]    http://www.hands.com/
|-|  HANDS.COM Ltd.                    http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND



More information about the Pkg-sysvinit-devel mailing list