livecd July 2007

livecd@lists.fedoraproject.org

33 participants
36 discussions

F7 general question about livecd-creator and timezones
by Skunk Worx 01 May '09

01 May '09

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

3 3

Revised: [PATCH] turboLiveInst - improves livecd/usb installer speed by 15-20+%
by Douglas McClendon 07 Sep '07

07 Sep '07

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

5 17

[PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686
by Douglas McClendon 21 Aug '07

21 Aug '07

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

5 15

Adding files into the CD root file system
by Alexandre Magaz Graça 20 Aug '07

20 Aug '07

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

5 6

RFC- improving livecd installer efficiency
by Douglas McClendon 13 Aug '07

13 Aug '07

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

4 15

LiveUSB to LiveUSB with F7?
by C S 06 Aug '07

06 Aug '07

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

4 7

Pushed a few changes
by Jeremy Katz 27 Jul '07

27 Jul '07

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

2 1

[PATCH] --addXdir , facility to easily add external directories to target sysrootfs OR isofs
by Douglas McClendon 26 Jul '07

26 Jul '07

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

2 6

[PATCH] --turbo-liveinst improves livecd installer speed by about 20%
by Douglas McClendon 25 Jul '07

25 Jul '07

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

2 3

boot problem
by jhon choptieso 25 Jul '07

25 Jul '07

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

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

livecd July 2007