On Thu, Feb 28, 2013 at 01:30:50PM +0000, Philip Hands wrote: > I just upgraded a wheezy box, and was again asked if I wanted to keep > my local FSCKFIX=yes option, or return to the (stupid) default. > > That made me scratch my head, thinking: wasn't there a bug about that?
Yes. The reason for the prompt is probably the conversion of rcS to a conffile, which was done partly to permit changing of this (and other) defaults in the future. I thought this was a good idea for the medium term, but I've also got a lot of flak about it for various reasons. The current odd "only default to yes on arm arches" is not ideal. We should be using better criteria to make that decision. > On the other hand it seems that there's a wide consensus that, not only > is it wrong as it is, but that it should be fixed -- DC11 was not the > first time this subject has come up. > The only concern raised in the bug itself was about fscking underlying > media in a RAID. This to me reads like an after-echo of a (long-ago > fixed) bug in LVM, where pvscan could sometimes find one of the physical > devices before its associated RAID device, and so bring up LVM only > writing to one drive. I raised this issue on #debian-devel a few times, and got thoroughly roasted for even suggesting changing the default by several people. So I'm not sure of exactly what the consensus is, or how grounded in reality the objections are at the present time. Personally, I'd be all for changing the default if it's safe to do so. And for new installs possibly even if it's not safe, /if/ we can detect such situations and disable it during installation (or even at runtime)--we could default to "auto" and adjust the default if not configured. > So, given the consensus for a fix, what needs to be done to actually > make this happen, and is there any chance of it happening before the > wheezy release? > > I'd think that it would be OK to start with the new "yes" default for > new installs, but might be argued that people that were upgrading should > at least be warned of the change (not that most of them will know that > they were suffering under the old default, and many of those that do > know will get prompted because they've already set it to "yes" locally). > > The fact that the /etc/default/rcS file is changing anyway, and so will > prompt anyone who's already edited it, seems to make this a good time to > fix this bug. > > If it's deemed impossible for wheezy, what do we need to do so that it > at least has a chance of being fixed for jessie. > > Should it be reassigned to initscripts? should the priority be raised? I think it's unfortunately too late for wheezy, but certainly on the cards for jessie. I did try to get wider discussion on this issue, but didn't change the default due to the very vocal objections raised at the time. I certainly would like to fix this properly, perhaps after getting a concrete list of objections and trying to address them if possible (and still valid). We could - alter FSCKFIX to be "auto" by default - auto would itself default to "yes" - auto would default to "no" if the system was found to be using RAID/LVM and/or was in a state which could be potentially dangerous. The rules for this are entirely open for discussion. Inputs for deciding the default could be the absence of a console (i.e. noninteractive) which is the current basis for the arm defaults IIRC, though this isn't reliable to detect. Any others? As always, I'm happy for any better suggestions! 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
