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

[Carsten Hey]

[ Dropping hmh from Cc, I was not sure if he's one of the uploaders
  and thus should receive the mail anyway - but I looked it up now. ]

* Roger Leigh [2012-04-28 20:17 +0100]:
> On Sat, Apr 28, 2012 at 06:21:58PM +0200, Carsten Hey wrote:
> > * Henrique de Moraes Holschuh [2012-04-28 12:11 -0300]:
> > > 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 ...
>
> initscripts can't fix this problem /at all/ by altering /etc/fstab.
> ...

So the correct thing could, besides doing it manually, only be done in
a maintainer script of an essential package, but as you explained, doing
this would be wrong.  I think we agree that there is no clean way to
remove the line automatically.


> If the admin deliberately configured a mount with noauto,

Is there any valid use-case to configure a sysfs mount to /sys with
noauto?  If so, was there an according bug report before doing so had
this effect?

> we would be deliberately trashing their configuration.

The admin relied on undocumented and undefined behaviour if a sysfs
mount to /sys with noauto was deliberately configured, and this
configuration attempt was never successful in any stable Debian release.


> > In general, I don't consider changing a programs behaviour without
> > a reason to do so to match the principle of least surprise.  ...
>
> ...  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.

Well, better code and consistent behaviour (over different mount options
or over different releases) are not necessarily the same.

> 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,

All but producing the same fstab entries as the debian-installer would
is in my opinion a bug in any alternative installer.

> but I don't think that is in any way initscripts' responsibility.

That initscripts does not fix bugs introduced by other packages is not
a bug in initscripts.  initscripts responsibility in this case is in my
opinion that it should not render systems that worked well under an
previous stable release to be unbootable after upgrading to an new
release.

A regression leading to unbootable systems sounds like a bug to me, even
if the previously working configuration is considered to be buggy.


> > > > 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 nor about their
                                           fixed typo here ^
> > intention.
>
> It sounds quite straightforward to me:

Yes, the question is indeed straightforward.

> how do other distributions handle noauto in this situation?  Do they
> respect it, ignore it, or not look at fstab at all?

I know that at least some switched from requiring an /sys fstab entry to
not requiring it, but I do not know what others do if there is still
such a line.  This is what I meant by not being sure about the answers.

By not being sure about the intention I meant this:  Since Debian
Squeeze handles such lines different from Debian Wheezy, we already got
two major distributions (stable and testing) that assume a different
semantic.  If we would check how other distributions handle this, we
would (independent of the result) get at least two different behaviours
in major distributions and I don't see which conclusion could be drawn
from "some do this and others do this".  Even if all would assume the
same semantic, due to a lacking standard like document or reference
implementation, no one could guarantee that some distributions do not
switch to a different behaviour the next day (even with a standard no
one could guarantee this, but then we at least would know that they are
broken and how to do it correctly).

Anyway, you seem to consider this questions to be important.  If you
think that they are that important that the outcome of this discussion
depends on it, I think the behaviour of other distributions can be
investigated, it just will need some time.


Regards
Carsten