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

[Roger Leigh]

On Thu, Jun 07, 2012 at 02:27:40PM +0100, Philip Hands wrote:
> Roger Leigh <rleigh at codelibre.net> writes:
> > On Thu, Jun 07, 2012 at 09:13:35AM +0100, Philip Hands wrote:
> >> The only disadvantage I can think of with FSCKFIX=yes is the reduced
> >> likelihood of noticing (if you happen to understand the messages) to
> >> notice that inodes are being dropped into lost+found -- I would think
> >> that that could be handled by something that checks whether lost+found
> >> is empty and mails root about it, but that is hardly a blocker.
> >
> > That would be useful.  I think the main issue is Henrique's point that
> > it's not always safe to run fsck when using lvm/md on unreconstructed
> > arrays/volumes.  That could result in dataloss.  That said, such things
> > should normally be detectable: normally isn't there an md superblock
> > which should make the partition detectable as a part of a RAID set,
> > rather than a fsck-able filesystem?  Likewise with LVM PVs.
> 
> Hmm, perhaps.  How does this result in data loss?  If you're running one
> disk down on a RAID5 then surely the data is _supposed_ to be the same
> as what would be on the full set.
> 
> OK, so I've had disks that had duff blocks on them, and also had drives
> drop out of a RAID, such that the only valid copy of the data was on the
> drive that was dropped out, and if I'd blithely added it back in that
> would have overwritten the good data with the bad, but I've no idea how
> you'd expect to detect that automatically, and I think that there's very
> little chance of the vast majority of users surviving that with their
> data (and it was the result of a pretty odd sequence of events in my
> case) so if people suffer from that sort of thing then they've probably
> been doing something overly ambitious with their disk shuffling, and
> they can expect to restore from backups when that goes wrong.

Sure.  I think enabling it is probably the correct course of action.
It would be good if we could have some real-life examples of how this
could cause breakage--just to be on the safe side.  I'm not entirely
clear on how one could accidentally fsck something destructively by
accident.

One case I can think of is if the md array is partially degraded, and
you repair it.  But it should just rebuild itself when you add new
spares (it always has for me).  And LVM PVs are unlikely to be used
directly in fstab as device names.

Henrique, could you possibly clarify the specific scenarios you're
referring to here?

> > I guess it's a balance between whether we get more dataloss if FSCKFIX=
> > yes or no.
> 
> Could this be a candidate for a debconf question, with a default of yes
> and a low priority unless the right combination of md/lvm exists, in
> which case its priority could be promoted?

Potentially, but given that a system can change after initial install,
it could become incorrect.  If we do this, it's probably best to
do it automatically to override the default in the absence of any
user preference.  Shouldn't be too hard to check for the presence of
LVM or MD and set the internal default to "no".

> Of those that do see the prompt, and understand it, I doubt many do
> anything other than fsck -y on the relevant device anyway.

Yes.  I think the other consideration is that with the normal situation,
you have the option to stop, take a bit image of the disc, and then
fsck safe in the knowledge that you've got a clean backup if it screws
up.

> Of course, the fsck failure can be an early warning of disk failure,
> which setting FSCKFIX=yes may mask until it breaks properly.  On the
> other hand, these days smartmon probably covers that, along with mdadm
> sending emails when raids degrade and other such tools.

I think that's certainly a good argument in having such automated
notification enabled by default, especially when the time between
reboots (and hence and fsck) is completely unpredictable.  Having d-i
set this up on initial install would be desirable, IMO.


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