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

[Roger Leigh]

On Sat, Apr 28, 2012 at 11:16:48PM +0200, Carsten Hey wrote:
> [ 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.

I was just thinking, is there a way to detect if the system was
bootstrapped with grml-bootstrap compared with plain debootstrap? If
that was the case, we could put a specific check for that in, and
clean up the fstab if so.  It would mean everyone else would get
the configuration preserved, and only the broken ones get updated,
which I think would be a reasonable compromise if possible.

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

Not that I am aware of for the host system.

> > we would be deliberately trashing their configuration.
> 
> A regression leading to unbootable systems sounds like a bug to me, even
> if the previously working configuration is considered to be buggy.

It's a bug.  And we should not break any systems if we can help it.
But the change in behaviour is only exposing a latent bug originating
elsewhere.

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

For current systems, I think it's useful to know what systemd and
upstart are doing.  systemd is simple enough to test on Debian;
for upstart we can look at Ubuntu.  Part of the reason for the mount
changes was to align the mount options with those used in the
initramfs (copied both ways, but mainly updating the initramfs with
the initscripts defaults), and also with systemd so that we have
consistent behaviour across all init systems and boot methods.
So if all the others choose to not respect noauto for specific
mounts, that's a point in favour of doing that.


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