Thanks again for the reply.
Douglas McClendon <dmc.fedora(a)filteredperception.org> wrote:
Date: Fri, 25 Jul 2008 23:53:41 -0700
From: Douglas McClendon <dmc.fedora(a)filteredperception.org>
Subject: Re: [Fedora-livecd-list] Re: How do I save and restore my
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Douglas McClendon <dmc.fedora(a)filteredperception.or wrote:
> >If that doesn't help or answer you question, try to add more detail
> >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
> make sure it still boots, then I shut down. I boot a system on
> of Fedora 9 on the hard drive and plug in my Live USB so I can
> files on my USB stick.
> I see 2 folders:
> in the LiveOS folder I see three files:
> 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
> 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
> > copy the overlay file from one liveusb and put it on
> > the format of the overlay file is inherently tied to the
> > it was originally with. I.e. you won't be able to
copy an overlay
> > from an f9-x86 liveusb onto an f9-x64 or f10-x86 liveusb.
> > customized f9-x86 liveusb that you created with
> Nothing fancy - The same USB stick, built in the same way with the
> iso and the same overlay size.
> The overlay file name changes. I've given the updated file (the
> that was part of the LiveUSB for all of the updates) the same
> the new file that is created and left the updated file with its
> name. I've overwritten just the overlay itself and the
> 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 always build from the same .iso using a script so everything is built
identically. The overlay file name does change every time though.
> I could never get it to boot. The boot starts but then hangs.
What is the last thing you see when it hangs?
Decompressing Linux... done.
Booting the kernel.
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Assuming drive cache: write through
WARNING: Cannot find root file system!
Create symlink /dev/root and then exit this shell to continue the boot
I can't find the symlink command anywhere in this limited recovery shell.
I don't know where this little root directory is so I can move commands
and scripts into it (before I back up) to help me recover or avoid banging
out to this shell.
> 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
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
> 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
I actually started with something like this only created an output file of
/usr/MLONG01/usbiso. This was ok with my 1 gig stick but it was to small
to install apps and run updates, so I upgraded.
I could actually restore a bootable USB from that file which would work in
a pinch. The problem is that I'm using a 16Gig USB stick and my back up
files would be 16Gig each and take hours to create and restore. It
actually takes longer than building the bootable USB and running the
updates. On the plus side I can do a restore without an internet
connection or interaction. Unfortunately, these files are just too big to
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
> > fstab, such that say, /mnt/data mounts to a ext3fs image
> > file on your liveusb. You can then add a user that has a
> > under there, and perhaps install applications under there.
> > you could then copy that ext3fs image file to an f10
> > only have to re-do the fstab and passwd modifications,
> > 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
What I know of the LiveUSB file structure is not yet WiKiworthy.
Are my assumptions correct regarding squashfs.img and
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures
disclosures relating to UK legal entities.