Re: Setting FSCKFIX=yes on certain machines
On Fri, Aug 15, 2008 at 04:32:23PM +0300, Martin Michlmayr wrote:
> * Bernhard R. Link <brlink@debian.org> [2008-08-15 15:23]:
> > * Martin Michlmayr <tbm@cyrius.com> [080814 10:52]:
> > > We have to set FSCKFIX=yes in /etc/default/rcS on machines that don't
> > > have any I/O devices to follow the boot process, otherwise fsck might
> > > prompt the user to press a key and this is not possible.
> > >
> >
> > Why not make this the default for all machines? I think the people that
> > can make a informed answer to the questions asked by fsck are a very
> > little minority nowadays.
> > FSCKFIX=no also (at least on etch, not tested on lenny) also has the
> > disadvantage of stopping the boot and needing the root password to
> > continue. And when the person with root password arrives, there is
> > usually little that can be done but just answering everything
> > with yes (or running fsck -y).
> >
>
> Let's add Ted.
e2fsck -p will fix *most* filesystem corruptions automatically. The
ones where it stops and asks for permissions are ones where some
amount of human intervention might be needed. In some cases, it is
situations such as where we are moving a file to lost+found, and that
file could be critical to a system running correctly, or securely
(i.e., a hosts.deny file), and so e2fsck has always erred on the side
of prudence, and letting a human decide. Note that in such a case, it
doesn't require a filesystem wizard to look at the files that are in
lost+found, and decide that maybe this is something that you
**really** want to fix before letting the system come all the way back
up.
There are a few other cases where answering yes will actually cause
severe filesystem damage. (i.e., relocating the inode table.) In
e2fsprogs 1.41 I've added some extra failsafes to try avoid that
scenario (we try a *lot* harder to use the backup block group
descriptors before we relocate the inode table), but it's still the
case that it can come up. I suspect what I probably should do is have
a class of questions which are so dangerous that even -y will not
automatically fix them, if there isn't a human in front of the
keyboard.
Or maybe we'll have a -pp option which is much more aggressive about
automatically fixing more types of filesystem corruption without
asking for human input. In general, it's a hard problem, though.
Note that in practice, it's *very* rare for e2fsck to trigger these
days and need human assistance unless there is some kind of hardware
or software trouble. The ext3 journal does protect you against most
places where e2fsck would ask for help. That's one of the reasons why
this hasn't been high priority for me to fix, compared with stablizing
ext4 (for example).
Regards,
- Ted
Reply to: