Re: ifupdown writes to /etc... a bug?
Emile van Bergen <emile-deb@evbergen.xs4all.nl> writes:
> Hi,
>
> On Thu, Mar 13, 2003 at 02:12:18AM +0100, Emile van Bergen wrote:
>
> > [...] as I implement the solutions using /mem for the problems above
> > I'll let you know how it works out.
>
> For those still interested in this thread, I'm still toying with /mem
> and what it means for sysvinit.
>
> For either /run or /mem I see three possibilities for the boot process
> that differ in assumptions, restrictions and features. (Please read /run
> instead of /mem below if you feel the only sensible purpose of /mem is
> /mem/run, so that just having /run is enough).
>
> A: rcS.d scripts may assume /mem to be ram-based (that's probably too
> much to ask)
>
> 1. mount /mem as some ram-based fs
> 2. check root fs and mount -o remount /, possibly rw (scripts may use
> /mem for temporary storage and /etc/mtab -> /mem/mtab will be correct
> from the start)
> 3. check and mount all local fs'es, if any, possibly rw
> 4. bring up network; scripts may use /mem; state will stay
> 5. mount all network fs'es
> 6. copy a skeleton from somewhere in /var to /mem so that later started
> services may assume directories or empty files to be available;
> possibly from a network fs
Why not use /etc/mem-skel/ as skeleton and /var/something for actual
states from the last boot (although I don't realy see a point in
restoring and saving thing from/to /var, why not use var instead)
> + simple
> + root- and local fs check scripts have temporary storage available
> + mtab always correct
> - requires existence of some ram fs in kernel
> - limits admin's freedom to put /mem on a real fs
>
> B: require /mem to be either ram-based or on a writable /
Basically same as A but describes how to make a 50% correct mtab.
> C: allow /mem to be either ram-based, on a writable /, or as a symlink
> to /var/mem if /var is local
>
> 1. check root fs and possibly remount rw (no temporary storage)
> 2. check and mount all local fs'es, if any, possibly rw (dito)
> 3. optionally mount /mem as some ram-based fs, otherwise clear /mem
> 4. create a 99% correct mtab using cp /proc/mounts /mtab ;
> mount -o remount /
> 5. bring up network; scripts may use /mem; state will stay
> 6. mount all network fs'es
> 6. copy skeleton from somewhere in /var to /mem
>
> + doesn't need ram fs or writable /; /var may be only writable fs on
> system
> - more involved
> - mtab doesn't contain mount options for local fs'es other than /
Very evil.
Why should /mem be ram based? Any writeable fs would do for ABC. For
people who only want one writeable fs how is the following option D:
D: /mem might exist in /etc/fstab
1. check root fs and mount -o remount /, possibly rw
2. mount /mem if present
(3.) clean /mem/state
4. cp /etc/mem-skel /mem/
5. remount / and /mem to correct /mem/state/mtab
6. check and mount all local fs'es, if any, possibly rw
7. bring up network; scripts may use /mem/state; state will stay
possibly accross reboots
8. mount all network fs'es
9. copy reboot resistance states from /var/state-store if thats wanted
(10.) copy /var/state to /mem/state and mount bind /mem/state to
/var/state/ unless they are the same (would it hurt to
otherwise?). Any non boot essential software can keep using
/var/state.
If /mem exists in the fstab it must be rw, if it doesn't / must be rw.
+ /var and /mem can be the same fs (so one rw fs is enough)
+ all mount options are correct
+ /mem can be any local fs thats writeable
+ /mem can be missing
- eigther / or /mem must be local (so what?) or nfs-root writeable
- mount and ipup/down must be changed slightly (same as ABC)
MfG
Goswin
Reply to: