FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Kernel

 
 
LinkBack Thread Tools
 
Old 11-17-2010, 11:39 PM
Steve Langasek
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote:
> Package: initramfs-tools
> Version: 0.93.4
> Severity: critical
> File: /usr/share/initramfs-tools/init
> Tags: patch

How in the world does this count as "critical"?

> The /etc/init.d/mountall.sh script reports a red FAILED because of that.

This is the only symptom you describe, and that's certainly not critical!

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20101118003956.GB24919@virgil.dodds.net">http://lists.debian.org/20101118003956.GB24919@virgil.dodds.net
 
Old 11-18-2010, 11:43 AM
Goswin von Brederlow
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

severity 603858 important
thanks

Steve Langasek <vorlon@debian.org> writes:

> On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote:
>> Package: initramfs-tools
>> Version: 0.93.4
>> Severity: critical
>> File: /usr/share/initramfs-tools/init
>> Tags: patch
>
> How in the world does this count as "critical"?
>
>> The /etc/init.d/mountall.sh script reports a red FAILED because of that.
>
> This is the only symptom you describe, and that's certainly not critical!

Usualy a FAILED message also means the script returns an error, which in
turn means insserv stops executing depending scripts in that runlevel
and skips to the next.

Looking closer at the script I see now that mountall.sh does not report
errors through its exit code. So it just makes it impossible to see if
something real failed to mount because proc always fails to mount. Sorry
for the severity.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87eiaissyj.fsf@frosties.localnet">http://lists.debian.org/87eiaissyj.fsf@frosties.localnet
 
Old 05-10-2011, 10:12 PM
rleigh
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote:
> I recently installed a squeeze system. The generated /etc/fstab
> contains the following line:
>
> # <file system> <mount point> <type> <options> <dump> <pass>
> proc /proc proc defaults 0 0
>
> But in /usr/share/initramfs-tools/init you have:
>
> mount -t proc -o nodev,noexec,nosuid none /proc
>
> This causes mount to return an error when mounting all local
> filesystems because "proc" and "none" are different divices and it
> can't mount /proc again over an existing mountpoint. The
> /etc/init.d/mountall.sh script reports a red FAILED because of that.
>
> Node: /etc/mtab is a link to /proc/mounts here. That might affect this
> issue.

It certainly does. I've attached a patch which fixes this for
all filesystems handed over to the host from the initramfs so
that read-only root works correctly. This matches up the mount
options with those used by initscripts so that everything works
whether you're using /etc/mtab as a file or as a symlink to
/proc/mounts (as will occur soon; see #620710 and
http://people.debian.org/~rleigh/util-linux_2.19.1-1.dsc). The
new mount uses libmount and /run/mount/utab which makes a
/proc/mounts symlink work correctly.


Regards,
Roger

--
.'`. 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.
 
Old 05-11-2011, 04:40 PM
rleigh
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

On Tue, May 10, 2011 at 11:12:07PM +0100, Roger Leigh wrote:
> On Wed, Nov 17, 2010 at 11:04:15PM +0100, Goswin von Brederlow wrote:
> > I recently installed a squeeze system. The generated /etc/fstab
> > contains the following line:
> >
> > # <file system> <mount point> <type> <options> <dump> <pass>
> > proc /proc proc defaults 0 0
> >
> > But in /usr/share/initramfs-tools/init you have:
> >
> > mount -t proc -o nodev,noexec,nosuid none /proc
> >
> > This causes mount to return an error when mounting all local
> > filesystems because "proc" and "none" are different divices and it
> > can't mount /proc again over an existing mountpoint. The
> > /etc/init.d/mountall.sh script reports a red FAILED because of that.
> >
> > Node: /etc/mtab is a link to /proc/mounts here. That might affect this
> > issue.
>
> It certainly does. I've attached a patch which fixes this for
> all filesystems handed over to the host from the initramfs so
> that read-only root works correctly. This matches up the mount
> options with those used by initscripts so that everything works
> whether you're using /etc/mtab as a file or as a symlink to
> /proc/mounts (as will occur soon; see #620710 and
> http://people.debian.org/~rleigh/util-linux_2.19.1-1.dsc). The
> new mount uses libmount and /run/mount/utab which makes a
> /proc/mounts symlink work correctly.

Just to add a small bit of clarification: for "mount -a" to work,
the mnt_fsname and mnt_dir and mnt_type must match or else mount
reports a mount error.

This information is recorded in three places:

1) /etc/fstab
2) /etc/mtab (or /proc/mounts if symlinked)
3) initscripts mounting filesystems (mountkernfs.sh, mountdevsubfs.sh)

The information needs to be identical between all three when running
"mount -a" or else the result is a mount failure (exit status 32).

Historically, mtab is a regular file. In this case, the options it
stores come from the initscripts doing the mounting and/or fstab if
any entries are present. Typically no fstab entries will be present,
so initscripts is the only source of the options found in mtab, and
hence they are always the same. The only one present in fstab by
default is /proc, and initscripts is careful to use the same options
to avoid a mismatch.

initramfs-tools only comes into the picture when we make /etc/mtab a
symlink to /proc/mounts. At this point, the mount options used by
initramfs-tools init are visible to mount where previously they were
hidden. Because initramfs-tools doesn't use the same options as
historical practice in initscripts or fstab, the result is a mismatch
between /etc/mtab and /etc/fstab which results in "mount -a" returning
with a mount failure status.

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.


Regards,
Roger

--
.'`. 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.
 
Old 05-11-2011, 06:56 PM
Ben Hutchings
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

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.

--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110511185613.GP2268@decadent.org.uk">http://lists.debian.org/20110511185613.GP2268@decadent.org.uk
 
Old 05-11-2011, 07:27 PM
rleigh
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

On Wed, May 11, 2011 at 07:56:13PM +0100, Ben Hutchings wrote:
> 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?

Well, the mnt_fsname for each is hard-coded in the initscripts scripts'
domount() calls. If the user adds an fstab entry, they'll use the
same fsname (or else the scripts won't use it and you'll also get mount
errors). As a result, there's no choice in the naming here--they have
been hardcoded in initscripts for many years. The only reason we
haven't had much reported breakage is that until now very few users
have made /proc/mounts a symlink, and those that have probably manually
fixed things up rather than go to the effort of getting the initramfs
fixed.


The order is like this:

init (initramfs) mounts /proc /dev /dev/pts /sys /run etc.
---
mountkernfs.sh
mounts /run, proc, /sys (if not already mounted by the initramfs).
Defaults are taken from /lib/init and /etc/fstab.
mountdevsubfs.sh
does the same for /dev/pts /dev/shm.
[root is made r/w]
mtab.sh
generates the initial mtab; this uses the defaults from
/lib/init and /etc/fstab as for the earlier scripts.
mtab then remounts the filesystems with the options from /lib/init
and /etc/fstab to ensure that user-configured filesystem options are
applied to the initramfs mounts [note: this does not affect mnt_fsname]
mountall.sh
calls "mount -a" to mount filesystems
This is the problematic step. When we use the generated mtab, it
exactly matches what we did, and runs without error. When we
use a symlink to /proc/mounts, there's a mismatch with the options
initramfs init used, and what the initscripts and fstab used, and
this is what causes the error.

The cause is simple to test for yourself. Just take the
proc /proc proc defaults 0 0
line from /etc/fstab, and change the first "proc" to "none" (or
anything else) and run "mount -a", and you'll see it fail. Change it
back, and it works just fine. This is why updating initramfs init
to use the same mnt_fsname for its mounts as the system/admin would
use corrects the problem. It's purely the "none" mnt_fsname from
initramfs that's breaking mount here because it doesn't match what
every system has in their fstab (by default).


Regards,
Roger

--
.'`. 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.
 
Old 05-12-2011, 03:52 PM
Goswin von Brederlow
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

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.

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.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r583gbm0.fsf@frosties.localnet">http://lists.debian.org/87r583gbm0.fsf@frosties.localnet
 
Old 05-12-2011, 03:52 PM
Goswin von Brederlow
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

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.

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.

MfG
Goswin



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87r583gbm0.fsf@frosties.localnet">http://lists.debian.org/87r583gbm0.fsf@frosties.localnet
 
Old 05-12-2011, 06:06 PM
rleigh
 
Default 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
filesystems.

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.


Regards,
Roger

--
.'`. 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.
 
Old 05-12-2011, 06:57 PM
Goswin von Brederlow
 
Default Bug#603858: Mount options for proc conflict with /etc/fstab breaking /etc/init.d/mountall.sh

rleigh <rleigh@codelibre.net> writes:

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

The entry historically used in /etc/fstab, the initscripts, the Debian
Installer (which puts the initial entry into /etc/fstab).

The only thing that uses a different device is intramfs.

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

And /proc is what I was concerned about. Although I do have /sys in
there too on most systems.

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

Indeed. We can expect a well formed entry in /etc/fstab. There is no
good reason why the user would want to change the pseudo device used
there. It is enough if initramfs just uses the same device name as
everything else expects.

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

Having mount ignore the device name when it is a pseudo device sounds
feasable. I still would like all packages to use the same device name
just for consistencies sake. Also mount might not be the only thing
comparing /etc/fstab to /proc/mounts.

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

It really doesn't matter what it is as long as it is consitent. Given
that /run and /run/lock aren't yet in use in Debian now would be the
time to pick a name and then stick with it. Using "run" and "runlock"
sounds good, go with that.

Since /run and /run/lock don't usualy have fstab entries it shouldn't be
a problem to change the name for those that have the experimental
initscripts installed or for a transition period when initscritps and
initramfs disagree on the name. So I don't think any depends/breaks
should be needed.

MfG
Goswin





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 8762pfhhm9.fsf@frosties.localnet">http://lists.debian.org/8762pfhhm9.fsf@frosties.localnet
 

Thread Tools




All times are GMT. The time now is 06:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org