[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ifupdown writes to /etc... a bug?

On Wed, Mar 12, 2003 at 10:24:49PM +0100, Thomas Hood wrote:
> On Wed, 2003-03-12 at 18:03, Joey Hess wrote:
> > To put it another way, this is something that an admin can hack around
> > as they are setting up a diskless type system. It needs no special
> > support from Debian, though we should document that /var/run must be
> > available before the network is brought up and could suggest that both
> > /var's have links to a /run directory. Of course if d-i got support for
> > setting up diskless systems, it would be modified to do that for the
> > admin.

> > We then can just move anything we like into /var/run, and stop worrying
> > about the issue. Seems reasonable to me.

> Yes, that's the essence of it.  One still does need to worry
> about systems that have already been set up such that /var/run
> doesn't meet the new criteria, and which would break if
> early-accessed state files were suddenly moved there.  How
> should this be phased in?  Announce at sarge release time that
> "/var/run must henceforth be rw and network-independent", and
> start moving files to /var/run in post-sarge package releases?

Well, aside from the fact that it would be nice to fix this in sarge,
Continuing to use /var/run as the canonical location complicates things a
bit for the mtab case.  The 'grep -v rootfs /proc/mounts' approach ought
to work, but now instead of being able to just run 'mount /run; grep ...',
we would either have to guess at a list of needed mount points (/var,
/var/run, /run) and try them all, first making sure they're not
network-based; or resign ourselves to not getting any other interesting
information mount might've wanted to give us about local devices that
were mounted at boot time.

Steve Langasek
postmodern programmer

Attachment: pgpvYa440ecg2.pgp
Description: PGP signature

Reply to: