[Fedora-livecd-list] Re: How do I save and restore my overlay?

[Douglas McClendon]

martin.x.long at jpmchase.com wrote:
> 
> Douglas McClendon <dmc.fedora at filteredperception.or wrote:
> 
>  >If that doesn't help or answer you question, try to add more detail to
>  >your question.
> 
> Douglas -
> 
> Thanks for the reply.  
> 
> I use the live usb tools to create my live USB stick with a 2047 MB 
> overlay.  I boot from it and let it run updates. I reboot the LiveUSB to 
> make sure it still boots, then I shut down.  I boot a system on a copy 
> of Fedora 9 on the hard drive and plug in my Live USB so I can see the 
> files on my USB stick.  
> 
> I see 2 folders:
> LiveOS
> and
> syslinux
> 
> in the LiveOS folder I see three files:
> osmin.img
> overlay-FEDORA-3099-53F2
> and
> squashfs.img
> 
> ======
> assumptions
> 
> squashfs.img looks to be the size of the live iso
> overlay-FEDORA-3099-53F2 looks to be the size of the overlay and has 
> overlay in the file name
> osmin.img is only 8k probably a boot strap, I'm not sure.

osmin.img is part of an optimization used during the install-to-disk
process.  Interesting long story, but should not be relevant here.

> =======
> 
> I'm sorry, I can't find anything on the LiveUSB file structure on the 
> WiKi.  I've signed on as a writer for the Fedore project so I'd like to 
> write it once I figure out what it is.

Sounds like a good plan.  I don't have the free time I used to when I
was happily unemployed, but I'll try to help.


> I was hoping that I could backup the overlay file and the syslinux 
> folder from my completely updated LiveUSB stick and restore them to a 
> newly built LiveUSB from my backup.

I think this should work, but there may be some subtle wording here.
What you said almost sounds like boiling down to doing a straight
duplication of a LiveUSB, which AFAIK should work.  To the extent that
it doesn't work, we should focus on how what you are doing is different
than a pure duplication.

> 
>  > I'm not entirely sure what you mean.  One thing that is possible is to
>  > copy the overlay file from one liveusb and put it on another.  Though
>  > the format of the overlay file is inherently tied to the specific liveos
>  > it was originally with.  I.e. you won't be able to copy an overlay file
>  > from an f9-x86 liveusb onto an f9-x64 or f10-x86 liveusb.  Or even a
>  > customized f9-x86 liveusb that you created with livecd-creator/tools.
> 
> Nothing fancy - The same USB stick, built in the same way with the same 
> iso and the same overlay size.
> 
> The overlay file name changes.  I've given the updated file (the overlay 
> that was part of the LiveUSB for all of the updates) the same name as 
> the new file that is created and left the updated file with its original 
> name. I've overwritten just the overlay itself and the overlay and every 
> combinarion of the osmin.img and squashfs.img files.

This sounds reasonable.  Now, if this is a new LiveUSB built from the
same LiveCD, the osmin.img and squashfs.img should be 100% identical.
Same file sizes, same md5sums.  If they aren't, mention that.


> 
> I could never get it to boot.  The boot starts but then hangs.

What is the last thing you see when it hangs?


> Ideally, it would be great to specify the overlay and the syslinyx 
> folder that goes with that overlay in the command line to build the 
> LiveUSB.

Unfortunately the syslinux folder is hard coded and is a limitation of
syslinux (actually you get 2 or 3 choices, but not an arbitrary choice).
  The overlay file name is part of our code, and is keyed off of the
UUID of the usb disk (in this case).  I can't say off the top of my head
(it's been awhile) whether making the filename specifiable on the
commandline is trivial or not.

> 
> At this point I would be thrilled if I could get a set of manual steps 
> together to have an updated system without going through the update 
> process.  I loose a day each time.

If I find the time, I'll try to reproduce your problem.  An absolute
brute-force method that should work for identical sized usbsticks would
be a bit for bit copy.  I.e. if you set up one 4G LiveUSB and it works,
you should be able to plug it in, and if it is seen as perhaps /dev/sdX
and then you plug in another 4G usbstick seen as /dev/sdY, you should be
able to run

dd if=/dev/sdX of=/dev/sdY

and get a working clone.  (note, you may have the partition visible as
/dev/sdX1, but use the whole device as above for the duplication).

> 
>  > From an engineering standpoint, of course anything is possible.  One
>  > use case I see, is to use the persistence feature to add an entry to
>  > fstab, such that say, /mnt/data mounts to a ext3fs image located on a
>  > file on your liveusb.  You can then add a user that has a home directory
>  > under there, and perhaps install applications under there.  In this way,
>  > you could then copy that ext3fs image file to an f10 liveusb, and then
>  > only have to re-do the fstab and passwd modifications, such that
>  > everything now pretty much looks the same.
> 
> Your suggestion of building a file structure that would transcend 
> different releases would be awesome but alas I need to crawl before I 
> can run.
> 
> Any help would be greatly appreciated.

Hope the above helps.  And as mentioned, if I find the time, I'll try to
reproduce your less brute-force method of copying, which sounds pretty
reasonable, but clearly isn't working for some reason or another.

And just post any wiki/work-in-progress and I'll be happy to provide
feedback.

-dmc