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? 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! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
