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

Re: Bug#84074: ifupdown writes to /etc... a bug?


On Tue, Mar 11, 2003 at 08:36:25AM +0000, Miquel van Smoorenburg wrote:

> Emile van Bergen  <emile-deb@evbergen.xs4all.nl> wrote:
> >* add /mem, which is RAM-based, writable /very/ early
> You should use /dev/shm with a shmfs. The location has been standarized,
> shmfs shrinks and grows as needed so never takes more memory than
> needed, and shmfs data can be put into swap.
> Downside: works only with 2.4.x. kernels.

Well, then have /mem be a symlink to /dev/shm/mem on 2.4.x and an older
RAM-based FS on older kernels.

> >  and initialised
> >  in full from /var/mem at bootup, allowing the admin to define a desired
> >  initial state;

I realised the apparent contradiction, but it's not if you consider this
sequence of events:

1. /mem is mounted and empty because it's RAM-based or manually emptied

2. things like ifup can use /mem

3. /var is mounted; contents of /var/mem are copied recursively to /mem,
   including optionally /var/mem/preserve, without clearing /mem first,
   so any files that were put in /mem in step 2 that do not exist in /var/mem 
   just stay there

4. things use /mem, optionally /mem/preserve

5. optionally, /mem/preserve is copied back to /var/mem/preserve.

> Right ... but /var isn't available at boot. That's kind of the
> point of this whole discussion. Debian should define an initial
> state and create it (just one or two directories, I guess)
> using an init script at early boot.

The initial state can be defined as empty before /var is online, or
you could choose something like /etc/mem if it's really necessary to
have a non-empty state before you have /var that isn't trivial to

> But then you could go all the way and have /var/bootstate
> as I described. It could be a symlink to /dev/shm/bootstate,
> and as soon as the real /var is mounted over it the link
> dissapears and the real /var/bootstate appears, at that point
> it is easy to copy /dev/shm/bootstate back to it, voila.

That only works on kernels that allow you to mount things on non-empty
mount points.

> This is all trivial to implement. A few lines of scripting.
> The hard thing is: what about systems with a 2.2 kernel ?
> Or older 2.4 kernels, where shmfs was still a configurable
> option (in later 2.4 kernels you can't turn it off)

Use any ram-based FS.



E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

Attachment: pgpUP4yFdvVjb.pgp
Description: PGP signature

Reply to: