On Tue, Dec 20, 2005 at 12:01:44PM +0100, Petter Reinholdtsen wrote: > [Anthony Towns] > > Here are the cases: > > (a) /var on /, mounted rw during normal operation > > (b) /var a local fs, separate to / > > (c) / and /var separate NFS mounts > > (d) / local, /var an NFS mount > > (e) /var local, can't be mounted 'til a writable fs is available > > For (a) you just need to wait until S10checkroot.sh has finished. > > For (b) you need to wait until S35mountall.sh has finished. > But the potential users of this /run directory can not wait until > neither S10checkroot.sh Uh, the new initscripts force them to wait until S36mountvirtfs... > One user is bootlogd, needing before init is started to store > stats about the boot. That is before both these points in the boot. So how do you log the failure of mounting /run rw? Given this is supposed to be a tmpfs, and not something permanent anyway, having bootlogd store the output it's meant to be logging, and dump it to /var/log when it's ready seems fine anyway. Adding that to init would even seem pretty straightforward, along with an addition to telinit to, uh, tell init to dump the logs somewhere. There doesn't seem to be a bootlogd package? > Another is to update mtab, documenting every mount point as they are > mounted. This should hot have to wait until after /var/ is mounted. Likewise, how do you document the mounting of /run in mtab? Hrm, why don't we use /proc/mounts for mtab information, and have mount store _only the extra information it needs_ in /var/run/mtab? > A third use is read-only clients (LTSP/lessdisks), needing a place to > store things generated during boot (mtab, motd, etc). These work > around the issue by hacking the boot sequence quite a lot, but it > would be cleaner if no special handling is required. Sure, those were mentioned above (/ local, /var an NFS mount, or if /var is a tmpfs or similar, / and /var local). Cheers, aj
Attachment:
signature.asc
Description: Digital signature