Hi, On Wed, Mar 12, 2003 at 10:39:33AM -0600, Steve Langasek wrote: > On Wed, Mar 12, 2003 at 10:47:45PM +1000, Anthony Towns wrote: > > On Wed, Mar 12, 2003 at 11:45:48AM +0000, Miquel van Smoorenburg wrote: > > > So, it would be better to mount /run automatically without an > > > /etc/fstab entry, since it's hard to say what that entry is. > > > Besides, for a ramdisk, you still need to mkfs a filesystem on > > > it before mounting it, so it's all special case code anyway. > > > We are in a position where we can cheat, though. Since we don't > > automatically support read-only root partitions, we can just make /run > > be on the root fs, and assume that admins who've already demonstrated > > enough cleverness to cope with /etc/motd, /etc/network/ifstate, > > /lib/modules/*/modules.* and so forth can cope with adding an fstab > > entry for /run. > > Not to mention that moving mtab to tmpfs to solve the read-only /etc > problem only introduces a new problem of initializing mtab with > information about already-mounted filesystems. Perhaps this has already > been solved, but if not, I think Debian should punt on it for the time > being. mount -n /mem grep -v rootfs /proc/mounts > /mem/mtab # don't want pseudo-rootdev ... mount -o remount,rw / # also puts proper root device name in mtab The only reason that mtab isn't merely a symlink to /proc/mounts is that the userspace part of mount may store information there that's useful later. However, if the userspace mount has never been run since the kernel booted, mtab cannot contain any valid information that's not already in /proc/mounts. Other than the actual name of the block device on which the root filesystem resides of course, but that's just a weird thing with Linux that's easily solved, see above. Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Attachment:
pgpmwtYtsXAr_.pgp
Description: PGP signature