[Fedora-livecd-list] Re: Review? LiveUSB persistence

[Douglas McClendon]

Jeremy Katz wrote:
> On Mon, 2008-02-04 at 18:51 -0600, Douglas McClendon wrote:
>> Jeremy Katz wrote:
>>> Outside of those changes, everything looks pretty straight-forward and
>>> reasonable.  We'll want a little more error checking in
>>> livecd-iso-to-disk and it might also be nice to have another tool that
>>> lets you create your usb stick to use with the actual cd form (I did
>>> this by hand and it was pretty nice that I could easily get it
>>> working!). 
>> I didn't really slow down and read this bit at first-  So you actually 
>> used the livecd+usb form?  I probably tried that once when I first wrote 
>> the code, but haven't even considered it since then.  I guess you must 
>> have by hand added something like overlay=UUID=bla to the kernel 
>> cmdline.  Of course the original incarnation of the patch supported the 
>> syntax overlay=auto which would scan all drives.  But that code scares 
>> my responsibility-averse nature, and I was happy to remove it when 
>> focusing on the liveusb case.  And also there was a bunch of related 
>> bash junk for dealing with finding multiple overlays.
> 
> Yep, I remember the auto bits as well.  While at the time, I think I was
> pushing you towards it, I think I'm now with you on the being
> conservative.  It was pretty easy to set up to use an external drive,
> though.  I had a partition with a dos filesystem, created the
> LiveOS/Fedora-8-Live-i686- file and booted with overlay=LABEL=foo (which
> was the label of my filesystem).

So now that you're threatening to merge the code...  reviewing it myself 
I see that-

One obvious error is that in the halt teardown code, I assume the 
overlay device is /dev/live.  This is only true for the LiveUSB case, 
and my seemingly pointless use of a variable to store /dev/live, shows 
that I was somewhat aware of the issue.  The right answer might be the 
need to add another udev rule to the initramfs so that the overlayfs 
device can be known at halt time.  I would say that because I think 
there might be no guaranteed way to determine the FS holding the file 
associated with a loop device (because losetup -a output may be 
truncated, and I don't know of another way?????)

Other than that, I don't actually see anything too ugly.  Probably the 
selinux permissifying in the teardown should be tested to see if it is 
really needed.  It's possible I just messed up my labels in some prior 
version.  Or, it's possible that the right answer is to change the 
selinux policy to allow whatever it was disallowing.

As far as your statements about doing teardown from initramfs...  One 
thing I had wanted to do was to make the initramfs mount visible later 
on.  This was to be able to watch the size of the overlay sparse file. 
My way around the need for that was to create a new tmpfs just for it. 
But what you see in the code ('nobwa') is that currently there is a 
devicemapper bug I'm hitting if I try to do that.  (I have a 
reproducibly indeterminite example I need to make the effort of 
attaching to the bug report).  But digressing a bit...  To see the 
initramfs, I think you might have to change nash so that it goes back to 
using pivotroot instead of mount --move.  And then presumably hook into 
halt so that at the end, it fires off something from the initramfs 
again.  Or I guess, you could copy your initramfs stuff to a new tmpfs, 
and not need the pivotroot thing.  But the pivotroot thing seems more 
natural.  But I have no idea why that got changed to a movemount (just 
to hide the mountpoint, or some other issue?)


-dmc