On Wed, Mar 12, 2003 at 01:26:58PM +0000, Miquel van Smoorenburg wrote: > In article <[🔎] 20030312124745.GB27390@azure.humbug.org.au>, > Anthony Towns <aj@azure.humbug.org.au> 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. > I agree. In that case, we don't need to worry about 2.2 kernels > and ramdisks either; just state 'use a 2.4 kernel with tmpfs > (Virtual memory file system support) enabled'. And the debian kernels > should enable it by default (it's very small as it is just an > extension on the always-builtin shm support). > Only things left to be done: > - Enable CONFIG_TMPFS in default debian kernels > - Include /run in sysvinit > - Mount /run ASAP if it is a seperate filesystem > - Clean /run as soon as it is read/write. > - On installation of sysvinit offer to put /run as tmpfs in fstab > automatically if the kernel supports it - amend policy so that people don't file serious bugs against packages for using a directory not defined in the FHS :) -- Steve Langasek postmodern programmer
Attachment:
pgpAIQaPF2euN.pgp
Description: PGP signature