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

[Douglas McClendon]

Jeremy Katz wrote:
> On Tue, 2007-07-24 at 03:43 -0500, Douglas McClendon wrote:
>> Attached is a _first pass_ patch that enables LiveOS persistence for 
>> livecd-tools.  Before you read this and get _too_ excited, note that I'm really 
>> only posting this because of the f8t1 devel freeze.  If I get any encouragement, 
>> I am very willing to work my ass off in the next few days to get this cleaned up 
>> into respectable shape for a potential f8t1 feature.  But I also realize it is 
>> probably just too late for that. (OTOH the code is already structured so that it 
>> is obvious that in the absence of a persistence bootarg, the code has no impact)
> 
> Given where a few things stand[1], I'd prefer to hold off until
> post-test1.  Although this definitely looks like a good start

agreed.  Definitely would have felt more test1 worthy if it had been polished 
and tested and used for at least a couple weeks.

> 
>> 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.

And actually, I've got a different feature I've been working on for Elias Hunt, 
that could work well with the mount scan as well.  (caching the 
iso/sqfs/ext3fsimg to disk)


> 
>> - after booting normally (no persistence bootarg), if you invoke
> 
> As long as nothing has been found, it should be fine to do this, no?
> Also, instead of using the label as the key, we might want to go for
> something better and UUID based.  I'm just a little worried that labels
> aren't unique enough.  

But UUIDs are just SO UGLY ;)  But you are technically right.  For my next 
iteration, I'll use both,  i.e. default becomes /LiveOS/Persistence-LABEL-UUID

Mainly having the label makes an ls in the directory actually somewhat 
intelligible to the user.



> 
>> - 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 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).


> 
>> - pathspec defaults to /LiveOS/Persistence-LIVEOS_LABEL
>> (e.g. /LiveOS/Persistence-Fedora-7-Live-i386)
>>
>> if pathspec does not start with a /, it prepends the above default.
>> (e.g. persistence=:dmc would mean to search all partitions for 
>> /LiveOS/Persistence-Fedora-7-Live-i386-dmc)
> 
> Per above, I think that we want to have it tied to the UUID of the live
> image.  At which point, specifying it becomes more for
>  * Putting it buried somewhere on the filesystem other than /LiveOS
>  * Handling multiple persistence on the same media
> The first I can sort of see... the second seems like it's probably less
> useful.  Especially once the label isn't the important part

See above.  I agree with the why you presented.  But I can see more of a 
use-case on the second.  We'll see what people on this list think and do once 
the patch is actually polished and tested a bit.


> 
>> Finally: Known bugs:
>>
>> 1) I had to comment out the mayflower generated init's trap and set -e
> 
> It might be worth integrating directly into the mayflower init.  I'm not
> opposed to keeping it separate, though.  Keeping it separate might
> actually help a little as I try to spend some time to get us to a more
> stock initramfs

I'll keep it seperate for now.  Once it starts getting to the point of merge 
worthy you can let me know what you prefer.


> 
>> 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 :)


> 
>> 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.

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)

> 
>> Well, that about covers it for now.  As always, comments, suggestions, and 
>> criticisms will be greatly appreciated.  (though feel free to wait 48 hours for 
>> plenty of obvious improvements, such as fixing those known bugs).
>>
>> "release early, release often"...
> 
> Thanks for getting a good start on this!
> 
> Jeremy
> 
> [1] Having to fight entirely unrelated things to get working images spit
> out just due to distro flux

Yeah, I know you and jkeating have lots on your plate.  This is definitely 
nowhere near a candidate for f8t1.  But if the deadline helped motivate me to 
get something done, all the better ;)

-dmc