[Fedora-livecd-list] /etc/statetab and persistence

[Jeremy Katz]

On Sat, 2007-08-25 at 18:39 -0500, Douglas McClendon wrote:
> Jon Steer wrote:
> > I just noticed that there is apparently a /etc/statetab which allows
> > you to specify directory paths to load from other sources upon bootup.
> > 
> > So, on a liveCD,mounting /etc or mounting /var on another partition,
> > especially on USB keys would work pretty handily.
> > 
> > What am I missing?
> 
> Well, the statetab presumably must live on a version of /etc that gets 
> mounted over then.  And in the livecd case, you wouldn't want the 
> initial statetab to point somewhere else for /etc.  And given that, it 
> is kind of hard to modify after the fact.
> 
> But it wouldn't be hard at all to have some sort of kernel argument like 
> "statetab="/etc:/dev/sdb2,/var:/dev/sdb3" or maybe with a little more work,
> 
> statetab="/etc:LABEL="myipodstate":/path/to/etc"
> 
> which would cause it to mount -t auto the filesystem labeled 
> 'myipodstate' and then bindmount /path/to/etc from there to /etc.
> 
> The main downside I see over what I've been trying to do with 
> dm-snapshot, is that
> 
> a) you would have to store the entire /etc on the persistent storage.
> b) /usr would then not be persistent, thus making 'yum -y install emacs' 
> not work like you want it to.
> 
> But for a subset of the problem, it definitely works.

Yeah, I'm not sure how well it really works for /etc or /var with the
live image given those caveats.  For /home it could work nicely, but
really, at that point, you're almost better off just mounting something
as /home.  Which, I guess, points to a super-simple /home persistence
that we could do...  just add to the livecd initscript something like
(excuse my terrible pseudo-shell here)
  if [ -e /dev/disk/by-label/$(ROOTLABEL)-home -a ! `strstr
nohomepersist /proc/cmdline` ]; then
    mount /dev/disk/by-label/$(ROOTLABEL)-home /home
  fi

It could even handle it being an encrypted device pretty easily since
the support for referencing a luks device by label or UUID is in now
iirc

> And as mentioned before, another dirt simple solution would be to just 
> have tarballs stored on a usbstick, and then have the boot process 
> extract them into the ram overlay automatically if it finds them.  That 
> also would be a quick and dirty way to accomplish a lot of things.

Yeah, things like this definitely can work.  They just (unfortunately)
don't lend themselves to being very easily "discoverable" by more
ordinary end-users

Jeremy