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

[Carsten Hey]

* Roger Leigh [2012-04-29 23:19 +0100]:
> On Sat, Apr 28, 2012 at 11:16:48PM +0200, Carsten Hey wrote:
> > 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.

grlm-debootstrap copies files into the chroot that is being created:

  cp $VERBOSE $CONFFILES/chroot-script $MNTPOINT/bin/chroot-script
  cp $VERBOSE $CONFFILES/config    $MNTPOINT/etc/debootstrap/

Removing a part of them has been added in a commit after the fstab has
been fixed, but I don't know if this clean up was always (or rather in
the four years the fstab error existed) missing in grml-debootstrap or
if it has been deleted whilst refactoring, but this can be looked up.

Users might delete either /bin/chroot-script, /etc/debootstrap/ or both
after installation.  Normally I don't delete any of them, but I don't
know how others handle this or if others even know that there are still
files needed during installation on their system.

Possible ways to detect 'grml-bootstrap'ed systems include (given that
the files have not been deleted manually and that there are no relevant
changes grlm-debootstrap in the relevant timeframe):

  $ fgrep -q -x done /etc/debootstrap/stages/fstab 2>/dev/null
  $ test -x /bin/chroot-script
  $ [ -x /bin/chroot-script ] && grep -qx '^# Purpose:.*executed.*via grml-debootstrap$' /bin/chroot-script

Unlike the second line, the third will not wrongly return 0 if a user
created an unrelated script with the same name.  One way to raise the
probability of a correct result in case the user deleted either the
directory or the file is to combine the first and the last line.

If you choose this way of solving the issue, please drop us a mail so
that we can look up if tests like the above would work with all relevant
grml-debootstrap versions.


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

I assume the reason for these questions is obvious; without a valid use
case for this, both options seem to be reasonable for me, and with
a valid use case only initscripts' current behaviour would have been
reasonable.


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

I fully agree.


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

Being consistent to other init systems in Debian makes sense.  I'll send
an other mail after knowing this.


Regards
Carsten


P.S.: No, you are not the only one.  The current situation is more or
less an evolution of what started years ago.  If needed, I think there
is a large enough community to provide alternatives before people become
completely insane and create a tightly integrated Gnome distribution
(what btw. already has been proposed) based on Linux core.