F7 general question about livecd-creator and timezones
by Skunk Worx
My ks scripts have the timezone set to PDT (America/Los_Angeles).
Installation to a hard drive works as expected. PDT in startup and in
shells, etc.
Creating a livecd-creator iso with the same tz setting, then booting,
shows A/L_A in the /etc/sysconfig/clock file, as expected.
However the date is always EDT in the boot messages, shells, etc.
During startup I see :
(lvm)
Press I to enter interactive startup
Setting clock (utc) Mon Jun 4 00:12:59 EDT 2007
(udev)
I'm not clear on what is happening between lvm and udev in the Linux
startup sequence.
If someone could give me a hint about what to look for and where to look
for it I would appreciate the help.
---
John
14 years, 7 months
Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+%
by Douglas McClendon
Attached is a revised version of my turboLiveInst patch to livecd-tools and
anaconda.
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:
copy: 250s
postinst: 86s
install from cdrom with turboLiveInst:
copy: 299s
postinst: 84s
install from usb without turboLiveInst:
copy: 226s
postinst: 72s
install from usb with turboLiveInst:
copy: 175s
postinst: 72s
Conclusions:
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
welcome.
peace...
-dmc
16 years, 3 months
[PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686
by Douglas McClendon
Attached is a patch.
It could be broken into two patches for clarity. Please review and apply if
appropriate.
patch#1: add --container-size flag
Using this flag, one can cause the os.img that sits in the squashfs.img, to be a
larger sparse file than the filesystem contained in it. By default, the old
behavior happens. One somewhat unrealistic, but real justification for this,
would be booting a livecd on a system with 16G of ram. Without this flag, you
would be limited to only writing 2G of data (given the existing f7-livecd-i686
choice of a 4G uncompressed-size, and about 2.1G of data). With this flag and a
container of say 1T or 100G, there would be no negative consequences, but the
livecd user would be able to online resize2fs their root filesystem upward if
they liked.
The more realistic usefulness comes if through a persistence implementation, the
overlay file is not a 512M file stored in tmpfs, but an 8G file stored on an
ipod. Everything mentioned above applies.
patch#2: add --cleanup-deleted flag
Using this flag, about 25% is added to the build time, but any files that were
created and deleted in the install_root during installation, will not result in
wasted space on the resulting iso. This happens because of the nature of the
filesystem living on a sparse file. Anecdotally, this could be used to respin
the fedora7-livecd-i686, from its existing 700MB, to 664MB. Or more likely, add
another 100MB or so of uncompressed software onto it.
This is of even greater importance as people spin their own livecds, and do
intensive things during the installation, that might cause even more wasted space.
Also, this somewhat lays the foundation for a 'turboinstaller' that improves
current liveinst efficiency by 10-25% (for cdrom vs usbflash respectively), as
mentioned in bug 248082 (pending efficiency tests with extra device mapper layers)
Please review. Any comments, suggestions, or criticisms are welcome. I still
consider myself a relative novice when it comes to python.
peace...
-dmc
16 years, 3 months
Adding files into the CD root file system
by Alexandre Magaz Graça
Hi,
I'm making a LiveCD that I want to autorun (from Windows and Linux) to
open a browser showing some help about how it works. So I added a new
option that lets add to the CD root file system.
If someone finds it useful, the attached patch adds this option to
pilgrim. The patch is for the latest git version.
Cheers,
Àlex
16 years, 3 months
RFC- improving livecd installer efficiency
by Douglas McClendon
Question: Does the current livecd installer inefficiently write lots of 0's to
the destination drive that it doesn't need to?
I think it might. The os.img on the F7 livecd is a 4G sparse file with about
2.3G of data. Anaconda's livecdcopy backend uses python's os.read/write. I
would guess that that means that 4G of data is getting written, when
theoretically only 2.3G needs to.
The solution that comes to mind is this-
in livecd-tools, create the os.img as a 7G (or 700G??) sparse file. Basically
just way big. Then take care to make the ext3fs be the exact correct size for
the data (i.e. 2.3G). Then, in the initramfs, just after mounting it (after
snapshotting it), do a resize2fs to 7G (or 700G).
Then when anaconda does the copy, only copy the first 2.3G of the sparse file.
It is however late in the 'day' for me, so maybe someone can chime in with
confirmation or refutation of my logic here.
-dmc
16 years, 4 months
LiveUSB to LiveUSB with F7?
by C S
All references I can find for spinning have a running
host(with rpm, yum, etc) as a requirement to build
live's upon. But is it possible to have
livecd-creator spin a new CD off of F7's Live itself?
I assume Revisor would only build upon this.
Being a newbie I didn't know if it's in the design,
plan or not possible at all...
cs
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
16 years, 4 months
Pushed a few changes
by Jeremy Katz
I threw together a few little changes today and pushed them into the
repo. You can now use $basearch as your repo URL (or in the mirrorlist
URL) and the right thing should happen. Also, if you include memtest86+
in your manifest, it should land in the boot loader config. Finally, if
you put kernel-xen in your manifest, that should now work.
And with that, I'm out for the next week. dmg -- I'll look some more at
the turboinst stuff when I get back. I also want to try to get the
persistence and other arch bits in pretty soon then.
Jeremy
16 years, 4 months
[PATCH] --addXdir , facility to easily add external directories to target sysrootfs OR isofs
by Douglas McClendon
attached is a patch which gaging from the history of this list, will be welcomed.
I know there may already be some similar functionality already in revisor, this
patch adds it to livecd-tools
The two new options are
--addidir=<directory>
and
--addsdir=<directory>
Both may be invoked any number of times. The contents of the directories
specified, will be copied to the target livecd. addsdir adds the contents to
the rootfs of the target, while addidir adds the contents to the iso9660fs of
the target.
An example might be to use this to add an index.html and autorun.bat to the iso
so that when the iso is popped in a winblowz machine, a webpage from the cdrom
will automatically launch.
The addidir copy happens just before mkisofs, so this can be used to easily
replace /isolinux/splash.jpg
The addsdir copy happens after installation, but before the selinux relabel and
optional prelink.
These semantics are up for debate. Test and enjoy...
As always, comments, criticisms, suggestions are welcome.
-dmc
16 years, 4 months
[PATCH] --turbo-liveinst improves livecd installer speed by about 20%
by Douglas McClendon
Attached are a couple of rough alpha quality patches.
They implement what I have described rather verbosely on fedora-livecd-list and
in bug 248082.
The short story is the fedora7 livecd installer works by copying a 4G ext3 image
to the destination rootfs, and then resizing to maximal size.
The attached patches improve the speed of this step by 10-30% (for cdrom vs fast
livecd-iso-to-disk'd usbflash install media respectively).
This is accomplished because the 4G image actually only holds 2G of data. The
patch to livecd-creator, when invoked with --turbo-liveinst, will create a small
(25kb) binary delta file on the livecd. The patch to anaconda, will detect the
presence of the file, and if it is there, use it with devicemapper to create a
2G ext3 image, which can naturally be copied to the destination volume more
quickly. (I.e. 2G of zeros don't get written to disk).
In addition to improving installation speed, this also results in rootfs volumes
of 2.1G->3.9G being supported.
This patch is less than polished and elegant. But I'm hoping it might make it
into f8t1. Please review, and give suggestions for improvements. I'll plan on
trying to clean it up in whatever ways seem best over the next couple of days.
These are patches against current livecd git and anaconda cvs snaps. I think
they will work (very limited testing so far), but mainly I post them to get
eyeballs and brains looking at the code and the idea. No doubt within 24-48
hours I will post a more respectable looking patchset that I hope more people
might be willing to test.
(note, the cleanupDeleted patch I just posted to livecd-tools is included here,
as it lays the foundation for this... as well as reclaiming lots (5-15+%) of
wasted space on the livecd)
-dmc
16 years, 4 months
boot problem
by jhon choptieso
greetings.
I have boot problems. I used kadischi to build my liveCD.
Here the log:
#qemu -m 256 -cdrom fedora-live.iso
...
losetup: failed to open /cdrom/kadischi.sqsh: No such file or directory.
...
kernel panic.
No such file or directory... some idea about why it passes that?
--
jhon choptieso
16 years, 4 months
