[Fedora-livecd-list] [PATCH] persistence - VERY ROUGH first pass

[Jeremy Katz]

On Tue, 2007-07-24 at 17:30 -0500, Douglas McClendon wrote:
> Jeremy Katz wrote:
> > On Tue, 2007-07-24 at 03:43 -0500, Douglas McClendon wrote:
> >> The Principals Of OPeration are-
> >>
> >> - unless a boot argument of "persistence[=[devspec][:pathspec]]" is seen, 
> >> nothing will behave differently, except for the existence of a new tool 
> >> /usr/sbin/livetool
> > 
> > Sounds good for now; we'll almost certainly want to make it default to
> > automatic eventually with the option being to not do it.  
> 
> The only reason I would put up front as to not do it by default, would be adding 
> boot time to _every_ livecd boot.  But it may well be that the mount scanning 
> only takes <2seconds, in which case, making it default might seem ok.

The time will end up depending on how many devices you have.  I suspect
the benefits of being able to have it just work will outweigh the
increase in boot time.  We just then have to find up ways to counter the
increase by making other things take less time ;-)

> >> - devspec can be in the following forms (should be obvious what they mean),
> >> and defaults to auto, which means to search all mountable partitions.  (the 
> >> search process mounts readonly (with paranoid blockdev --setro as well)
> > 
> > blockdev --setro is an awesome idea.  Having to use fuse for ntfs is
> > annoying at best, fragile if we go further.  How much is it really worth
> > to be able to have it on ntfs?
> 
> Honestly it was entirely frustrating last night trying to use it.  But for the 
> next iteration at least, I'll try to keep in there.  I admit this is a very 
> debatable point.  Speaking of which, there is a HUGE ISSUE that maybe people can 
> chime in with advice on-
> 
> How do I detect that a filesystem has not been cleanly unmounted?  (ext3? ntfs? 
> vfat??)

It's filesystem dependent and I don't know of any utilities that just
generally expose it.  

> It seems like the right thing to do is to consider not cleanly unmounted 
> filesystems as offlimits (especially because they may be part of a hibernated 
> system).

Hmm, hibernation is a good point.  We can detect if the system has been
hibernated (from Linux) at least -- look for a swap with a signature of
S2SUSPEND.  And then we could not do so.

> >> 2) ext3's inability to mounted readonly is annoying (yeah, I know norecovery or 
> >> ext2 will probably get it for me, still annoying)
> > 
> > Yeah -- what happens when you try to mount it with the block device
> > read-only and a dirty journal?
> 
> "EXT3-fs write access unavailable cannot proceed"
> 
> As mentioned, ext2 or norecovery will probably get around this though.  It's 
> just going to make the mount scanning code ugly to have to massively special 
> case each filesystem type.  Like for instance mount.ntfs not supporting the -n 
> flag.  It _seems_ like "mount -n -o ro -t auto" ought to work for the generic 
> case (without blockdev --setro).  But I guess thats asking too much at the moment :)

kzak is trying to build up some momentum around a revived util-linux
upstream, so it might be worth talking with him about it.  It probably
will come down to having to special case things, though :(

> >> 3) choice handling is broken.  Don't use auto when it will find more than one 
> >> entry.  Maybe just don't use auto at all.
> > 
> > We definitely want auto.  With more than one entry, maybe we should just
> > bail?  Asking for input is bound to be tricky given things like USB
> > keyboards
> 
> Agreed.  This was only because I got frustrated coding in a hurry last night. 
> If the USB keyboard thing is an issue, I can go back to my original thought, 
> which was to have a timeout on the choice, and bail (=overlay-in-ram-as-normal) 
> if no option is given.

If there's a choice, then falling back to no persistence is definitely
the sane thing to do

> Anybody have any ideas on how to implement a ticking counter on a bash read 
> prompt?  ('read -t 60 choice' will work, but I'd like to have a ticking counter 
> if possible)

There's some countdown code in mayflower -- search for COUNTDOWN

Jeremy