[Pkg-sysvinit-devel] Problem with RAMRUN/RAMLOCK if /var is mounted
Edgar Fuß
ef at math.uni-bonn.de
Fri Jan 25 11:18:32 UTC 2008
EF> the mount in /etc/init.d/mountkernfs will have failed because /var
EF> will not have been mounted at this early stage and the root fs will
EF> most probably lack the mount point var/run (since the file system to
EF> be mounted on /var contains the mount point run).
PR> To avoid this, some effort is taken to make sure the root file system
PR> include /var/run/ on the file system, to allow it to be mounted before
PR> /var/ is mounted, and then moved to the new /var/run/ when /var/ is
PR> mounted. An interesting question is why this is not the case for your
PR> machine. It should have been created when initscripts was installed
PR> or upgraded.
The system in question was installed via FAI.
So I'll have to hack into FAI that var/run and var/lock are created on the root fs. What's the logic supposed to be used for this? Just mkdir var/run? What to do in case var is a symlink (probably can't happen)?
EF> Who is supposed to access /var/run or /var/lock before /var is
EF> mounted anyway?
PR> The daemons starting very early in the boot with the new event based
PR> kernel, for example dhclient started via udev for those that want it.
PR> An alternative is to use the new /lib/init/rw/ directory for status
PR> info, but pid files are supposed to go into /var/run/.
I see. But how is this supposed to work in case you don't use RAMRUN/RAMLOCK, but /var resides on a seperate file system? I may be overlooking something, but my impression is that those daemons will write into var/run on the root fs and that will be shadowed as soon as /var is mounted in /etc/init.d/mountall.sh.
More information about the Pkg-sysvinit-devel
mailing list