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
Reply to: