[Pkg-sysvinit-devel] Bug#637087: Sensible default for all systems

[Josh Triplett]

On Mon, Dec 19, 2011 at 01:45:10PM +0000, Roger Leigh wrote:
> On Sat, Dec 17, 2011 at 03:14:51PM -0800, Josh Triplett wrote:
> > I don't see any possible scenario where FSCKFIX=no makes sense as a
> > default.  We don't debug broken filesystems with disk editors anymore;
> > either fsck works, or we restore files from backup (or from Debian
> > packages after running debsums).  Filesystem developers might want to
> > set FSCKFIX=no, or ask others to temporarily do so to reproduce a
> > problem, but as a default I think it makes sense to use FSCKFIX=yes on
> > all types of systems.
> > 
> > When fsck hits an error and offers to drop into a root shell, who does
> > anything other than just running fsck again and saying "go ahead and fix
> > it"?  Let's remove the intermediate step.
> 
> I've been thinking this way since I first noticed the default.  Are
> there any reasons ever not to fix?
> 
> With fsckfix=yes, does it at least prompt you to continue rather than
> just blindly fixing?

A prompt to continue would not work well on a headless system, or one
without a local console (such as a remote server).  While ideally every
system would have some kind of remote KVM or serial console, people
still run servers where a prompt on the console means a phonecall,
expensive "remote hands" service, or long trip.

> There are recovery situations where you might
> want to stop and make a disc image in order to avoid further damage.
> But dropping to a root shell only to run fsck by hand is rather
> pointless, I agree.  Only a tiny minority of users would be capable
> of fixing things--I know I wouldn't be able to edit my inodes by
> hand!

Hard to think of any recovery situation where you wouldn't just boot
from recovery media to make the image.  Also, people with unusual
requirements can always change the default, but the default needs to
work for people who don't know to change the default.

- Josh Triplett