[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

On Thu, May 12, 2011 at 05:52:23PM +0200, Goswin von Brederlow wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
> > On Wed, May 11, 2011 at 05:40:52PM +0100, rleigh wrote:
> > [...]
> >> The fix for this is straightforward: by making initramfs-tools use the
> >> same options as initscripts and any additional user entries in
> >> /etc/fstab (which will naturally use the same options as the scripts
> >> in order to be functional), mount failures are prevented and existing
> >> user configuration is preserved and functional.
> >
> > How is that supposed to work when initramfs-tools mounts directories
> > before /etc/fstab is accessible?
> >
> > Ben.
> The quick way is to just fix the hardcoded name to match what everything
> else uses.

What, in this context, is "everything else"?

At this point in time, initscripts is installed on every Debian
system out there.  As a result, any customised fstab files will
/have/ to use the same names as those in the initscripts unless
you edit both /etc/init.d/mount* /and/ fstab.  So unless you've
taken extraordinary measures, the hardcoded policy /is/ what is in
use, and when it comes to changing it we do need to bear in mind
that all of the filesystems in question could be in /etc/fstab
and if we change it, we break things.  Consider the breakage that
would result on upgrades, for example.

Now, of all the filesystems, only /proc is in /etc/fstab by default,
so it's less risky to alter the others, particularly the newer
additions such as /run.

> For the more flexible way the /etc/fstab is accessible when the
> initramfs is generated. Access it then. That means it still breaks when
> the user changes the entry or adds an incompatible entry without
> generating a new initaramfs but that can't be helped.

This is getting far too complex.  Ensuring that all the names are
consistent fixes the immediate problem which you reported.

The actual problem is that mount (rightly) checks mnt_fsname when it
checks if a filesystem is already mounted; if they differ, they aren't
the same filesystem.  /However/, when it comes to "special" filesystems
which don't have a block device as a backing store, the name /might/ be
irrelevant--proc is proc, no matter where you mount it, and the same
applies to devpts and sysfs.  Maybe the real solution here is that
mount should disregard different mnt_fsname for these special kernel

tmpfs filesystems are different; here they /do/ differ in the sense that
/run, /run/lock, /lib/init/rw etc. /are/ separate unique instances of
tmpfs.  Here, it might make sense to give them a name other than "none"
or "tmpfs" in order to distinguish between them--that is to say, the
tmpfs instance, rather than the mountpoint.  So names such as "run",
"runlock", would provide a unique key for /etc/fstab in addition to the
mountpoint.  But this is mostly cosmetic, and if we do make such a
change we'll need to ensure that it's coordinated between initscripts
and initramfs-tools.


  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.

Attachment: signature.asc
Description: Digital signature

Reply to: