On Thu, Jun 07, 2012 at 09:13:35AM +0100, Philip Hands wrote: > Having upgraded to wheezy recently, I note that you're changing defaults > in rcS (as exhaustively discussed elsewhere). > > That being the case, there is no additional cost to fixing this bug, > as people are going to be prompted on upgrade about rcS anyway, so this > would seem to be a very good time to do it.
No defaults in rcS have been changed (from a squeeze to wheezy upgrade POV). We did add some new ones transiently in testing before moving them to /etc/default/tmpfs, and removed UTC, but the defaults present in squeeze are unchanged. However, this change has permitted rcS to become a regular conffile, so now at least we have the /possibilty/ of updating it to change the defaults sanely. > Perhaps I should be in favour of leaving it as it it, since I get > new customers contact me reasonably often when it turns out that the > only thing that is really wrong is that fsck needs to be run with -y. [...] > 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. I guess it's a balance between whether we get more dataloss if FSCKFIX= yes or no. 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 _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel
