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. _______________________________________________ Pkg-sysvinit-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-sysvinit-devel
