Douglas -
Thanks again for the reply.
Douglas McClendon <dmc.fedora@filteredperception.org>
wrote:
> Message: 1
> Date: Fri, 25 Jul 2008 23:53:41
-0700
> From: Douglas McClendon <dmc.fedora@filteredperception.org>
> Subject: Re: [Fedora-livecd-list]
Re: How do I save and restore my
>
overlay?
> To: fedora-livecd-list@redhat.com
> Message-ID: <488AC9F5.5060905@filteredperception.org>
> Content-Type: text/plain; charset=ISO-8859-1;
format=flowed
>
> martin.x.long@jpmchase.com wrote:
> > Douglas McClendon <dmc.fedora@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 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 sequence.
bash-3.2#
=================================================
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
> > 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
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 work with.
>
> 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.
What I know of the LiveUSB file structure
is not yet WiKiworthy.
Are my assumptions correct regarding
squashfs.img and overlay-FEDORA-3099-53F2?
>
> -dmc
>
Thanks Again
Martin
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 and affiliates.
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 for disclosures relating to UK legal entities.