livecd August 2007

livecd@lists.fedoraproject.org

28 participants
52 discussions

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

installer efficiency - sparse hackery
by Douglas McClendon 20 Aug '07

20 Aug '07

Out of curiosity Jeremy, in your envisioned sparse-feature method alternative to turboLiveInst- How do you envision detecting which 0s in the file are legitimate data that needs to get written to disk, and which are unnecessary unwritten parts of the file? I took a look at the tar --sparse documentation, which suggests that it handles sparseness by doing a complete extra read of the whole file, to detect 0s. As mentioned, because what you are talking about is _not_ an actual sparse copy, there may be legitimate 0s that need to be written in our case. It seems the only way would be to write a tool, which utilizes "intimate knowledge of ext3fs filesystem internals" to detect the appropriate place of holes in the file. Can I just ask you - please - until you have a specific complete plan for an alternate solution, just go ahead and commit turboLiveInst for f8test2. If you come up with a better cleaner solution (even if only in your opinion), I promise not to utter one word of complaint after you remove turboLiveInst. I mean, you've already been down the path of suggesting a file-level copy. That turned out to have a 5X slowdown performance penalty. Now you are going down the path of this sparse copy, which is an incomplete solution, that despite what you've said, is not simply an elegant implementation of sparse support in python's shutil.copy. Rather, it is at least as much of a hack as what I did. And I maintain that turboLiveInst is not a hack, but an elegant use of devicemapper snapshot, which is the same elegant mechanism responsible for the fedora7 livecd in the first place. Getting more exposure to devicemapper shapshot usage in the developer community - is a good thing. It is a wonderful tool, that I'm sure will see many elegant uses in the coming years. Regards, -dmc

1 0

[Fwd: RE : Persistancy in livecd achieved [Patch attached]]
by Rahul Sundaram 20 Aug '07

20 Aug '07

Hi I looked for this in the list archives from the recent discussions. Sending it here again since it might have reached the list before. Rahul

2 1

LiveCD as Xen Guest, existence proof?
by Jon Steer 20 Aug '07

20 Aug '07

Has anyone managed to boot an F7 LiveCD as an F7 Xen Guest? I can boot an F6 LiveCD, but not F7. I can also boot the F7 LiveCD on VirtualBox, but not on F7 thanks, jon -- "Whereever you go, there you are"

2 2

Re: livecd persistence
by Douglas McClendon 20 Aug '07

20 Aug '07

Jeremy Katz wrote: > Had a chance to look at cleaning up the patches any? If not, I'll take > a stab the first of next week as I really want to get the basic bits in > for test2 :) I've been waiting to put turboLiveInst to rest, as my approach may involve devicemapper tricks, which I need to make sure you are comfortable with reviewing before I waste any time implementing them. Also, I need to make sure that this asdas(a)redhat.com person doesn't have useful persistence code, which I would be wasting my time duplicating if not necessary. Lastly, wouldn't test2 require an approved feature? I've been holding off myself due to no feedback regarding the attached mail -dmc ---- On Mon, 13 Aug 2007, Douglas McClendon wrote: > Any progress on this front? The F8 feature freeze is rapidly approaching. > > If I don't hear back about this issue, I'll just solicit people who have signed the CLA to put up a couple placeholder features, just so they are in place before the freeze. > > 1) livecd persistence, as mentioned on fedora livecd wishlist > > 2) improve livecd boot speed dramatically It was Luis Villa's last act before he left to draft changes to the CLA. I'll find out what the status of those changes are -- and it seems that counsel agreed to them. Max, do you know where this stands? --g ---- Greg Dekoenigsberg wrote: > On Thu, 19 Jul 2007, Douglas McClendon wrote: > >> Yeah, I figured out the CLA issue. I still haven't signed it. I hate legaleze. Maybe you can clarify- By signing that, and submitting works via channels under that umbrella, am I giving RH a license to modify my work, distribute those modifications to others, and not be obliged (ala GPL) to submit modifications back to me? Thats sort of what it sounds like, i.e. that they get as many rights as the original copyright holder (which would be those aforementioned rights). >> >> I'm sure this has been talked to death on some mailinglist or FAQ, any pointer to such a thread would be appreciated. > > You know, I'm not sure this particular reading has ever been discussed. I know that we want to make super-sure that (a) you actually *have* the right to share code with us, and (b) you can't take your ball and go home, and the CLA is structured to do that. > > I've never interpreted the CLA as giving us the right to take your work, modify it, and not give the modifications back -- but yeah, on a closer reading, that looks possible. I'll check it out with legal. Any progress on this front? The F8 feature freeze is rapidly approaching. If I don't hear back about this issue, I'll just solicit people who have signed the CLA to put up a couple placeholder features, just so they are in place before the freeze. 1) livecd persistence, as mentioned on fedora livecd wishlist 2) improve livecd boot speed dramatically -dmc > > I can assure you that's not our intent, but contracts don't really care much about intent. :) > > --g >

5 10

Is it possible to use yum setup on build host?
by Lars Bjørndal 20 Aug '07

20 Aug '07

Hello! I wonder if it's possible to use the yum setup on the machine you're using to build the livecd, instead of using the "repo" commands in the .ks file? In case it is, how do you do it? In case I need to use the repo command in the .ks file, I would like to know if it's possible to use "includepkgs=" in any way. Thank you! Lars

3 2

Get an error message with Revisor
by Lars Bjørndal 20 Aug '07

20 Aug '07

The command I ran was: revisor --cli --kickstart=/etc/livecd-console-rev.ks --optical\ --model=lrs After package download, and creating the file image, I got: Setting interval between checks to 0 seconds Traceback (most recent call last): File "/usr/sbin/revisor", line 203, in <module> revisorBase.run() File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 48, in run self.base.lift_off() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 532, in lift_off self.buildLiveMedia() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 904, in buildLiveMedia if not liveImage.setup(livemedia_targetsize, build_dir="/var/tmp/revisor-livecd", yum_installroot=self.cfg.yumobj.conf.installroot, yum_cachedir=self.cfg.yumobj.conf.cachedir): File "/usr/lib/python2.5/site-packages/revisor/pilgrim.py", line 448, in setup os.symlink("../proc/mounts", self.build_dir + "/install_root/etc/mtab") OSError: [Errno 17] File exists What could I do to fix this? Thanks! Lars

2 1

[PATCH] overlay/persistence second pass - for developer reference only
by Douglas McClendon 20 Aug '07

20 Aug '07

Attached (for real this time) is a revision to the persistence implementation that I posted a couple weeks ago. This is mainly for Jeremy, Tim, and anyone else who is interested in working on this, or something similar. I.e. at the very least, it is worth a read to look at the issues I've dealt with, and the several that are in comments as TODO. It may well be that a simpler persistence implementation that involves just extracting tarballs from usbsticks into the normal ram overlay, may be useful instead of (or even in addition to) this kind of implementation. (or perhaps some implementation of unionfs will make it into fedora eventually?) The main points of note, since the first post are- - all sorts of bugs fixed - I moved the overlay storage filesystem to be visible as /mnt/overlayfs always. This solves some aspects of the current problem of not easily being able to see how much writable space you really have available on the rootfs. (the real answer is a combination of the device mapper overlay file AND the filesystem it resides on). - I've included modified /etc/rc.d/init.d/halt and functions, to handle getting things cleanly shutdown (which is VERY important) - ntfs is somewhat present, but not really working. I have tested with vfat and ext3. Note that ext3 is a PITA when not cleanly unmounted- see TODOs. - rudimentary testing of the choice selection when multiple possible overlay images are detected suggests it works. - the patch format merely reflects my educational process with git, and not that I suggest that code this immature is anywhere near ready for merging. (i.e. inclusion of halt&functions and the origs I based them off of. Refer to list archives for documentation on how to use addidir/addsdir if needed) As always, comments/criticisms/suggestions are more than welcome. peace... -dmc

1 0

[PATCH] overlay/persistence second pass - for developer reference only
by Douglas McClendon 20 Aug '07

20 Aug '07

Attached is a revision to the persistence implementation that I posted a couple weeks ago. This is mainly for Jeremy, Tim, and anyone else who is interested in working on this, or something similar. I.e. at the very least, it is worth a read to look at the issues I've dealt with, and the several that are in comments as TODO. It may well be that a simpler persistence implementation that involves just extracting tarballs from usbsticks into the normal ram overlay, may be useful instead of (or even in addition to) this kind of implementation. (or perhaps some implementation of unionfs will make it into fedora eventually?) The main points of note, since the first post are- - all sorts of bugs fixed - I moved the overlay storage filesystem to be visible as /mnt/overlayfs always. This solves some aspects of the current problem of not easily being able to see how much writable space you really have available on the rootfs. (the real answer is a combination of the device mapper overlay file AND the filesystem it resides on). - I've included modified /etc/rc.d/init.d/halt and functions, to handle getting things cleanly shutdown (which is VERY important) - ntfs is somewhat present, but not really working. I have tested with vfat and ext3. Note that ext3 is a PITA when not cleanly unmounted- see TODOs. - rudimentary testing of the choice selection when multiple possible overlay images are detected suggests it works. - the patch format merely reflects my educational process with git, and not that I suggest that code this immature is anywhere near ready for merging. (i.e. inclusion of halt&functions and the origs I based them off of. Refer to list archives for documentation on how to use addidir/addsdir if needed) As always, comments/criticisms/suggestions are more than welcome. peace... -dmc

1 0

How to install one package from a specific repo?
by Lars Bjørndal 17 Aug '07

17 Aug '07

Hello! I need to install clamav from the development repository. I tried to do "yum --enablerepo=development -y install clamav" in the %post section of the .ks file, but it didn't work. BTW: I tried to set keepcache=1 in the yum.conf file on the build system, but the packages are lost after the livecd is built. So next time, they need to be refetched... Is it possible to keep them for future use? Lars

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

livecd August 2007