On Sun, Dec 18, 2005 at 01:26:45PM +0100, jdthood@tiscali.nl wrote: > Steve Langasek wrote: > > (We also shouldn't need to specify a policy for mounting any > > particular filesystem on /run, but merely mount /run early iff it's > > present in /etc/fstab and leave the implementation details to the > local > > admin.) > I think that packages Depending on initscripts >= 2.86.ds1-7 should be > entitled to assume that /run/* is a writable location available very > early after boot. Yes, they should. > Initscripts 2.86.ds1-7 includes /run and mountvirtfs mounts a tmpfs on it, > thus causing this assumption to be true. If the local admin wants > something else then he or she can edit the script in such a way that > the aforementioned assumption remains true. No, having to edit init scripts sucks. So does having mounts that aren't controlled via /etc/fstab. Are there really any init scripts that need to write out data prior to checkroot.sh (the point at which /run would be writeable by default on the rootfs)? If not, why can't we mount /run using /etc/fstab as part of checkroot.sh, and leave the details to the admin? This optimizes for the common case, and leaves the way open for solutions to uncommon requirements. > If there is demand for an alternative standard operation mode that > satisfies the assumption then that can be implemented, of course, but > offhand I can't think of why anyone would need anything but the default > configuration. The two use cases that were raised when /run was first discussed were: - NFS-mounted /var filesystem - read-only / filesystem Having a /run directory for early-boot volatile data addresses the needs of both of these use cases (even simultaneously -- hurray!), but by constraining the actual *implementation* of /run (barring ugly hacking of the init scripts), you've made the system less suitable for a third use case: - memory is at a premium, disk is not I'm not going to claim that I know of any particular users that are affected by this change; files that are candidates for /run (or /lib/run) are typically small enough that it's fairly unlikely for this alone to impact what they can or can't do with Debian. But that's also not the point: the point is that design-wise, there's simply no reason to make the choice for the user of *what* is mounted on /run, only to specify that *something* must be (and that it must be writable); given that the existing default is perfectly suitable for the majority of users, I believe we're better off not touching it. If you really want to be clever though about supporting upgrades for users that may already have read-only root, I guess you could do something like this: if grep -q '[[:space:]]/run' /etc/fstab; then mount $options /run elif grep -q '[[:space:]]/[[:space:]].*\bro\b' /etc/fstab; then mount $options -t tmpfs tmpfs /run fi And then everyone can be happy. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature