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