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

[Jeremy Katz]

On Mon, 2008-02-04 at 23:42 -0600, Douglas McClendon wrote:
> 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-

My plan is working ;-)  Just kidding...

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

Yeah, if we can't go back into the initramfs (which, yes, may not be
possible given our use of mount --move), then we'll have to come up with
some better trickery for the halt side.  I need to corner notting this
afternoon and see what thoughts he has on it as initscripts/init is all
his territory and he's in the middle of reworking some of it for upstart
anyway

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

You can't (successfully) do a pivotroot from an initramfs iirc.  

Jeremy