On Sat September 16 2006 16:56, Petter Reinholdtsen wrote: > [Steve Langasek] > > > However, that's not the same thing as saying it's ok for sysvinit > > to *make* /var/run a tmpfs on the admin's behalf. I think it's > > pretty clear that this violates the letter of the FHS, and such a > > change needs to be considered carefully. > > I fail to see how it violates the letter of the FHS. It is as far as > I can see unspecified what kind of file systems will be used, and > also if directories will persist across boots. > > The reason I believe it is important to have some writable file > system available at the very beginning of the boot is that there are > programs running when kernel modules are loaded by udev that need a > place to store state information. At the moment, there is no > location to do that, and strange things can happen when the coldplug > events happen early in the boot. To fix it, some tmpfs area need to > be mounted in mountkernfs.sh. This issue has been discussed here on > the list a few months ago, without any conclusion being reached. I > do not want us to release etch with a boot system unable to handle > detected hardware properly, so I decided to fix this now. Also, it > is useful to make it easier to set up stateless workstations using > Debian (aka diskless machines ala LTSP), and storing state > information in a RAM file system make this a lot easier.
Sounds fine, if one has enough RAM to spare. How big can /var/run get? Could such a change limit the usefulness of low mem systems? Is it feasible to create a tmpfs based /var/run during boot then move its contents to a disk based /var/run (if that is the admin's the preference) when /var becomes available? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]