The /run directory is currently created after the first boot as a symlink to /var/volatile/run. Debian implements /run as a tmpfs, and symlinks /var/run/ and similar runtime directories back to /run. Anyway, /run needs to be available in the rootfs at first boot, and not created post-install.
I would suggest that we correctly create the symlink for /run to /var/run since this is targeted for embedded systems, having multiple tmpfs may not be the best.
Here's an article on this issue. http://article.gmane.org/gmane.linux.redhat.fedora.devel/146976 As this article suggests, I suggest a directory hierarchy like this. tmpfs on /run /var/run -> /run /var/run/lock -> /run/lock /var/run/log -> /run/log .... This approach has already adopted by major distribution in their new releases.
Also, if we make /run the standard directory for volatile runtime data, /var/volatile would not be necessary any more.
%solution% 1) change base-file package, make /run a standard directory /run /run/tmp /run/lock ... 2) improve populate-volatile.sh, change the way it deals with links In current system, if we change /etc/default/volatile/<config file>, and then run command '/etc/init.d/populate_volatile.sh update', it is very likely the result is not what we expect. For example, changing 'l root root 0755 /var/run /var/volatile/run' to 'l root root 0755 /var/run /run' in the config file does not have any real effect. This is caused by the way populate_volatile.sh deals with 'l'-type config items. It first examines if the <target> (in this example /var/run) exists, and if so, it does nothing. I don't think this is appropriate. The script should do things as the configuration file tells it. So I suggest the following way to deal with links in populate_volatile.sh. (similar to Ubuntu's way to deal with mounted-var. See attachment for more detail.) <type> <user> <group> <mode> <target> <link_source> if <target> exists as a dir: cp -rf <target> <link_source>; rm -rf <target>; if <target> exists as a link or a file: rm -f <target> ln -sf <link_source> <target> 3) change /etc/fstab make /run a mount point for tmpfs /var/volatile is no more a mount point for tmpfs 4) change /etc/default/volatiles/<default config>, make the following directory hierarchy /var/run -> /run /var/cache -> /run/cache /var/lock -> /run/lock ... /var/volatile/run -> /run /var/volatile/cache -> /run/cache ... I still keep /var/volatile in system for backward compatibility reason. Because I'm not sure whether some packages in yocto will need it. But no tmpfs mounted at /var/volatile. (Any suggestion would be welcome.)
Please look at the base_files recipe also since it lays down some of the original layout so we do not need to do the cp or rm, also continue to implement a prototype this so we can confirm it's operation.
We've added code which links /run to /var/run in the recent udev upgrade. Whilst I appreciate the desire to match "standards", is there a strong reason to change these defaults and break backwards compatibility with existing systems? I have a suspicion this is going to be a very disruptive change for users and I'm not sure we have a good reason for it?
Thank you for your advices. Here's a few thoughts of mine, please feel free to give me your opinions and suggestions. 1) Backward compatibility Backward compatibility is the first thing that came into my mind when I first looked at this issue. That's why I still keep /var/volatile directory in my design. After applying changes as stated above, I built a sato image and tested it on beagleboard. The weekly test cases all passed. 2) populate_volatile.sh Three major files (of course there're others) in yocto that change the directory hierarchy are 'fs-perms.txt', which is used by package.bbclass, 'base_files_xxx.bb' and 'initscripts' (volatiles and populate_volatile.sh). Syntax in volatiles: <type> <user> <group> <mode> <target> <link_source> In current system, if <target> has been created in fs-perms.txt or base_file_xxx.bb (or other recipes), populate_volatile.sh has no real effect on that <target>. In other words, it has the lowest 'priority' (forgive me if I used the wrong word). However, /etc/default/volatiles/<config> and populate_volatile.sh are files that the end user actually see. They don't see fs-perms.txt or base_files_xxx.bb. If that script doesn't behave as expected, the user may be confused. So I suggest improve the script. Also, as Saul suggested, implementing a prototype for user confirmation is necessary. 3) problem with linking /run to /var/run I think linking /run to /var/run in current system is OK. It's simple and seems to work so far. However, there may be two potential problems. *) what if some application needs /run/lock or /run/cache, as udev needs /run *) symlink /run to /var/run is specified in /etc/default/volatiles/<config>, if /run or /run/xxx is created by some recipes in yocto, the symlink will not be correctly created by the current populate_volatile.sh script. Actually, we have 'meta/recipes-core/initrdscripts/files/init-live.sh: mkdir -p /run' and 'meta/recipes-core/initrdscripts/initramfs-framework/udev: mkdir -p /run '. I'm not sure wehther other recipes may use /run. With these two problems considered, I prefer making /run dir a mount point for tmpfs. We can symlink /var/run to it, and also, symlink /var/volatile/run to /run for backward compatibility. 4) summary There're two things we have to decide. *) whether we should improve the populate_volatile.sh script *) whether we should make /run dir a mount point for tmpfs or just symlink link it to /var/run
For now, everything seems OK to symlink /run to /var/run. There seems no compelling reason to do this, so I'll mark this bug as RESOLVED/NOTABUG.
Setting to VERIFIED. /run and /var/run/ symlink to /var/volatile/run, which is working fine now.