I follow the Article at:
Great job by the way, and got my 1GB USB booting the
Live Version of Fedora 7. This is after see some of
the guys at the linux meeting in Huntsville, AL
running Ubuntu in a similar way.
After add my own user and tweak the network and some
minor changes and add on rpm's noticed on my next
reboot the fact that the changes did not got saved.
Last night talking about the subject, a friend told me
he can save his data with Ubuntu and find out there is
"According to official web page you need to use
casper-rw lable instead of casper-cow."
I wonder if you have some ideas on how to get this
done, I'm a RedHat Junkie, and don't like the idea to
switch to another distro.
Attached is a revised version of my turboLiveInst patch to livecd-tools and
This version is more polished. I.e. bugs have been fixed, complexity removed,
and therefore should be easier to review.
I performed some anecdotal performance tests, on a sony vaio vgn-n250e. I used
a 30G destination volume for all tests, and when using usbstick media, it was
media that reported 8.5MB/s from hdparm -t. I did have selinux disabled, and
did not use the prelink option. I'd love to hear performance numbers from
differing test rigs.
The performance results I got were-
install from cdrom without turboLiveInst:
install from cdrom with turboLiveInst:
install from usb without turboLiveInst:
install from usb with turboLiveInst:
On this testrig, installing from cdrom, turboLiveInst yielded a 20% speedup in
copy, which resulted in an end to end install speedup of 15%. Installing from
usb, turboLiveInst yielded a 29% speedup in copy, which resulted in an end to
end install speedup of 20%.
I did test copy-to-ram mode, and the resulting benefits were laughably huge.
But this is only because this laptop has 1G of ram, and very strange behaviour
occurs this near the threshold of having too little ram to use this feature.
Though this is still an argument in favor of turboLiveInst, in that somehow it
found itself on the better side of the threshold. I would expect that with 2G
of ram, the benefit would be on the order of 35-50% speedup, as the main thing
masking the benefit in the cdrom case, is the slow access to install media,
which hides the benefit of cutting the needed disk writes nearly in half.
The secondary benefit of turboLiveInst is that it removes the artificial
limitation that the target rootfs must be greater than 4.0G, instead of the 2.1G
actual uncompressed size of the contents of the LiveCD.
Jeremy has pushed back against this patch because of complexity. Hopefully this
round of polishing will make the patch much easier to read and understand. In
addition, since the cleanupDeleted patch which this one depends on has already
been merged, that should also make this a bit more palatable.
Jeremy also brought up the idea of doing a file level copy installation, rather
than the current block level mechanism. This _is_ a good idea, in my opinion,
in that it will more intelligently support situations such as a separate /usr
filesystem. In addition there is no way that turboLiveInst or the existing
block level mechanism can be made to support xfs or other non-ext3 destination
filesystems chosen by the user (should those options return).
But- I would argue that file level installations may suffer badly due to cdrom
seeking. I would also argue that there is no reason why turboLiveInst, could
not be the first choice for installation technique, with fallbacks to file level
copies for the seperate /usr and xfs type scenarios.
Ultimately I just hope that turboLiveInst gets serious consideration for F8, via
performance comparison with whatever other options may exist.
Finally, here are some notes on the architecture, which may help you to
understand the code-
As I mentioned in the original patch, the basic idea is to simply, at
livecd-creator build time, use a device mapper snapshot to generate a delta file
between the 4.0G filesystem housing 2.1G of data, and a 2.1G filesystem holding
the same data. Then at anaconda/liveinst time, that delta file is used to
recreate a virtual image of the 2.1G filesystem, so that it can be copied to the
installation target, rather than the 4.0G filesystem which includes 1.9G of
zeros that needn't be written to disk.
I ended up using /dev/loop118 in the initramfs init (mayflower generated) to
expose the delta file. /dev/loop118 was mknod'd already by mayflower, but not
actually used for anything. I used it to expose the delta file (osmin.tgz),
because /dev/loop121 was being used to expose the 4.0G os.img, and it seemed
simplest to use an identical mechanism to expose that data. Because by the time
anaconda runs, the original cdrom and squashfs filesystems have been lazy
unmounted, a simple cp at that time was not an option(?).
I chose to extract the delta file (osmin, a 16MB sparse file containing 1.2M of
data, compressed to 25kb on cdrom) into /dev/shm (i.e. ram) so that reads from
it would not try to go to the cdrom. This may not have been necessary.
I chose to calculate the size of the filesystem at livecd-creator time, and
include it with osmin as osmin.size(together forming osmin.tgz). This is less
complex than what I did in the first pass, which was to use dumpe2fs to
calculate it at ananconda time.
As always, questions, comments, criticisms, and especially testers are more than
I've found a bug in how livecd-creator adds entries in isolinux menu.
There must be a newline after the memtest entry, otherwise the next
entry gets merged with this one. The attached patch fixes this.
We Downloaded Live CD for Fedora 7 from fedora official website.We are trying to run the live CD from one of DELL OPTIPLEX 320 but we are unable to run successfully .Once the kernel is loading the system got hannged and keyboard not responding.We tried google to find out the errors but we didnt get any suessful solutions.
IN The screen we are getting these messages
uncompressing Linux....Ok,booting the kernel.
After that system got hanged....
Kindly help me in this issue.. AS it is very urgent for us .We also tried with fedora 6 and CENT-OS 4.4 live cDs but we faced the same problems...
I follow this list and have read the README and Wiki, but
I still have questions. To start, is there any documentation
other than the sources (the README and Wiki are pretty sparse).
Most of my questions are detailed and not x86 mainline :-)
For example, I'd like to use my own local repositories (I
work with custom systems that aren't 100% in the public trees).
How do I modify the kickstart file to handle this?
Also, I'm interested in building a LiveCD for PowerPC (that's
my target base). I assume that I need to do this from a PPC
host? Is there any other magic required?
n.b. I'll be using the version from rawhide, as the FC7
release version is ExcludeArch ppc :-(
Gary Thomas | Consulting for the
MLB Associates | Embedded world
I noticed the recent commit that enables usage of swap partitions
automatically. I'm not so sure this is a good idea. This seems like it
would break the case, of me having F7 installed, downloading and burning
the f8(t3)-livecd iso, doing a pm-hibernate, and then booting
f8(t3)-livecd, and then wanting to resume my F7 system after testing
Anybody else have an opinion one way or the other?
---- from /etc/rc.d/init.d/live in livecd-fedora-base-desktop.ks ----
+# enable swaps unless requested otherwise
+swaps=\`blkid -t TYPE=swap -o device\`
+if ! strstr "\`cat /proc/cmdline\`" noswap -a [ -n "\$swaps" ] ; then
+ for s in \$swaps ; do
+ action "Enabling swap partition \$s" swapon \$s
Just wondering if anyone else was able to boot ISOs generated by
livecd-creator recently? First off, when I try to use qemu-kvm, I get
random hangs during the bootup process (in different places; last message
might be SCSI or TCP congestion algorithm, etc).
So, I use "qemu". The images I'm generating fail to find the root
filesystem (screenshot attached).
I'm building them on Fedora 7, git head livecd-tools. This used to work, so
something regressed recently, and I have no idea what =) How would one go
about debugging this?
I'm trying to upgrade an FC4 system to Fedora 7 and thought the
Fedora-7-Live-i686.iso would be the way to do it. But after booting the
Live CD, I don't see any option or instructions or application program to
upgrade. Is there one? If so - what?
I am actually running the Live CD in a vmware virtual machine with virtual
CDRom mapped onto the iso image - it works fine but is rather slow, so not
easy for me to try experiments. Hoping someone can simply say this is
what you have to do. Pointers to relevant doc welcome. Also, if
there is a way - can I run it in the old non-graphical curses mode like the
older Fedora installers? Might be a bit faster than the graphical
interface, nice though it looks.
I saw this same question asked in the forum but with no reply, so hoping I
have a better chance of answer here. I didn't see way of searching the
list archives, so apologies if asked already.
Enter to win a night a VIP night out at TIFF
I've had these lying around for a while and had forgot to post them
here. They apply against:
Author: Jeremy Katz <katzj(a)redhat.com>
Date: Fri Aug 31 12:41:27 2007 -0400
check for isomd5sum early enough
First patch just removes and unused parameter.
Second patch refactors the resize2fs stuff so that it is substantially
easier to understand - e.g. trying to grok the binary search in
resize2fsToMinimal() is a lot easier than the original version in
There shouldn't be any functional changes, though ...