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.
Attachment:
signature.asc
Description: Digital signature