[Pkg-sysvinit-devel] Bug#670106: Bug#670106: initscripts: please ignore noauto sysfs entries in fstab

Roger Leigh rleigh at codelibre.net
Sat Apr 28 19:17:26 UTC 2012


On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote:
> * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]:
> > On Wed, 25 Apr 2012, Carsten Hey wrote:
> > > The problem is that installing Squeeze via grml-debootstrap perfectly
> > > works and after upgrading to Wheezy udev will not start.  A wrongly
> > > generated /etc/fstab can't be fixed for existing systems by releasing
> > > a fixed version of a tool that is only run once during installation.
> >
> > The correct thing to do would be to fix the broken /etc/fstab, then...
> 
> There is only one reliable way to do so: in initscripts' preinst.  But
> if it does not need to be that reliable, then postinst would be fine too
> in case you'd like to keep the preinst scripts of essential packages
> (and their dependencies) as small or as simple as possible.

initscripts can't fix this problem /at all/ by altering /etc/fstab.
If the admin deliberately configured a mount with noauto, we would
be deliberately trashing their configuration.  Second-guessing what
the admin /might have wanted/ is a road that we really don't want to
go down, IMO, since it always comes back to bite eventually.

> In general, I don't consider changing a programs behaviour without
> a reason to do so to match the principle of least surprise.  Not
> starting udev because of this change (not mounting /sys in Wheezy with
> the same config that works in Squeeze) doesn't make the situation any
> better.

So I think I'm probably responsible for this change in behaviour.
The old mountkernfs/devsubfs/... scripts had tons of duplicated
code, and the same code was also duplicated to support mtab
generation.  I refactored all this into a "domount" function in
/lib/init/mount-functions.sh.  This made everything more readable,
consistent and maintainable, as well as fixing a number of bugs.
It also made respecting various mount options such as noauto
consistent across the board.

However... I really don't think the new behaviour is buggy or
broken.  If anything, it's a big improvement over the old code.
I'm not sure I think this is a bug in initscript at all, really.
It's breaking on a file generated by a buggy grml-debootstrap,
but I don't think that is in any way initscripts' responsibility.

> > > In my opinion, the underlying problem is that there is no clear and
> > > distribution independent semantic of noauto when used in a fstab entry
> > > for those standard virtual file systems.  If there would be such a clear
> >
> > The other distros ignore "noauto"?  Or do them ignore /etc/fstab
> > entirely for the special filesystems?  I suspect it is the later.
> 
> I'm neither sure about the answers to your questions not about their
> intention.

It sounds quite straightforward to me: how do other distributions
handle noauto in this situation?  Do they respect it, ignore it,
or not look at fstab at all?


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





More information about the Pkg-sysvinit-devel mailing list