From dmc.fedora at filteredperception.org Wed Aug 1 11:27:01 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 01 Aug 2007 06:27:01 -0500 Subject: [Fedora-livecd-list] Re: LiveCD wiping root partition? In-Reply-To: References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> <46AF8522.2080409@filteredperception.org> <46AF8B55.6000306@fedoraproject.org> <46AF90A3.2080405@filteredperception.org> Message-ID: <46B06E05.506@filteredperception.org> Michel Salim wrote: > On 01/08/07, Douglas McClendon wrote: >> Rahul Sundaram wrote: >>> Michel Salim wrote: >>> >>>> Anyway, hard lesson learned. I wonder how Ubuntu does their live CD >>>> install. openSUSE is introducing one too, hopefully for their users >>>> the same bug does not occur. >>> Pretty much every live cd does a dd afaik. >> ubuntu 7.04 keeps their rootfs natively on squashfs (versus fedora which >> keeps >> it natively on an ext3 image which lives on a squashfs). >> >> Therefore they can't be doing a dd for the install. > > > Any reason why dd is preferred over, say, tar? The latter would be much > safer. And files would not have to be moved to their final partitions after > 'dd' too. seeking (cdrom and disk). Lots slower (5X?). I suspect that file level copy (tar) will be the long term answer for the flexible general case. Though I also suspect the much faster dd will be part of the long term answer as well for the typical case (i.e. formatting / as ext3, and no separate /usr). For example, on my system, using the existing 4.0G dd, the copy takes 299s. Using my turboLiveInst patch, I can shave that down to 250s. Using tar however to copy the 85896 files, took 1247s. And you also need to throw in another 30s or so for the format that isn't required in the dd case. Maybe(??) there is some more efficient way to copy those 85K files than the ( tar cpsf - | tar xpsf - ) that I used for that trial. Lastly safety has nothing to do with the tar vs dd issue. The safety issue had to do with the bug of the user interface not accurately reflecting what was happening. fyi, I did go ahead and file the bug, and even submit a patch which might fix it. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250301 That doesn't mean of course that you don't have every right and justification to be cursing the bits of the F7 livecd while watching it spark in a microwave. -dmc From kanarip at kanarip.com Wed Aug 1 12:16:22 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 01 Aug 2007 14:16:22 +0200 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System Message-ID: <46B07996.90800@kanarip.com> Hi All, livecd-creator's InstallationTarget.install() seems to run self.configureSystem(), then run self.configureNetwork(), possible overriding some configuration files generated with %post. Attached is a patch to prevent this from happening. Thanks to Mads Kiilerich for pointing this out in https://hosted.fedoraproject.org/projects/revisor/ticket/257 Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-post.patch Type: text/x-patch Size: 822 bytes Desc: not available URL: From kizu.fc.livecd at gmail.com Thu Aug 2 02:30:00 2007 From: kizu.fc.livecd at gmail.com (kenji izutani) Date: Thu, 2 Aug 2007 11:30:00 +0900 Subject: [Fedora-livecd-list] hot to figure out the free memory size? Message-ID: Hi all, I'd like to know how I can know the free memory left to allow a software generate a file at var directory. As far as I tested, free command did not to seem to show the exact number of free memory size even if I created and deleted a file. Although I get enough free once I reboot the livecd, I'd like to turn on the system permanently and the free size seems to fluctuate so I'm not sure how much memory I could use to generate a file. Thanks and regards, Kenji Izutani -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmc.fedora at filteredperception.org Thu Aug 2 05:55:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 02 Aug 2007 00:55:14 -0500 Subject: [Fedora-livecd-list] hot to figure out the free memory size? In-Reply-To: References: Message-ID: <46B171C2.8010304@filteredperception.org> kenji izutani wrote: > Hi all, > I'd like to know how I can know the free memory left to allow a software > generate a file at var directory. As far as I tested, free command did not > to seem to show the exact number of free memory size even if I created and > deleted a file. Although I get enough free once I reboot the livecd, I'd > like to turn on the system permanently and the free size seems to fluctuate > so I'm not sure how much memory I could use to generate a file. It's not yet easy, for rather esoteric reasons. As part of my persistence work, I intend to have a user management tool that makes it easy. Hopefully within a couple weeks so that it can make it into f8t2 or f8t3. If you really want to research it, take a look in mayflower of livecd-tools, how the copy on write is implemented with devicemapper and tmpfs. -dmc > > Thanks and regards, > Kenji Izutani > > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From kanarip at kanarip.com Sun Aug 5 18:24:49 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:24:49 +0200 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory Message-ID: <46B615F1.20500@kanarip.com> A patch to enable setting the build directory. This adds more flexibility for those who don't have as much space in /var/tmp. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-builddir.patch Type: text/x-patch Size: 3562 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:29:40 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:29:40 +0200 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root Message-ID: <46B61714.8070905@kanarip.com> A patch to enable changing the install_root from default. This enables other applications using livecd-creator as a backend application, while already having initialized a yum object configured with a certain installroot (which once the yum object is initialized, cannot be changed). Matching the build environment to what livecd-creator expects results in trouble with other builds running (eg., symlinking the actual yum installroot to "%s/install_root" % self.build_dir). We have not found loop-mounting the ext3 filesystem to be a problem. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-installroot.patch Type: text/x-patch Size: 3407 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:33:09 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:33:09 +0200 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache Message-ID: <46B617E5.9060704@kanarip.com> A patch to change the location of the yum cache directory. This enables existing yum cache to be used, which in our case is especially useful because that cache is populated already. Most importantly, livecd-creator doesn't bind mount the yum cache directory. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-yumcache.patch Type: text/x-patch Size: 5578 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:36:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:36:25 +0200 Subject: [Fedora-livecd-list] [PATCH 4/6] Translation Message-ID: <46B618A9.3010001@kanarip.com> A patch which is enabling translation in the python code, but is not including that what builds livecd-tools or it's RPMs. If you have a clue about what else I would need to patch to fully enable translation, please let me know because I don't have the slightest idea at this moment. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-translation.patch Type: text/x-patch Size: 19018 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:37:56 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:37:56 +0200 Subject: [Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application Message-ID: <46B61904.5040803@kanarip.com> A patch to prevent livecd-creator from also killing the application that is build on top of livecd-tools, while not changing the default behaviour. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-unmountkill.patch Type: text/x-patch Size: 1020 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:40:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:40:48 +0200 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels Message-ID: <46B619B0.4060900@kanarip.com> A patch which allows multiple kernels to be installed on the live media, giving boot options in the syslinux menu for all of them. In addition, this patch adds an optional timeout parameter for the boot menu. It also adds a cli parameter for appending boot options. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-kernelversion.patch Type: text/x-patch Size: 13010 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:46:56 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:46:56 +0200 Subject: [Fedora-livecd-list] About the previous patches Message-ID: <46B61B20.5020408@kanarip.com> A little word about the previous patches: I have re-based the Revisor cloned livecd-tools code base, and re-applied the changes we have made in order to get Revisor to do what it does. Since it's bad to derive from upstream code, I'm sending the changes I make to the list. I'll keep doing so every time Revisor re-bases, which happens every release or so. The patches sent to the list are all cumulative. The full cumulative patch is attached to this message. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd.patch Type: text/x-patch Size: 36517 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 18:55:37 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 20:55:37 +0200 Subject: [Fedora-livecd-list] [PATCH] Run post after having configured the network Message-ID: <46B61D29.3020107@kanarip.com> As proposed earlier, a patch to run %post only after configureNetwork() has run because %post network configuration may override configureNetwork() configuration, but vice-versa just seems wrong as you cannot do everything with kickstart network configuration directives. Thanks to Mads Kiilerich for pointing this out. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-runpost.patch Type: text/x-patch Size: 741 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 19:03:22 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 21:03:22 +0200 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B619B0.4060900@kanarip.com> References: <46B619B0.4060900@kanarip.com> Message-ID: <46B61EFA.9090709@kanarip.com> Jeroen van Meeuwen wrote: > A patch which allows multiple kernels to be installed on the live media, > giving boot options in the syslinux menu for all of them. > > In addition, this patch adds an optional timeout parameter for the boot > menu. It also adds a cli parameter for appending boot options. > My bad, I had left some old code in there before I created the patch. Hopefully this looks better. Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-kernelversion.patch Type: text/x-patch Size: 13904 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 19:19:06 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 21:19:06 +0200 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B61EFA.9090709@kanarip.com> References: <46B619B0.4060900@kanarip.com> <46B61EFA.9090709@kanarip.com> Message-ID: <46B622AA.9040803@kanarip.com> Jeroen van Meeuwen wrote: > Jeroen van Meeuwen wrote: >> A patch which allows multiple kernels to be installed on the live media, >> giving boot options in the syslinux menu for all of them. >> >> In addition, this patch adds an optional timeout parameter for the boot >> menu. It also adds a cli parameter for appending boot options. >> > > My bad, I had left some old code in there before I created the patch. > Hopefully this looks better. > Grmbl, it needs to import re too... Seems I need more coffee -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-kernelversion.patch Type: text/x-patch Size: 14017 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 5 19:19:52 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 21:19:52 +0200 Subject: [Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application In-Reply-To: <46B61904.5040803@kanarip.com> References: <46B61904.5040803@kanarip.com> Message-ID: <46B622D8.80209@kanarip.com> Jeroen van Meeuwen wrote: > A patch to prevent livecd-creator from also killing the application that > is build on top of livecd-tools, while not changing the default behaviour. > There's another spot where unmount() is being called, patching that too. -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-unmountkill.patch Type: text/x-patch Size: 1402 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Sun Aug 5 19:57:45 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 05 Aug 2007 14:57:45 -0500 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B622AA.9040803@kanarip.com> References: <46B619B0.4060900@kanarip.com> <46B61EFA.9090709@kanarip.com> <46B622AA.9040803@kanarip.com> Message-ID: <46B62BB9.4020802@filteredperception.org> Jeroen van Meeuwen wrote: > Grmbl, it needs to import re too... Seems I need more coffee I think I've got Jeremy trained to ignore anything of mine that doesn't have a subject line of "Revised: [PATCH]..." ;) -dmc From kanarip at kanarip.com Sun Aug 5 20:00:59 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 05 Aug 2007 22:00:59 +0200 Subject: [Fedora-livecd-list] [PATCH] Run post after having configured the network In-Reply-To: <46B61D29.3020107@kanarip.com> References: <46B61D29.3020107@kanarip.com> Message-ID: <46B62C7B.1070901@kanarip.com> Jeroen van Meeuwen wrote: > As proposed earlier, a patch to run %post only after configureNetwork() > has run because %post network configuration may override > configureNetwork() configuration, but vice-versa just seems wrong as you > cannot do everything with kickstart network configuration directives. > > Thanks to Mads Kiilerich for pointing this out. > It needs instroot, too -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-runpost.patch Type: text/x-patch Size: 797 bytes Desc: not available URL: From tim.wood at datawranglers.com Mon Aug 6 05:00:08 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Sun, 5 Aug 2007 23:00:08 -0600 Subject: [Fedora-livecd-list] Looking for help isolating a problem In-Reply-To: <46A7B453.7020901@filteredperception.org> References: <284110.79530.qm@web32010.mail.mud.yahoo.com> <46A7B0FE.30304@filteredperception.org> <46A7B453.7020901@filteredperception.org> Message-ID: <6FEEF7C1-08D1-46B2-AAEC-5F2526321B0B@datawranglers.com> Not all of this may be related... but this is strange enough I'm going to be overly verbose * I haven't had time to play with revisor in about 3 weeks * The kickstart I was starting with was a version of one that had been working successfully in the past. The main change was to remove some of the packages. * A day or two ago I built an RPM from git and installed it to verify that the bug I reported had been solved * I tried to build a CD image and failed repeatedly ... usually with Revisor reporting a connectivity issue ** Note: my revisor build "machine" is (and has been) a vmware image running on the repository machine ** I tried various basics up to and including rebooting both the vm (build machine) and the repository machine (vmware host) ** I stripped out the post stanza and various other non-core items from the kickstart. * I uninstalled the RPM I build from git and the related RPMs and then reinstalled the latest release (2.0.4.2 I believe) * I continue to received errors almost everytime. Sometimes it reports it can't connect to a repository, sometimes it complains about connectivity * It will sometimes succeed if I do something idiotically simple (the simplest sample.ks) * I've tried, flushing all the Revisor temp files (/srv/revisor, /var/ tmp/revsior, /var/tmp/yum... and even /var/log/revisor) * I've tried all sorts of tricks on the repository machine (run a full update, rebuild all the repodata stuff, etc) My next step has been to build an entirely new revisor build machine. That's not as bad as rebuilding a real machine but I'd rather avoid it if I can; especially since I'm not sure that'll solve the problem. Does anyone have any suggestions on either strange problems I've stumbled into (e.g. the git files from two days ago bulldozed my dog) or thoughts about how to properly narrow down the problem? Tim On Jul 25, 2007, at 2:36 PM, Douglas McClendon wrote: > Douglas McClendon wrote: >> C S wrote: >>> 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. >> Wow. Must be the collective unconsciousness. I was just thinking >> about this today. >> Of course, what you described, I think can be done pretty >> trivially. I.e. just get the livecd-tools /usr/bin/livecd-iso-to- >> disk (either by spinning your own livecd with the livecd-tools >> rpm, or wget/urlgrabbing a copy of the script from somewhere, >> etc...) and then doing >> livecd-iso-to-disk /dev/root /dev/ > > err... make that /dev/live instead of /dev/root > > >> That is F7-LiveCD-Itself-to-LiveUSB. For F7-LiveCD-Itself-to-spin- >> new-cd you would do something like livecd-creator --base-on=/dev/root > > /dev/live here as well. Though you will need to get livecd-creator > and dependencies installed. (yum install livecd-creator from the > livecd will work if you have enough ram and a net connection). And > you'll no doubt want to use --tmpdir pointing to some place with > lots of space mounted (i.e. not use the default tmpdir of /var/tmp > which would be in ram usually on a livecd) > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From jonathansteffan at gmail.com Mon Aug 6 08:51:05 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Mon, 06 Aug 2007 02:51:05 -0600 Subject: [Fedora-livecd-list] Looking for help isolating a problem In-Reply-To: <6FEEF7C1-08D1-46B2-AAEC-5F2526321B0B@datawranglers.com> References: <284110.79530.qm@web32010.mail.mud.yahoo.com> <46A7B0FE.30304@filteredperception.org> <46A7B453.7020901@filteredperception.org> <6FEEF7C1-08D1-46B2-AAEC-5F2526321B0B@datawranglers.com> Message-ID: <1186390265.3177.1.camel@damaestro> The log (/var/log/revisor.log) when running with revisor in --debug mode would help a lot. If this is a specific problem to revisor, the revisor-devel or revisor-users mailing list might be a better place to diagnose the issue. Jonathan Steffan On Sun, 2007-08-05 at 23:00 -0600, Tim Wood wrote: > Not all of this may be related... but this is strange enough I'm > going to be overly verbose > > * I haven't had time to play with revisor in about 3 weeks > * The kickstart I was starting with was a version of one that had > been working successfully in the past. The main change was to remove > some of the packages. > > * A day or two ago I built an RPM from git and installed it to verify > that the bug I reported had been solved > > * I tried to build a CD image and failed repeatedly ... usually with > Revisor reporting a connectivity issue > ** Note: my revisor build "machine" is (and has been) a vmware image > running on the repository machine > ** I tried various basics up to and including rebooting both the vm > (build machine) and the repository machine (vmware host) > ** I stripped out the post stanza and various other non-core items > from the kickstart. > > * I uninstalled the RPM I build from git and the related RPMs and > then reinstalled the latest release (2.0.4.2 I believe) > * I continue to received errors almost everytime. Sometimes it > reports it can't connect to a repository, sometimes it complains > about connectivity > * It will sometimes succeed if I do something idiotically simple (the > simplest sample.ks) > * I've tried, flushing all the Revisor temp files (/srv/revisor, /var/ > tmp/revsior, /var/tmp/yum... and even /var/log/revisor) > * I've tried all sorts of tricks on the repository machine (run a > full update, rebuild all the repodata stuff, etc) > > My next step has been to build an entirely new revisor build > machine. That's not as bad as rebuilding a real machine but I'd > rather avoid it if I can; especially since I'm not sure that'll solve > the problem. Does anyone have any suggestions on either strange > problems I've stumbled into (e.g. the git files from two days ago > bulldozed my dog) or thoughts about how to properly narrow down the > problem? > > Tim > > > On Jul 25, 2007, at 2:36 PM, Douglas McClendon wrote: > > > Douglas McClendon wrote: > >> C S wrote: > >>> 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. > >> Wow. Must be the collective unconsciousness. I was just thinking > >> about this today. > >> Of course, what you described, I think can be done pretty > >> trivially. I.e. just get the livecd-tools /usr/bin/livecd-iso-to- > >> disk (either by spinning your own livecd with the livecd-tools > >> rpm, or wget/urlgrabbing a copy of the script from somewhere, > >> etc...) and then doing > >> livecd-iso-to-disk /dev/root /dev/ > > > > err... make that /dev/live instead of /dev/root > > > > > >> That is F7-LiveCD-Itself-to-LiveUSB. For F7-LiveCD-Itself-to-spin- > >> new-cd you would do something like livecd-creator --base-on=/dev/root > > > > /dev/live here as well. Though you will need to get livecd-creator > > and dependencies installed. (yum install livecd-creator from the > > livecd will work if you have enough ram and a net connection). And > > you'll no doubt want to use --tmpdir pointing to some place with > > lots of space mounted (i.e. not use the default tmpdir of /var/tmp > > which would be in ram usually on a livecd) > > > > -dmc > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From tim.wood at datawranglers.com Mon Aug 6 17:59:29 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Mon, 6 Aug 2007 11:59:29 -0600 Subject: [Fedora-livecd-list] Looking for help isolating a problem In-Reply-To: <1186390265.3177.1.camel@damaestro> References: <284110.79530.qm@web32010.mail.mud.yahoo.com> <46A7B0FE.30304@filteredperception.org> <46A7B453.7020901@filteredperception.org> <6FEEF7C1-08D1-46B2-AAEC-5F2526321B0B@datawranglers.com> <1186390265.3177.1.camel@damaestro> Message-ID: FWIW... I did an uninstall, archived /etc/revisor, deleted all the odds and ends (e.g. /src/revisor and the stuff under /var/tmp), reinstalled and that cleared out enough junk that I was able to narrow the error down to a short list of things outside of Revsior. Tim On Aug 6, 2007, at 2:51 AM, Jonathan Steffan wrote: > The log (/var/log/revisor.log) when running with revisor in --debug > mode > would help a lot. If this is a specific problem to revisor, the > revisor-devel or revisor-users mailing list might be a better place to > diagnose the issue. > > Jonathan Steffan From dmc.fedora at filteredperception.org Mon Aug 6 18:50:19 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 06 Aug 2007 13:50:19 -0500 Subject: [Fedora-livecd-list] RFE- kickstart and package selection support for livecd installs Message-ID: <46B76D6B.9000301@filteredperception.org> After having fully grokked the livecd-creator code, it occurs to me that it may not be such a completely crazy idea to bring full package selection and even kickstart support to the livecd installer. The main constraint of course is having access to the 'core' or full repo, either via network or existing disk filesystem. The key aspect of feasibility I see, is how similar the task would be to the existing livecd-creator base-on-iso code path. I.e. that code path already takes as input, a livecd type installation, and then effectively applies a kickstart configuration to it. If similar code were in anaconda, it could act on the on-disk installed system after the normal liveinst/anaconda-livecd-backend installation. Just a thought... Probably more for F9 timeframe... -dmc From katzj at redhat.com Mon Aug 6 20:56:55 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 16:56:55 -0400 Subject: [Fedora-livecd-list] Re: LiveCD wiping root partition? In-Reply-To: <46B06E05.506@filteredperception.org> References: <46AF64FB.3020903@filteredperception.org> <46AF6FF4.7060507@filteredperception.org> <46AF8522.2080409@filteredperception.org> <46AF8B55.6000306@fedoraproject.org> <46AF90A3.2080405@filteredperception.org> <46B06E05.506@filteredperception.org> Message-ID: <1186433816.20556.61.camel@erebor.boston.redhat.com> On Wed, 2007-08-01 at 06:27 -0500, Douglas McClendon wrote: > Michel Salim wrote: > > Any reason why dd is preferred over, say, tar? The latter would be much > > safer. And files would not have to be moved to their final partitions after > > 'dd' too. > > seeking (cdrom and disk). Lots slower (5X?). I suspect that file level copy > (tar) will be the long term answer for the flexible general case. Though I also > suspect the much faster dd will be part of the long term answer as well for the > typical case (i.e. formatting / as ext3, and no separate /usr). > > For example, on my system, using the existing 4.0G dd, the copy takes 299s. > Using my turboLiveInst patch, I can shave that down to 250s. Using tar however > to copy the 85896 files, took 1247s. And you also need to throw in another 30s > or so for the format that isn't required in the dd case. Maybe(??) there is > some more efficient way to copy those 85K files than the ( tar cpsf - | tar xpsf > - ) that I used for that trial. Yeah, I gave the copy approach a quick test before leaving for vacation and it was taking quite a while. Still want to make sure that wasn't due to something stupid in my test setup, but it's looking less promising as an approach for speeding things up. Jeremy From katzj at redhat.com Mon Aug 6 20:58:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 16:58:01 -0400 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <46B07996.90800@kanarip.com> References: <46B07996.90800@kanarip.com> Message-ID: <1186433881.20556.63.camel@erebor.boston.redhat.com> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: > livecd-creator's InstallationTarget.install() seems to run > self.configureSystem(), then run self.configureNetwork(), possible > overriding some configuration files generated with %post. Hmm, the question is when is the best point at which to do this. After configuring the network or really as last as possible? The latter seems to fit better with when its run on an install Jeremy From katzj at redhat.com Mon Aug 6 20:59:25 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 16:59:25 -0400 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B615F1.20500@kanarip.com> References: <46B615F1.20500@kanarip.com> Message-ID: <1186433966.20556.65.camel@erebor.boston.redhat.com> On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: > A patch to enable setting the build directory. > > This adds more flexibility for those who don't have as much space in > /var/tmp. If you don't have space in /var/tmp, just use --tmpdir=/some/other/dir/with/space. Setting the build directory just sets people up for either a) deleting things they don't intend to or b) getting stale data in their build Jeremy From katzj at redhat.com Mon Aug 6 21:02:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:02:01 -0400 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root In-Reply-To: <46B61714.8070905@kanarip.com> References: <46B61714.8070905@kanarip.com> Message-ID: <1186434122.20556.68.camel@erebor.boston.redhat.com> On Sun, 2007-08-05 at 20:29 +0200, Jeroen van Meeuwen wrote: > This enables other applications using livecd-creator as a backend > application, while already having initialized a yum object configured > with a certain installroot (which once the yum object is initialized, > cannot be changed). Matching the build environment to what > livecd-creator expects results in trouble with other builds running > (eg., symlinking the actual yum installroot to "%s/install_root" % > self.build_dir). In practice, though, this is a bit of a moot point, since the API for using livecd-creator is the command-line and passing it a kickstart config. At which point, the fact that you have another yum object doesn't really make much difference... Jeremy From katzj at redhat.com Mon Aug 6 21:04:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:04:00 -0400 Subject: [Fedora-livecd-list] [PATCH 4/6] Translation In-Reply-To: <46B618A9.3010001@kanarip.com> References: <46B618A9.3010001@kanarip.com> Message-ID: <1186434241.20556.71.camel@erebor.boston.redhat.com> On Sun, 2007-08-05 at 20:36 +0200, Jeroen van Meeuwen wrote: > A patch which is enabling translation in the python code, but is not > including that what builds livecd-tools or it's RPMs. Using rhpl.translate for new code is probably a bad idea... it doesn't support all gettext features and also trips up some interesting areas with python's unicode support. > If you have a clue about what else I would need to patch to fully enable > translation, please let me know because I don't have the slightest idea > at this moment. Also needs makefile gunk to extract out strings using xgettext into a livecd-tools.pot, etc. See anaconda's po/Makefile for one example. Or other utilities for others. Jeremy From katzj at redhat.com Mon Aug 6 21:06:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:06:00 -0400 Subject: [Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application In-Reply-To: <46B61904.5040803@kanarip.com> References: <46B61904.5040803@kanarip.com> Message-ID: <1186434361.20556.74.camel@erebor.boston.redhat.com> On Sun, 2007-08-05 at 20:37 +0200, Jeroen van Meeuwen wrote: > A patch to prevent livecd-creator from also killing the application that > is build on top of livecd-tools, while not changing the default behaviour. Better would be a patch to use the YumBase.close() method in yum >= 3.1.7. And then perhaps fallback to the current behavior for older yum (although I'm not against just requiring yum 3.2.x at this point I don't think) Jeremy From katzj at redhat.com Mon Aug 6 21:07:54 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:07:54 -0400 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B619B0.4060900@kanarip.com> References: <46B619B0.4060900@kanarip.com> Message-ID: <1186434475.20556.77.camel@erebor.boston.redhat.com> On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote: > A patch which allows multiple kernels to be installed on the live media, > giving boot options in the syslinux menu for all of them. This part looks mostly reasonable... > In addition, this patch adds an optional timeout parameter for the boot > menu. It also adds a cli parameter for appending boot options. I think a better approach for this, though, is to extend the kickstart bootloader syntax a little bit. The proliferation of command-line options for this is a little ridiculous. Also, it leads to the images not being reproducible just from the kickstart config Jeremy From kanarip at kanarip.com Mon Aug 6 21:09:33 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:09:33 +0200 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <1186433881.20556.63.camel@erebor.boston.redhat.com> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> Message-ID: <46B78E0D.5010209@kanarip.com> Jeremy Katz wrote: > On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: >> livecd-creator's InstallationTarget.install() seems to run >> self.configureSystem(), then run self.configureNetwork(), possible >> overriding some configuration files generated with %post. > > Hmm, the question is when is the best point at which to do this. After > configuring the network or really as last as possible? The latter seems > to fit better with when its run on an install > +1 Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Aug 6 21:21:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:21:48 +0200 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <1186433966.20556.65.camel@erebor.boston.redhat.com> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> Message-ID: <46B790EC.1010707@kanarip.com> Jeremy Katz wrote: > On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: >> A patch to enable setting the build directory. >> >> This adds more flexibility for those who don't have as much space in >> /var/tmp. > > If you don't have space in /var/tmp, just use > --tmpdir=/some/other/dir/with/space. Setting the build directory just > sets people up for either a) deleting things they don't intend to or b) > getting stale data in their build > Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp issue. Push comes to shovel, I really don't need to set the build_dir to anything I can think of, rather then just use the InstallationTarget.build_dir for any reference after I import livecd-creator and create the extended InstallationTarget instance. I'm not sure though what you mean by a) and b) though. AFAICT these would never just happen because build_dir === build_dir, regardless of what you set it to, or how you set it. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Aug 6 21:24:27 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:24:27 +0200 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root In-Reply-To: <1186434122.20556.68.camel@erebor.boston.redhat.com> References: <46B61714.8070905@kanarip.com> <1186434122.20556.68.camel@erebor.boston.redhat.com> Message-ID: <46B7918B.2040005@kanarip.com> Jeremy Katz wrote: > On Sun, 2007-08-05 at 20:29 +0200, Jeroen van Meeuwen wrote: >> This enables other applications using livecd-creator as a backend >> application, while already having initialized a yum object configured >> with a certain installroot (which once the yum object is initialized, >> cannot be changed). Matching the build environment to what >> livecd-creator expects results in trouble with other builds running >> (eg., symlinking the actual yum installroot to "%s/install_root" % >> self.build_dir). > > In practice, though, this is a bit of a moot point, since the API for > using livecd-creator is the command-line and passing it a kickstart > config. At which point, the fact that you have another yum object > doesn't really make much difference... > No matter what API you support, it doesn't prevent you from applying the patch. Should I remove all cli options that refer to the configuration directive to make livecd-creator itself not have this option? Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Mon Aug 6 21:26:23 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:26:23 -0400 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <46B78E0D.5010209@kanarip.com> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> Message-ID: <1186435583.9762.0.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: > >> livecd-creator's InstallationTarget.install() seems to run > >> self.configureSystem(), then run self.configureNetwork(), possible > >> overriding some configuration files generated with %post. > > > > Hmm, the question is when is the best point at which to do this. After > > configuring the network or really as last as possible? The latter seems > > to fit better with when its run on an install > > +1 Want to send a revised patch? :-) Jeremy From kanarip at kanarip.com Mon Aug 6 21:29:21 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:29:21 +0200 Subject: [Fedora-livecd-list] [PATCH 4/6] Translation In-Reply-To: <1186434241.20556.71.camel@erebor.boston.redhat.com> References: <46B618A9.3010001@kanarip.com> <1186434241.20556.71.camel@erebor.boston.redhat.com> Message-ID: <46B792B1.5050308@kanarip.com> Jeremy Katz wrote: > On Sun, 2007-08-05 at 20:36 +0200, Jeroen van Meeuwen wrote: >> A patch which is enabling translation in the python code, but is not >> including that what builds livecd-tools or it's RPMs. > > Using rhpl.translate for new code is probably a bad idea... it doesn't > support all gettext features and also trips up some interesting areas > with python's unicode support. > New code? It's been 6 months since Boston already. Not sure though if that means you're old? ;-) I don't know what rhpl does or doesn't do right; it works. Should it get fixed before you even think about applying any translation patch whatsoever, or can we live with it for the moment? >> If you have a clue about what else I would need to patch to fully enable >> translation, please let me know because I don't have the slightest idea >> at this moment. > > Also needs makefile gunk to extract out strings using xgettext into a > livecd-tools.pot, etc. See anaconda's po/Makefile for one example. Or > other utilities for others. > Right, I figured. I'll try and get some more work done on this. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Mon Aug 6 21:28:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:28:18 -0400 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B790EC.1010707@kanarip.com> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> Message-ID: <1186435698.9762.3.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:21 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: > >> A patch to enable setting the build directory. > >> > >> This adds more flexibility for those who don't have as much space in > >> /var/tmp. > > > > If you don't have space in /var/tmp, just use > > --tmpdir=/some/other/dir/with/space. Setting the build directory just > > sets people up for either a) deleting things they don't intend to or b) > > getting stale data in their build > > Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp > issue. Push comes to shovel, I really don't need to set the build_dir to > anything I can think of, rather then just use the > InstallationTarget.build_dir for any reference after I import > livecd-creator and create the extended InstallationTarget instance. This sounds a lot better to me... > I'm not sure though what you mean by a) and b) though. AFAICT these > would never just happen because build_dir === build_dir, regardless of > what you set it to, or how you set it. Okay, we don't actually do any removal, so you won't hit that. But if you set a build_dir that already exists, then you're setting up for some "interesting" conditions. By ensuring that it's a new mkdtemp'd dir, we can be certain that we own it, that it's unique, and that no one has done anything with it first Jeremy From katzj at redhat.com Mon Aug 6 21:29:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:29:44 -0400 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root In-Reply-To: <46B7918B.2040005@kanarip.com> References: <46B61714.8070905@kanarip.com> <1186434122.20556.68.camel@erebor.boston.redhat.com> <46B7918B.2040005@kanarip.com> Message-ID: <1186435784.9762.6.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:24 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-05 at 20:29 +0200, Jeroen van Meeuwen wrote: > >> This enables other applications using livecd-creator as a backend > >> application, while already having initialized a yum object configured > >> with a certain installroot (which once the yum object is initialized, > >> cannot be changed). Matching the build environment to what > >> livecd-creator expects results in trouble with other builds running > >> (eg., symlinking the actual yum installroot to "%s/install_root" % > >> self.build_dir). > > > > In practice, though, this is a bit of a moot point, since the API for > > using livecd-creator is the command-line and passing it a kickstart > > config. At which point, the fact that you have another yum object > > doesn't really make much difference... > > No matter what API you support, it doesn't prevent you from applying the > patch. But why add (and therefore have to maintain, follow indirections and then deal with potential odd fall-out) options that aren't ever going to be hit or used? Jeremy From kanarip at kanarip.com Mon Aug 6 21:50:09 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:50:09 +0200 Subject: [Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application In-Reply-To: <1186434361.20556.74.camel@erebor.boston.redhat.com> References: <46B61904.5040803@kanarip.com> <1186434361.20556.74.camel@erebor.boston.redhat.com> Message-ID: <46B79791.4070807@kanarip.com> Jeremy Katz wrote: > On Sun, 2007-08-05 at 20:37 +0200, Jeroen van Meeuwen wrote: >> A patch to prevent livecd-creator from also killing the application that >> is build on top of livecd-tools, while not changing the default behaviour. > > Better would be a patch to use the YumBase.close() method in yum >= > 3.1.7. And then perhaps fallback to the current behavior for older yum > (although I'm not against just requiring yum 3.2.x at this point I don't > think) > Hey, this just works for us. I'm not the maintainer of livecd-tools nor do I have commit access. Make me have one of these things before you tell me what is better, while /and/ not applying the better change you suggest yourself, /and/ not applying the patch I sent you. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Mon Aug 6 21:52:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Aug 2007 17:52:05 -0400 Subject: [Fedora-livecd-list] [PATCH 4/6] Translation In-Reply-To: <46B792B1.5050308@kanarip.com> References: <46B618A9.3010001@kanarip.com> <1186434241.20556.71.camel@erebor.boston.redhat.com> <46B792B1.5050308@kanarip.com> Message-ID: <1186437125.9762.17.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:29 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-05 at 20:36 +0200, Jeroen van Meeuwen wrote: > >> A patch which is enabling translation in the python code, but is not > >> including that what builds livecd-tools or it's RPMs. > > > > Using rhpl.translate for new code is probably a bad idea... it doesn't > > support all gettext features and also trips up some interesting areas > > with python's unicode support. > > New code? It's been 6 months since Boston already. Not sure though if > that means you're old? ;-) I don't know what rhpl does or doesn't do > right; it works. Should it get fixed before you even think about > applying any translation patch whatsoever, or can we live with it for > the moment? Realistically, you don't want to be using rhpl.translate in revisor either. You want to be using python's native gettext module. rhpl.translate was created when python's gettext module was awful (to be kind :-). And I'd really rather _not_ apply something that I know is deprecated and going to go away in the future. The difference should mostly be switching to import gettext instead of rhpl.translate and then using _ = gettext.gettext. /me makes a note to make rhpl.translate start spewing deprecation warnings soon... Jeremy From kanarip at kanarip.com Mon Aug 6 21:59:52 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 06 Aug 2007 23:59:52 +0200 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <1186434475.20556.77.camel@erebor.boston.redhat.com> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> Message-ID: <46B799D8.70506@kanarip.com> Jeremy Katz wrote: > On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote: >> A patch which allows multiple kernels to be installed on the live media, >> giving boot options in the syslinux menu for all of them. > > This part looks mostly reasonable... > >> In addition, this patch adds an optional timeout parameter for the boot >> menu. It also adds a cli parameter for appending boot options. > > I think a better approach for this, though, is to extend the kickstart > bootloader syntax a little bit. The proliferation of command-line > options for this is a little ridiculous. Also, it leads to the images > not being reproducible just from the kickstart config > It's never reproducible from kickstart config as kickstart is not allowing you to set specific version numbers, nor filesystem compression, prelinking, ignoring deleted files, etc. I'd rather have some error, bug or dis-functionality that I can fix. I can't read your mind and think of the better approach without seeing the code live in some upstream source repository. If it's reasonable, like the previous patch, you get to apply it and _then_ think of a better way, then apply that. Just a cloud of better ideas doesn't make it rain. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Aug 6 22:20:46 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Aug 2007 00:20:46 +0200 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <1186435583.9762.0.camel@localhost.localdomain> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> Message-ID: <46B79EBE.2070007@kanarip.com> Jeremy Katz wrote: > On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: >>>> livecd-creator's InstallationTarget.install() seems to run >>>> self.configureSystem(), then run self.configureNetwork(), possible >>>> overriding some configuration files generated with %post. >>> Hmm, the question is when is the best point at which to do this. After >>> configuring the network or really as last as possible? The latter seems >>> to fit better with when its run on an install >> +1 > > Want to send a revised patch? :-) > Well, as it is now it does apply at the very last moment, exactly the way the installer works, right? Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Aug 6 22:22:02 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Aug 2007 00:22:02 +0200 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <1186435698.9762.3.camel@localhost.localdomain> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> Message-ID: <46B79F0A.70203@kanarip.com> Jeremy Katz wrote: > On Mon, 2007-08-06 at 23:21 +0200, Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: >>>> A patch to enable setting the build directory. >>>> >>>> This adds more flexibility for those who don't have as much space in >>>> /var/tmp. >>> If you don't have space in /var/tmp, just use >>> --tmpdir=/some/other/dir/with/space. Setting the build directory just >>> sets people up for either a) deleting things they don't intend to or b) >>> getting stale data in their build >> Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp >> issue. Push comes to shovel, I really don't need to set the build_dir to >> anything I can think of, rather then just use the >> InstallationTarget.build_dir for any reference after I import >> livecd-creator and create the extended InstallationTarget instance. > > This sounds a lot better to me... > >> I'm not sure though what you mean by a) and b) though. AFAICT these >> would never just happen because build_dir === build_dir, regardless of >> what you set it to, or how you set it. > > Okay, we don't actually do any removal, so you won't hit that. But if > you set a build_dir that already exists, then you're setting up for some > "interesting" conditions. By ensuring that it's a new mkdtemp'd dir, we > can be certain that we own it, that it's unique, and that no one has > done anything with it first > So again if we remove the opts, livecd-tools is safe, and Revisor gets to do whatever it wants. Would that be an acceptable patch? Kind regards, Jeroen van Meeuwen -kanarip From dmc.fedora at filteredperception.org Mon Aug 6 22:29:35 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 06 Aug 2007 17:29:35 -0500 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B799D8.70506@kanarip.com> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> Message-ID: <46B7A0CF.5000800@filteredperception.org> Jeroen van Meeuwen wrote: > Jeremy Katz wrote: >> On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote: >>> A patch which allows multiple kernels to be installed on the live media, >>> giving boot options in the syslinux menu for all of them. >> This part looks mostly reasonable... >> >>> In addition, this patch adds an optional timeout parameter for the boot >>> menu. It also adds a cli parameter for appending boot options. >> I think a better approach for this, though, is to extend the kickstart >> bootloader syntax a little bit. The proliferation of command-line >> options for this is a little ridiculous. Also, it leads to the images >> not being reproducible just from the kickstart config >> > > It's never reproducible from kickstart config as kickstart is not > allowing you to set specific version numbers, nor filesystem > compression, prelinking, ignoring deleted files, etc. I agree with this point... and how it relates to my prior addidir/addsdir patch... *But*... > > I'd rather have some error, bug or dis-functionality that I can fix. I > can't read your mind and think of the better approach without seeing the > code live in some upstream source repository. If it's reasonable, like > the previous patch, you get to apply it and _then_ think of a better > way, then apply that. Just a cloud of better ideas doesn't make it rain. I think your arguments Jeroen would be more valid if you had a little more patience. I.e. I don't remember seeing much design-debate over the current contentious issues. And it's only been a couple days since you posted the patch. *And* revisor appears to already be working off of its own copy of pilgrim.py (as I figured out when I wondered why the patches were still using that name). Thus I don't think there is any reason to rush this particular debate. By posting the initial ideas, and getting initial feedback from the list, _and then waiting a few days/weeks_ someone might figure out a drastically more elegant solution. Or not. Now, if a couple months go by, and neither my turboLiveInst patch nor anything better, nor any ability to easily replicate the ubuntu feature of throwing extra goodies in the iso (e.g. firefox windows installer, autorun.bat+why_f8livecdkicksass.html) then maybe I'll take up your side of the argument. -dmc From kanarip at kanarip.com Mon Aug 6 22:29:15 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Aug 2007 00:29:15 +0200 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root In-Reply-To: <1186435784.9762.6.camel@localhost.localdomain> References: <46B61714.8070905@kanarip.com> <1186434122.20556.68.camel@erebor.boston.redhat.com> <46B7918B.2040005@kanarip.com> <1186435784.9762.6.camel@localhost.localdomain> Message-ID: <46B7A0BB.8010801@kanarip.com> Jeremy Katz wrote: > On Mon, 2007-08-06 at 23:24 +0200, Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Sun, 2007-08-05 at 20:29 +0200, Jeroen van Meeuwen wrote: >>>> This enables other applications using livecd-creator as a backend >>>> application, while already having initialized a yum object configured >>>> with a certain installroot (which once the yum object is initialized, >>>> cannot be changed). Matching the build environment to what >>>> livecd-creator expects results in trouble with other builds running >>>> (eg., symlinking the actual yum installroot to "%s/install_root" % >>>> self.build_dir). >>> In practice, though, this is a bit of a moot point, since the API for >>> using livecd-creator is the command-line and passing it a kickstart >>> config. At which point, the fact that you have another yum object >>> doesn't really make much difference... >> No matter what API you support, it doesn't prevent you from applying the >> patch. > > But why add (and therefore have to maintain, follow indirections and > then deal with potential odd fall-out) options that aren't ever going to > be hit or used? > Because we move forward and that's what we do. We focus on new features, software and technology. The issue of maintaining things on the long-term applies to anaconda, pykickstart, it's deps. Not livecd-tools. Not Revisor either. Not at this point in time anyway. If maintaining the code is your biggest concern though... Try and assign all livecd-tool's bugs to me. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Aug 6 22:36:23 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Aug 2007 00:36:23 +0200 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B7A0CF.5000800@filteredperception.org> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> Message-ID: <46B7A267.4040008@kanarip.com> Douglas McClendon wrote: > I think your arguments Jeroen would be more valid if you had a little > more patience. Believe me, this has been going on for quite a while. I.e. I don't remember seeing much design-debate over > the current contentious issues. And it's only been a couple days since > you posted the patch. *And* revisor appears to already be working off > of its own copy of pilgrim.py (as I figured out when I wondered why the > patches were still using that name). Right, that pilgrim.py is getting us ugly faces everywhere. Working with us is a matter of principle for these guys. All we need is the '-' to be removed from the 'livecd-creator' command. Kind regards, Jeroen van Meeuwen -kanarip From dmc.fedora at filteredperception.org Mon Aug 6 22:47:26 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 06 Aug 2007 17:47:26 -0500 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B7A267.4040008@kanarip.com> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> <46B7A267.4040008@kanarip.com> Message-ID: <46B7A4FE.4000208@filteredperception.org> Jeroen van Meeuwen wrote: > Douglas McClendon wrote: >> I think your arguments Jeroen would be more valid if you had a little >> more patience. > > Believe me, this has been going on for quite a while. I've been on this list for years (jdogalt). Believe me, I've got my own litany of issues. But from where I'm standing, it does look like you threw up 6 patches without much obvious design discussion beforehand, and you are getting too upset too quickly. Since the livecd-creator bits are what is used to build the official fedora releases, I do think there should be a fair amount of resistence to changes. > > I.e. I don't remember seeing much design-debate over >> the current contentious issues. And it's only been a couple days since >> you posted the patch. *And* revisor appears to already be working off >> of its own copy of pilgrim.py (as I figured out when I wondered why the >> patches were still using that name). > > Right, that pilgrim.py is getting us ugly faces everywhere. Working with > us is a matter of principle for these guys. All we need is the '-' to > be removed from the 'livecd-creator' command. Can you explain this a bit more? I am not a seasoned python programmer, but that sounds like a _really_ strange issue to me??? -dmc From jonathansteffan at gmail.com Tue Aug 7 00:04:42 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Mon, 06 Aug 2007 18:04:42 -0600 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B7A4FE.4000208@filteredperception.org> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> <46B7A267.4040008@kanarip.com> <46B7A4FE.4000208@filteredperception.org> Message-ID: <1186445082.29420.31.camel@damaestro> On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote: > Jeroen van Meeuwen wrote: > > Douglas McClendon wrote: > >> I think your arguments Jeroen would be more valid if you had a little > >> more patience. > > > > Believe me, this has been going on for quite a while. > > I've been on this list for years (jdogalt). Believe me, I've got my own litany > of issues. > > But from where I'm standing, it does look like you threw up 6 patches without > much obvious design discussion beforehand, and you are getting too upset too > quickly. > > Since the livecd-creator bits are what is used to build the official fedora > releases, I do think there should be a fair amount of resistence to changes. I'm not at all against resistance to changes that might not be quite ready. I am against hindering innovation, in any form, or minimally causing discouragement because we have taken on code that helps us do what what want to do with software, even when upstream is not ready for us to. :-D > > > > > I.e. I don't remember seeing much design-debate over > >> the current contentious issues. And it's only been a couple days since > >> you posted the patch. *And* revisor appears to already be working off > >> of its own copy of pilgrim.py (as I figured out when I wondered why the > >> patches were still using that name). > > > > Right, that pilgrim.py is getting us ugly faces everywhere. Working with > > us is a matter of principle for these guys. All we need is the '-' to > > be removed from the 'livecd-creator' command. > > Can you explain this a bit more? I am not a seasoned python programmer, but > that sounds like a _really_ strange issue to me??? It's a matter of livecd-creator not wanting to be imported and subclassed. Ignore that the sys.path.append() is more then nasty, but it does help to illustrate discussion we have had in the past around the time of the Fedora 7 release. The revisor team has wanted the livecd bits to be importable (in a similar way that pungi has allowed us to) and when that was denied we had to make the controversial decision to pull the full source into revisor. My understanding, at least this is what I took from the discussion, is that livecd-creator is just not ready to be imported and is offering nothing resembling a stable API/code base. This didn't bother us at all, we were willing to fix any issue that arises from changes in livecd-creator and the way we utilized the code in revisor. To just move on and start getting things done, we brought all of livecd-creator into revisor and named it pilgrim.py. When we move to do a release we try our best to rebase and then submit our changes upstream, hoping to help mature the API/code base far along enough where we are allowed to import and utilize it. Consider the following: >>> import sys >>> sys.path.append('/usr/bin') >>> import livecd-creator File "", line 1 import livecd-creator ^ SyntaxError: invalid syntax >>> Now, without the dash: Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ] >>> import sys >>> sys.path.append('/usr/bin') >>> import livecdcreator >>> You could then continue on with: >>> myubercoolliveimage = livecdcreator.InstallationTarget(options.more, options.yeah) At this point you have access to the needed toolchain with your 'myubercoolliveimage' and also allows us (revisor team) to make our changes much more gracefully by subclassing or overriding functions almost as a proof of concept. Forgive my rudimentary example, but most of the reason why we have just brought all of livecd-tools into revisor is to not waste a *ton* of time on discussions just like this one. I'm not saying I don't find value in this type of good, open debate... it is more I personally work better expressing what I would like to see software do by at least getting some sort of code down. Some of the things we are doing in revisor might seem elementary and, also, underdeveloped but we are trying to work out a feature rich application that has both a fully functional CLI and GUI mode that puts an amazing amount of power right at the end users hands. I'm trying to not fuel the fire here as we all have much more productive things we can be working on. ;-) Jonathan Steffan daMaestro From jkeating at redhat.com Tue Aug 7 00:15:03 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 6 Aug 2007 20:15:03 -0400 Subject: [Fedora-livecd-list] [PATCH 2/6] Setting the install_root In-Reply-To: <46B7A0BB.8010801@kanarip.com> References: <46B61714.8070905@kanarip.com> <1186434122.20556.68.camel@erebor.boston.redhat.com> <46B7918B.2040005@kanarip.com> <1186435784.9762.6.camel@localhost.localdomain> <46B7A0BB.8010801@kanarip.com> Message-ID: <20070806201503.4aee17ce@ender> On Tue, 07 Aug 2007 00:29:15 +0200 Jeroen van Meeuwen wrote: > Because we move forward and that's what we do. We focus on new > features, software and technology. > > The issue of maintaining things on the long-term applies to anaconda, > pykickstart, it's deps. Not livecd-tools. Not Revisor either. Not at > this point in time anyway. Wow. Just wow. "I don't care what kind of crap pile this stuff is in the future, I want my $foo right now, and be damned with it working next release." You can't be serious right? -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmc.fedora at filteredperception.org Tue Aug 7 05:05:27 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 07 Aug 2007 00:05:27 -0500 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <1186445082.29420.31.camel@damaestro> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> <46B7A267.4040008@kanarip.com> <46B7A4FE.4000208@filteredperception.org> <1186445082.29420.31.camel@damaestro> Message-ID: <46B7FD97.3090905@filteredperception.org> Jonathan Steffan wrote: > On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote: >> Jeroen van Meeuwen wrote: >>> Douglas McClendon wrote: >>>> I think your arguments Jeroen would be more valid if you had a little >>>> more patience. >>> Believe me, this has been going on for quite a while. >> I've been on this list for years (jdogalt). Believe me, I've got my own litany >> of issues. >> >> But from where I'm standing, it does look like you threw up 6 patches without >> much obvious design discussion beforehand, and you are getting too upset too >> quickly. >> >> Since the livecd-creator bits are what is used to build the official fedora >> releases, I do think there should be a fair amount of resistence to changes. > > I'm not at all against resistance to changes that might not be quite > ready. I am against hindering innovation, in any form, or minimally > causing discouragement because we have taken on code that helps us do > what what want to do with software, even when upstream is not ready for > us to. :-D It's a subtle thing, but I would take the lack of upstream merging as an absence of encouragement, and not the presence of discouragement. > > >>> I.e. I don't remember seeing much design-debate over >>>> the current contentious issues. And it's only been a couple days since >>>> you posted the patch. *And* revisor appears to already be working off >>>> of its own copy of pilgrim.py (as I figured out when I wondered why the >>>> patches were still using that name). >>> Right, that pilgrim.py is getting us ugly faces everywhere. Working with >>> us is a matter of principle for these guys. All we need is the '-' to >>> be removed from the 'livecd-creator' command. >> Can you explain this a bit more? I am not a seasoned python programmer, but >> that sounds like a _really_ strange issue to me??? > > > It's a matter of livecd-creator not wanting to be imported and > subclassed. Ignore that the sys.path.append() is more then nasty, but it > does help to illustrate discussion we have had in the past around the > time of the Fedora 7 release. The revisor team has wanted the livecd > bits to be importable (in a similar way that pungi has allowed us to) > and when that was denied we had to make the controversial decision to > pull the full source into revisor. My understanding, at least this is > what I took from the discussion, is that livecd-creator is just not > ready to be imported and is offering nothing resembling a stable > API/code base. This didn't bother us at all, we were willing to fix any > issue that arises from changes in livecd-creator and the way we utilized > the code in revisor. To just move on and start getting things done, we > brought all of livecd-creator into revisor and named it pilgrim.py. When > we move to do a release we try our best to rebase and then submit our > changes upstream, hoping to help mature the API/code base far along > enough where we are allowed to import and utilize it. > It sounds like this is a perfect example of when forking works. > > Consider the following: > >>>> import sys >>>> sys.path.append('/usr/bin') >>>> import livecd-creator > File "", line 1 > import livecd-creator > ^ > SyntaxError: invalid syntax > > Now, without the dash: > > Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ] ln -s /usr/bin/livecd-creator /usr/lib/livecd-creator/livecdcreator.py would be quite a bit less yucky. > >>>> import sys >>>> sys.path.append('/usr/bin') >>>> import livecdcreator >>>> > > You could then continue on with: > >>>> myubercoolliveimage = livecdcreator.InstallationTarget(options.more, > options.yeah) > > At this point you have access to the needed toolchain with your > 'myubercoolliveimage' and also allows us (revisor team) to make our > changes much more gracefully by subclassing or overriding functions > almost as a proof of concept. Forgive my rudimentary example, but most > of the reason why we have just brought all of livecd-tools into revisor > is to not waste a *ton* of time on discussions just like this one. I'm > not saying I don't find value in this type of good, open debate... it is > more I personally work better expressing what I would like to see > software do by at least getting some sort of code down. Some of the > things we are doing in revisor might seem elementary and, also, > underdeveloped but we are trying to work out a feature rich application > that has both a fully functional CLI and GUI mode that puts an amazing > amount of power right at the end users hands. I'm trying to not fuel the > fire here as we all have much more productive things we can be working > on. ;-) +1 for forking. Personally I'm sitting on a few thousand lines of bash code that duplicates the functionality of livecd-creator myself (they just run about 6 times slower, but have a few beneficial aspects that I think may eventually be worthwhile for a larger audience). I'm quite optimistic that 2 years from now, fedora will have (at least one) really excellent livecd generation program, which uses great features pioneered by everyone on this list. To quote some of the last lines of perhaps my favorite rock opera- "we can walk our road together, if our goals are all the same. we can run alone and free, if we pursue a different aim." -dmc From jonathansteffan at gmail.com Tue Aug 7 08:00:39 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Tue, 07 Aug 2007 02:00:39 -0600 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B7FD97.3090905@filteredperception.org> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> <46B7A267.4040008@kanarip.com> <46B7A4FE.4000208@filteredperception.org> <1186445082.29420.31.camel@damaestro> <46B7FD97.3090905@filteredperception.org> Message-ID: <1186473639.31308.6.camel@damaestro> On Tue, 2007-08-07 at 00:05 -0500, Douglas McClendon wrote: > Jonathan Steffan wrote: > > On Mon, 2007-08-06 at 17:47 -0500, Douglas McClendon wrote: > >> Jeroen van Meeuwen wrote: > >>> Douglas McClendon wrote: [...] > >>> I.e. I don't remember seeing much design-debate over > >>>> the current contentious issues. And it's only been a couple days since > >>>> you posted the patch. *And* revisor appears to already be working off > >>>> of its own copy of pilgrim.py (as I figured out when I wondered why the > >>>> patches were still using that name). > >>> Right, that pilgrim.py is getting us ugly faces everywhere. Working with > >>> us is a matter of principle for these guys. All we need is the '-' to > >>> be removed from the 'livecd-creator' command. > >> Can you explain this a bit more? I am not a seasoned python programmer, but > >> that sounds like a _really_ strange issue to me??? > > > > [...] > > > > It sounds like this is a perfect example of when forking works. > > > > > > Consider the following: > > > >>>> import sys > >>>> sys.path.append('/usr/bin') > >>>> import livecd-creator > > File "", line 1 > > import livecd-creator > > ^ > > SyntaxError: invalid syntax > > > > Now, without the dash: > > > > Yuck: [ ln -s /usr/bin/livecd-creator /usr/bin/livecdcreator.py ] > > ln -s /usr/bin/livecd-creator /usr/lib/livecd-creator/livecdcreator.py > > would be quite a bit less yucky. Yes. ;-) It is still a nasty workaround to require your software to setup a symlink just to import code. We did look at this option, I just wanted to bring up that we had evaluated it. [...] > > +1 for forking. Personally I'm sitting on a few thousand lines of bash > code that duplicates the functionality of livecd-creator myself (they > just run about 6 times slower, but have a few beneficial aspects that I > think may eventually be worthwhile for a larger audience). We are in no way against working with upstream to make sure forward progress is made so everyone gains. > > I'm quite optimistic that 2 years from now, fedora will have (at least > one) really excellent livecd generation program, which uses great > features pioneered by everyone on this list. I'm more then optimistic we will have an amazing provisioning system, including live/stateless media, for Fedora 9 if not for Fedora 8 ;-) > > To quote some of the last lines of perhaps my favorite rock opera- > > "we can walk our road together, > if our goals are all the same. > we can run alone and free, > if we pursue a different aim." Awesome quote. Jonathan Steffan daMaestro From dmc.fedora at filteredperception.org Tue Aug 7 08:43:57 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 07 Aug 2007 03:43:57 -0500 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B79F0A.70203@kanarip.com> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> Message-ID: <46B830CD.6000801@filteredperception.org> Jeroen van Meeuwen wrote: > Jeremy Katz wrote: >> On Mon, 2007-08-06 at 23:21 +0200, Jeroen van Meeuwen wrote: >>> Jeremy Katz wrote: >>>> On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: >>>>> A patch to enable setting the build directory. >>>>> >>>>> This adds more flexibility for those who don't have as much space in >>>>> /var/tmp. >>>> If you don't have space in /var/tmp, just use >>>> --tmpdir=/some/other/dir/with/space. Setting the build directory just >>>> sets people up for either a) deleting things they don't intend to or b) >>>> getting stale data in their build >>> Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp >>> issue. Push comes to shovel, I really don't need to set the build_dir to >>> anything I can think of, rather then just use the >>> InstallationTarget.build_dir for any reference after I import >>> livecd-creator and create the extended InstallationTarget instance. >> This sounds a lot better to me... >> >>> I'm not sure though what you mean by a) and b) though. AFAICT these >>> would never just happen because build_dir === build_dir, regardless of >>> what you set it to, or how you set it. >> Okay, we don't actually do any removal, so you won't hit that. But if >> you set a build_dir that already exists, then you're setting up for some >> "interesting" conditions. By ensuring that it's a new mkdtemp'd dir, we >> can be certain that we own it, that it's unique, and that no one has >> done anything with it first Are you actually certain that you don't do any removal? def teardown(self): if self.build_dir: self.unmount() shutil.rmtree(self.build_dir, ignore_errors = True) -dmc From walters at redhat.com Tue Aug 7 20:07:36 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 16:07:36 -0400 Subject: [Fedora-livecd-list] [PATCH] default to using a global livecd yum cache, not a private one Message-ID: <1186517256.3674.20.camel@neutron.verbum.private> Hi, This patch moves the yum cache into /var/cache/livecd so that out of the box, the tool doesn't repeatedly download stuff from the internet. From walters at redhat.com Tue Aug 7 20:08:22 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 16:08:22 -0400 Subject: [Fedora-livecd-list] [PATCH] print out what urls are being downloaded, more verbose yum Message-ID: <1186517302.3674.23.camel@neutron.verbum.private> This patch was useful for debugging the first one. From walters at redhat.com Tue Aug 7 20:09:13 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 16:09:13 -0400 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default Message-ID: <1186517353.3674.26.camel@neutron.verbum.private> This makes it so things aren't all named livecd-. From katzj at redhat.com Tue Aug 7 20:35:01 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 16:35:01 -0400 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B830CD.6000801@filteredperception.org> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> <46B830CD.6000801@filteredperception.org> Message-ID: <1186518901.11906.15.camel@localhost.localdomain> On Tue, 2007-08-07 at 03:43 -0500, Douglas McClendon wrote: > Jeroen van Meeuwen wrote: > > Jeremy Katz wrote: > >> On Mon, 2007-08-06 at 23:21 +0200, Jeroen van Meeuwen wrote: > >>> Jeremy Katz wrote: > >>>> On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: > >>>>> A patch to enable setting the build directory. > >>>>> > >>>>> This adds more flexibility for those who don't have as much space in > >>>>> /var/tmp. > >>>> If you don't have space in /var/tmp, just use > >>>> --tmpdir=/some/other/dir/with/space. Setting the build directory just > >>>> sets people up for either a) deleting things they don't intend to or b) > >>>> getting stale data in their build > >>> Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp > >>> issue. Push comes to shovel, I really don't need to set the build_dir to > >>> anything I can think of, rather then just use the > >>> InstallationTarget.build_dir for any reference after I import > >>> livecd-creator and create the extended InstallationTarget instance. > >> This sounds a lot better to me... > >> > >>> I'm not sure though what you mean by a) and b) though. AFAICT these > >>> would never just happen because build_dir === build_dir, regardless of > >>> what you set it to, or how you set it. > > >> Okay, we don't actually do any removal, so you won't hit that. But if > >> you set a build_dir that already exists, then you're setting up for some > >> "interesting" conditions. By ensuring that it's a new mkdtemp'd dir, we > >> can be certain that we own it, that it's unique, and that no one has > >> done anything with it first > > > Are you actually certain that you don't do any removal? Indeed there is -- I thought there was, but then my quick look yesterday didn't see it. That really makes this a bit (okay, a lot) scary as it's basically a quick path to nuking your system which is something that we try pretty hard to be careful to not do. And since you can just make use of the build dir after instantiating, I think the risk is more than the gain Jeremy From katzj at redhat.com Tue Aug 7 20:47:52 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 16:47:52 -0400 Subject: [Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application In-Reply-To: <46B79791.4070807@kanarip.com> References: <46B61904.5040803@kanarip.com> <1186434361.20556.74.camel@erebor.boston.redhat.com> <46B79791.4070807@kanarip.com> Message-ID: <1186519672.11906.29.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:50 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-05 at 20:37 +0200, Jeroen van Meeuwen wrote: > >> A patch to prevent livecd-creator from also killing the application that > >> is build on top of livecd-tools, while not changing the default behaviour. > > > > Better would be a patch to use the YumBase.close() method in yum >= > > 3.1.7. And then perhaps fallback to the current behavior for older yum > > (although I'm not against just requiring yum 3.2.x at this point I don't > > think) > > Hey, this just works for us. It may "just work", but it's not the best approach and when I come back in six months or a year or whenever and try to figure out what the reasoning was, it's not going to be very obvious as to why there's an option here and who calls with the option and why they needed it. At which point either the code lives on, rotting and potentially unused and adding to the learning curve, or I remove it and hope it doesn't break someone. > I'm not the maintainer of livecd-tools nor > do I have commit access. Make me have one of these things before you > tell me what is better, while /and/ not applying the better change you > suggest yourself, /and/ not applying the patch I sent you. As I tried to convey yesterday on IRC, that's not the way that open source development works. Iteration of submitted patches based on feedback from the maintainer to get to the best solution is a part of how things get accepted. In the long-term, this sort of peer review leads to better code in the project being discussed and is also a part of the pedagogical process. Commit access to a project is a result of sending patches that the maintainer is comfortable with to the point that it's easier to just let them be committed. Or, in some projects, commit access only ever rests with the maintainer (cf: the kernel which only Linus directly commits to). Granted, I don't want to go to that extreme as I think that multiple committers is generally a better way to do things. But not as a carrot for rewriting patches. Jeremy From ddmbox2000 at yahoo.co.uk Tue Aug 7 20:57:44 2007 From: ddmbox2000 at yahoo.co.uk (dexter) Date: Tue, 7 Aug 2007 21:57:44 +0100 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default In-Reply-To: <1186517353.3674.26.camel@neutron.verbum.private> References: <1186517353.3674.26.camel@neutron.verbum.private> Message-ID: <200708072157.45178.ddmbox2000@yahoo.co.uk> On Tue August 7 2007 21:09:13 Colin Walters wrote: > This makes it so things aren't all named livecd-. Please resend all patches coz it got mangled! ...dex From tchung at fedoraproject.org Tue Aug 7 21:05:44 2007 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 7 Aug 2007 14:05:44 -0700 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default In-Reply-To: <200708072157.45178.ddmbox2000@yahoo.co.uk> References: <1186517353.3674.26.camel@neutron.verbum.private> <200708072157.45178.ddmbox2000@yahoo.co.uk> Message-ID: <369bce3b0708071405of37910fia8cee9954e8008ec@mail.gmail.com> On 8/7/07, dexter wrote: > On Tue August 7 2007 21:09:13 Colin Walters wrote: > > This makes it so things aren't all named livecd-. > > Please resend all patches coz it got mangled! > > > ...dex BTW, if possible, please use fedora people for any files and patches. http://fedorapeople.org/ Regards, -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From katzj at redhat.com Tue Aug 7 21:03:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:03:56 -0400 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <46B799D8.70506@kanarip.com> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> Message-ID: <1186520636.11906.46.camel@localhost.localdomain> On Mon, 2007-08-06 at 23:59 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-05 at 20:40 +0200, Jeroen van Meeuwen wrote: > >> A patch which allows multiple kernels to be installed on the live media, > >> giving boot options in the syslinux menu for all of them. > > > > This part looks mostly reasonable... > > > >> In addition, this patch adds an optional timeout parameter for the boot > >> menu. It also adds a cli parameter for appending boot options. > > > > I think a better approach for this, though, is to extend the kickstart > > bootloader syntax a little bit. The proliferation of command-line > > options for this is a little ridiculous. Also, it leads to the images > > not being reproducible just from the kickstart config > > It's never reproducible from kickstart config as kickstart is not > allowing you to set specific version numbers, nor filesystem > compression, prelinking, ignoring deleted files, etc. Version numbers should be able to be specified if you want that level of reproducibility. Filesystem compression/ignoring deleted files are largely developer options for convenience and not something which (in my mind at least) should be a part of a "production" image. Adding the prelinking option was, in retrospect, something of a mistake and should either have been done by extending kickstart or just using the %post. I actually want to sit down and do some clean-up of the options to sort of "hide" the developer only options and try to make it more obvious that the kickstart config is the way to go > I'd rather have some error, bug or dis-functionality that I can fix. I > can't read your mind and think of the better approach without seeing the > code live in some upstream source repository. If it's reasonable, like > the previous patch, you get to apply it and _then_ think of a better > way, then apply that. Just a cloud of better ideas doesn't make it rain. No, you get feedback to the patch saying "maybe try this way instead" and that can point you down a path that's cleaner. It doesn't have to be in the upstream repo to get feedback and act on it. Maybe I wasn't clear enough in what I was suggesting, so I'll try to flesh it out a little more. Rather than command line options for the timeout, preferred kernel and bootloader options, we should probably use the existing kickstart "bootloader" stanza and extend it a bit. It already has an option to specify additional kernel options ("--append") which we can use. And then it would make sense to also have it take a --timeout and --defaultkernel (or similar) option. This will let us parse the info from the config rather than from the command line and carrying things around Ultimately, we'll want this in pykickstart itself, but we could start with a subclass of the KickstartParser with a custom KickstartHandler for the bootloader command. Just the patch to pykickstart is likely to be simpler, though. And having the livecd-creator patch depend on the pykickstart change is okay Jeremy From katzj at redhat.com Tue Aug 7 21:10:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:10:48 -0400 Subject: [Fedora-livecd-list] [PATCH 6/6] Several Kernels In-Reply-To: <1186445082.29420.31.camel@damaestro> References: <46B619B0.4060900@kanarip.com> <1186434475.20556.77.camel@erebor.boston.redhat.com> <46B799D8.70506@kanarip.com> <46B7A0CF.5000800@filteredperception.org> <46B7A267.4040008@kanarip.com> <46B7A4FE.4000208@filteredperception.org> <1186445082.29420.31.camel@damaestro> Message-ID: <1186521048.11906.55.camel@localhost.localdomain> On Mon, 2007-08-06 at 18:04 -0600, Jonathan Steffan wrote: > It's a matter of livecd-creator not wanting to be imported and > subclassed. Ignore that the sys.path.append() is more then nasty, but it > does help to illustrate discussion we have had in the past around the > time of the Fedora 7 release. The revisor team has wanted the livecd > bits to be importable (in a similar way that pungi has allowed us to) > and when that was denied we had to make the controversial decision to > pull the full source into revisor. My understanding, at least this is > what I took from the discussion, is that livecd-creator is just not > ready to be imported and is offering nothing resembling a stable > API/code base. This didn't bother us at all, we were willing to fix any > issue that arises from changes in livecd-creator and the way we utilized > the code in revisor. I know that you guys don't mind. But the problem is that once it's installed, it's open season for anyone else who might want to depend on it also. And it happens. Trust me. There are some bits that snuck into rhpl to be "only" used by anaconda and firstboot, yet have ended up in all kinds of other places. Making it a lot harder to change them, fix them or otherwise improve them. So really, the fact that we're not guaranteeing any sort of API is just what lets us continue to _make_ large changes, some of which you've proposed and other that have been by others[1]. If this were all C, then interface versioning is doable and not that painful... being python, a lot of that functionality doesn't exist Douglas's idea of doing a symlink if you really want to import now is one of the best I've seen and I don't know why I didn't think about it when we had this discussion months ago. Jeremy [1] On my todo list for pre-test2 that will impact the internal API of livecd-creator is getting the patches from dwmw2/spot merged for ppc and sparc. And if there's time, I do want to get back to markmc's "image abstraction" patches as I know there's a fair bit of desire around them as well. From katzj at redhat.com Tue Aug 7 21:15:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:15:51 -0400 Subject: [Fedora-livecd-list] [PATCH] default to using a global livecd yum cache, not a private one In-Reply-To: <1186517256.3674.20.camel@neutron.verbum.private> References: <1186517256.3674.20.camel@neutron.verbum.private> Message-ID: <1186521351.11906.60.camel@localhost.localdomain> On Tue, 2007-08-07 at 16:07 -0400, Colin Walters wrote: > This patch moves the yum cache into /var/cache/livecd so that out of the > box, the tool doesn't repeatedly download stuff from the internet. Patch is empty :) But going from the earlier patch you put in bugzilla, I know the gist of this. And it's along a similar line as kanarip's patch to allow specifying the cache dir. The question is are we better off just going with a global one always or allowing it to be specified and if you want to share, then you can specify the global one. And I can see both sides, although I somewhat lean towards allowing it to be specified. One thing that becomes tricky in either case is how do we handle cleaning the directory? Currently, it's simple -- it gets blown away every time. When doing a shared or global cache, you don't want to blow it away, but you also want to make it easy for people to regain the disk space. Maybe the answer is that if you specify the cache, then we don't blow it away and otherwise we do. Other opinions? Jeremy From katzj at redhat.com Tue Aug 7 21:19:54 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:19:54 -0400 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default In-Reply-To: <369bce3b0708071405of37910fia8cee9954e8008ec@mail.gmail.com> References: <1186517353.3674.26.camel@neutron.verbum.private> <200708072157.45178.ddmbox2000@yahoo.co.uk> <369bce3b0708071405of37910fia8cee9954e8008ec@mail.gmail.com> Message-ID: <1186521594.11906.65.camel@localhost.localdomain> On Tue, 2007-08-07 at 14:05 -0700, Thomas Chung wrote: > On 8/7/07, dexter wrote: > > On Tue August 7 2007 21:09:13 Colin Walters wrote: > > > This makes it so things aren't all named livecd-. > > > > Please resend all patches coz it got mangled! > > BTW, if possible, please use fedora people for any files and patches. Attaching patches is far preferred to just posting a link to them -- it's a lot easier to review them inline without having to go and fetch them from somewhere. Also, inline as opposed to attached is also nice if your mailer doesn't mangle attachments. git-send-email is an incredibly useful tool for this. But, I'm not anti-attachment as my mailer can handle them fine (unlike Linus :-) Jeremy From katzj at redhat.com Tue Aug 7 21:22:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:22:04 -0400 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <46B79EBE.2070007@kanarip.com> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> Message-ID: <1186521724.11906.69.camel@localhost.localdomain> On Tue, 2007-08-07 at 00:20 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: > >> Jeremy Katz wrote: > >>> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: > >>>> livecd-creator's InstallationTarget.install() seems to run > >>>> self.configureSystem(), then run self.configureNetwork(), possible > >>>> overriding some configuration files generated with %post. > >>> Hmm, the question is when is the best point at which to do this. After > >>> configuring the network or really as last as possible? The latter seems > >>> to fit better with when its run on an install > >> +1 > > > > Want to send a revised patch? :-) > > Well, as it is now it does apply at the very last moment, exactly the > way the installer works, right? There are a few steps (relabeling, prelinking, making the initrd) that are happening after runPost() of your patch. If the %post is going to be the absolute last thing, it should probably be after all of these Jeremy From kanarip at kanarip.com Tue Aug 7 21:28:49 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 07 Aug 2007 23:28:49 +0200 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B830CD.6000801@filteredperception.org> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> <46B830CD.6000801@filteredperception.org> Message-ID: <46B8E411.2050206@kanarip.com> Douglas McClendon wrote: > Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Mon, 2007-08-06 at 23:21 +0200, Jeroen van Meeuwen wrote: >>>> Jeremy Katz wrote: >>>>> On Sun, 2007-08-05 at 20:24 +0200, Jeroen van Meeuwen wrote: >>>>>> A patch to enable setting the build directory. >>>>>> >>>>>> This adds more flexibility for those who don't have as much space in >>>>>> /var/tmp. >>>>> If you don't have space in /var/tmp, just use >>>>> --tmpdir=/some/other/dir/with/space. Setting the build directory just >>>>> sets people up for either a) deleting things they don't intend to >>>>> or b) >>>>> getting stale data in their build >>>> Right, tmpdir does evade the i-do-not-have-enough-space-in-/var/tmp >>>> issue. Push comes to shovel, I really don't need to set the >>>> build_dir to >>>> anything I can think of, rather then just use the >>>> InstallationTarget.build_dir for any reference after I import >>>> livecd-creator and create the extended InstallationTarget instance. >>> This sounds a lot better to me... >>> >>>> I'm not sure though what you mean by a) and b) though. AFAICT these >>>> would never just happen because build_dir === build_dir, regardless of >>>> what you set it to, or how you set it. > > >>> Okay, we don't actually do any removal, so you won't hit that. But if >>> you set a build_dir that already exists, then you're setting up for some >>> "interesting" conditions. By ensuring that it's a new mkdtemp'd dir, we >>> can be certain that we own it, that it's unique, and that no one has >>> done anything with it first > > > Are you actually certain that you don't do any removal? > > def teardown(self): > if self.build_dir: > self.unmount() > shutil.rmtree(self.build_dir, ignore_errors = True) > Right on. There's an addition problem with having tempfile.mkdtemp(), and that is that mounts can not easily be unmounted in a next run, if the creation of live media fails in one way or the other. Having a "static" build_dir, it can be used to check for existance, and be unmounted. You'd not be running out of loop devices anymore. If the directory already exists, the app complains and exits appropriately, or allows the user to act upon it and save his data. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Tue Aug 7 21:26:59 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:26:59 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <46B617E5.9060704@kanarip.com> References: <46B617E5.9060704@kanarip.com> Message-ID: <1186522019.11906.73.camel@localhost.localdomain> So, I commented a little on Colin's related patch... I'm leaning towards this approach, though. On Sun, 2007-08-05 at 20:33 +0200, Jeroen van Meeuwen wrote: > A patch to change the location of the yum cache directory. > > This enables existing yum cache to be used, which in our case is > especially useful because that cache is populated already. Most > importantly, livecd-creator doesn't bind mount the yum cache directory. Why not do the bind mount? By bind mounting the cache as /var/cache/yum in the chroot, you don't have to do any mucking with the yum config which should make it so that you just have to get the option and if it doesn't exist, fall back to the default. It also makes the cachedir available to the chroot in %post which people could take advantage of if they wanted Jeremy From katzj at redhat.com Tue Aug 7 21:37:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:37:42 -0400 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B8E411.2050206@kanarip.com> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> <46B830CD.6000801@filteredperception.org> <46B8E411.2050206@kanarip.com> Message-ID: <1186522662.11906.83.camel@localhost.localdomain> On Tue, 2007-08-07 at 23:28 +0200, Jeroen van Meeuwen wrote: > There's an addition problem with having tempfile.mkdtemp(), and that is > that mounts can not easily be unmounted in a next run, if the creation > of live media fails in one way or the other. Having a "static" > build_dir, it can be used to check for existance, and be unmounted. > You'd not be running out of loop devices anymore. If the directory > already exists, the app complains and exits appropriately, or allows the > user to act upon it and save his data. What/how are you expecting the user to do on the failure? Why not teardown immediately on failure (or at least, before you throw away the object you had)? Outside of cases where we're currently traceback'ing and not catching it[1], livecd-creator should be cleaning up after itself on error pretty much all the time and thus not running out of loop devices Jeremy [1] Hopefully a dwindling number... it seems to be, but if there are other cases people hit, let me know either by filing a bug or sending a patch! From dmc.fedora at filteredperception.org Tue Aug 7 21:42:30 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 07 Aug 2007 16:42:30 -0500 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <1186521724.11906.69.camel@localhost.localdomain> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> <1186521724.11906.69.camel@localhost.localdomain> Message-ID: <46B8E746.8070900@filteredperception.org> Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:20 +0200, Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: >>>> Jeremy Katz wrote: >>>>> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: >>>>>> livecd-creator's InstallationTarget.install() seems to run >>>>>> self.configureSystem(), then run self.configureNetwork(), possible >>>>>> overriding some configuration files generated with %post. >>>>> Hmm, the question is when is the best point at which to do this. After >>>>> configuring the network or really as last as possible? The latter seems >>>>> to fit better with when its run on an install >>>> +1 >>> Want to send a revised patch? :-) >> Well, as it is now it does apply at the very last moment, exactly the >> way the installer works, right? > > There are a few steps (relabeling, prelinking, making the initrd) that > are happening after runPost() of your patch. If the %post is going to > be the absolute last thing, it should probably be after all of these This might be the wrong list to be asking this, but out of curiosity- Why can't relabeling be done if the host is running with selinux disabled? (selinux=0) It's just writing some metadata to the fs right? Seems like it should be possible. And on a seperate note, I agree that prelinking really ought to be done in %post. That's something that a kickstart user might be interested in doing in the non-livecd case as well, for the same reasons, right? -dmc From walters at redhat.com Tue Aug 7 21:43:53 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 17:43:53 -0400 Subject: [Fedora-livecd-list] [PATCH] default to using a global livecd yum cache, not a private one In-Reply-To: <1186517256.3674.20.camel@neutron.verbum.private> References: <1186517256.3674.20.camel@neutron.verbum.private> Message-ID: <1186523033.3674.31.camel@neutron.verbum.private> On Tue, 2007-08-07 at 16:07 -0400, Colin Walters wrote: > Hi, > > This patch moves the yum cache into /var/cache/livecd so that out of the > box, the tool doesn't repeatedly download stuff from the internet. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-default-to-using-a-global-livecd-yum-cache-not-a-pr.patch Type: text/x-patch Size: 1476 bytes Desc: not available URL: From walters at redhat.com Tue Aug 7 21:44:08 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 17:44:08 -0400 Subject: [Fedora-livecd-list] [PATCH] print out what urls are being downloaded, more verbose yum In-Reply-To: <1186517302.3674.23.camel@neutron.verbum.private> References: <1186517302.3674.23.camel@neutron.verbum.private> Message-ID: <1186523048.3674.33.camel@neutron.verbum.private> On Tue, 2007-08-07 at 16:08 -0400, Colin Walters wrote: > This patch was useful for debugging the first one. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-print-out-what-urls-are-being-downloaded-more-verbo.patch Type: text/x-patch Size: 1217 bytes Desc: not available URL: From walters at redhat.com Tue Aug 7 21:44:25 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 17:44:25 -0400 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default In-Reply-To: <1186517353.3674.26.camel@neutron.verbum.private> References: <1186517353.3674.26.camel@neutron.verbum.private> Message-ID: <1186523065.3674.35.camel@neutron.verbum.private> On Tue, 2007-08-07 at 16:09 -0400, Colin Walters wrote: > This makes it so things aren't all named livecd-. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-pick-a-better-fs-label-by-default.patch Type: text/x-patch Size: 1909 bytes Desc: not available URL: From walters at redhat.com Tue Aug 7 21:49:41 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 07 Aug 2007 17:49:41 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <1186522019.11906.73.camel@localhost.localdomain> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> Message-ID: <1186523381.3674.40.camel@neutron.verbum.private> On Tue, 2007-08-07 at 17:26 -0400, Jeremy Katz wrote: > So, I commented a little on Colin's related patch... I'm leaning towards > this approach, though. If using the system yum cache works, that makes a lot of sense to me. My worry was the sqlite etc. files in the system directory and that if the system yum runs at the same time as the chroot one they'd stomp on each other's data. From katzj at redhat.com Tue Aug 7 21:54:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 17:54:43 -0400 Subject: [Fedora-livecd-list] Commits to the list? Message-ID: <1186523683.11906.89.camel@localhost.localdomain> Okay, I've finally gotten the git commit mail script to work with the weird git setup on git.fedoraproject.org. Any objections to send the commit mails to the list? Jeremy From katzj at redhat.com Tue Aug 7 23:38:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 07 Aug 2007 19:38:34 -0400 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <46B8E746.8070900@filteredperception.org> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> <1186521724.11906.69.camel@localhost.localdomain> <46B8E746.8070900@filteredperception.org> Message-ID: <1186529914.3096.5.camel@localhost.localdomain> On Tue, 2007-08-07 at 16:42 -0500, Douglas McClendon wrote: > This might be the wrong list to be asking this, but out of curiosity- > > Why can't relabeling be done if the host is running with selinux > disabled? (selinux=0) > It's just writing some metadata to the fs right? Seems like it should > be possible. Because the kernel developers have deemed it unsafe to write out any security xattrs which aren't understood by the kernel. The fact that they then get mapped to unlabeled_t doesn't seem to make much difference. Frankly, I think they're wrong, but lengthy attempts to convince them in the past have been unsuccessful. Maybe it's worth tilting at that windmill again. Dunno. > And on a seperate note, I agree that prelinking really ought to be done > in %post. That's something that a kickstart user might be interested in > doing in the non-livecd case as well, for the same reasons, right? Yep. Jeremy From notting at redhat.com Wed Aug 8 00:27:36 2007 From: notting at redhat.com (Bill Nottingham) Date: Tue, 7 Aug 2007 20:27:36 -0400 Subject: [Fedora-livecd-list] [PATCH] default to using a global livecd yum cache, not a private one In-Reply-To: <1186521351.11906.60.camel@localhost.localdomain> References: <1186517256.3674.20.camel@neutron.verbum.private> <1186521351.11906.60.camel@localhost.localdomain> Message-ID: <20070808002736.GA20037@nostromo.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > On Tue, 2007-08-07 at 16:07 -0400, Colin Walters wrote: > > This patch moves the yum cache into /var/cache/livecd so that out of the > > box, the tool doesn't repeatedly download stuff from the internet. > > Patch is empty :) But going from the earlier patch you put in bugzilla, > I know the gist of this. And it's along a similar line as kanarip's > patch to allow specifying the cache dir. The question is are we better > off just going with a global one always or allowing it to be specified > and if you want to share, then you can specify the global one. And I > can see both sides, although I somewhat lean towards allowing it to be > specified. > > One thing that becomes tricky in either case is how do we handle > cleaning the directory? Currently, it's simple -- it gets blown away > every time. When doing a shared or global cache, you don't want to blow > it away, but you also want to make it easy for people to regain the disk > space. Maybe the answer is that if you specify the cache, then we don't > blow it away and otherwise we do. Other opinions? Surely you'd want to unify the yum caches among pungi and livecd-creator? Bill From dmc.fedora at filteredperception.org Wed Aug 8 00:54:46 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 07 Aug 2007 19:54:46 -0500 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <1186529914.3096.5.camel@localhost.localdomain> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> <1186521724.11906.69.camel@localhost.localdomain> <46B8E746.8070900@filteredperception.org> <1186529914.3096.5.camel@localhost.localdomain> Message-ID: <46B91456.1010002@filteredperception.org> Jeremy Katz wrote: > On Tue, 2007-08-07 at 16:42 -0500, Douglas McClendon wrote: >> This might be the wrong list to be asking this, but out of curiosity- >> >> Why can't relabeling be done if the host is running with selinux >> disabled? (selinux=0) >> It's just writing some metadata to the fs right? Seems like it should >> be possible. > > Because the kernel developers have deemed it unsafe to write out any > security xattrs which aren't understood by the kernel. The fact that > they then get mapped to unlabeled_t doesn't seem to make much > difference. Frankly, I think they're wrong, but lengthy attempts to > convince them in the past have been unsuccessful. Maybe it's worth > tilting at that windmill again. Dunno. Thats the sort of info I was looking for. I'm probably part of a very small group of people who would notice, and even I don't care that much. I'll post a little script one of these days that gets around it :) -dmc From kanarip at kanarip.com Wed Aug 8 10:53:26 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 08 Aug 2007 12:53:26 +0200 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <1186521724.11906.69.camel@localhost.localdomain> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> <1186521724.11906.69.camel@localhost.localdomain> Message-ID: <46B9A0A6.4000603@kanarip.com> Jeremy Katz wrote: > On Tue, 2007-08-07 at 00:20 +0200, Jeroen van Meeuwen wrote: >> Jeremy Katz wrote: >>> On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: >>>> Jeremy Katz wrote: >>>>> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: >>>>>> livecd-creator's InstallationTarget.install() seems to run >>>>>> self.configureSystem(), then run self.configureNetwork(), possible >>>>>> overriding some configuration files generated with %post. >>>>> Hmm, the question is when is the best point at which to do this. After >>>>> configuring the network or really as last as possible? The latter seems >>>>> to fit better with when its run on an install >>>> +1 >>> Want to send a revised patch? :-) >> Well, as it is now it does apply at the very last moment, exactly the >> way the installer works, right? > > There are a few steps (relabeling, prelinking, making the initrd) that > are happening after runPost() of your patch. If the %post is going to > be the absolute last thing, it should probably be after all of these > It'd be plausible to have relabeling, prelinking and making the initrd occur after %post, but %post should apply to whatever else we do with kickstart information, right? I think where it is now, it fits perfectly. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Wed Aug 8 10:59:36 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 08 Aug 2007 12:59:36 +0200 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <1186522662.11906.83.camel@localhost.localdomain> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> <46B830CD.6000801@filteredperception.org> <46B8E411.2050206@kanarip.com> <1186522662.11906.83.camel@localhost.localdomain> Message-ID: <46B9A218.6000900@kanarip.com> Jeremy Katz wrote: > On Tue, 2007-08-07 at 23:28 +0200, Jeroen van Meeuwen wrote: >> There's an addition problem with having tempfile.mkdtemp(), and that is >> that mounts can not easily be unmounted in a next run, if the creation >> of live media fails in one way or the other. Having a "static" >> build_dir, it can be used to check for existance, and be unmounted. >> You'd not be running out of loop devices anymore. If the directory >> already exists, the app complains and exits appropriately, or allows the >> user to act upon it and save his data. > > What/how are you expecting the user to do on the failure? Why not > teardown immediately on failure (or at least, before you throw away the > object you had)? Outside of cases where we're currently traceback'ing > and not catching it[1], livecd-creator should be cleaning up after > itself on error pretty much all the time and thus not running out of > loop devices > True. On the other hand one may need/want to inspect the tree, in our case we usually do. If everything is tried and excepted, teardown on failure should be optional, or requested feedback upon in the form of a dialog: "We failed and now want to clean up. Do you want to inspect the tree first? Navigate there and there and knock yourself out." "Now, do you want to keep this tree for further investigation? [y/N]: " Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Wed Aug 8 13:51:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 08 Aug 2007 15:51:17 +0200 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <1186522019.11906.73.camel@localhost.localdomain> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> Message-ID: <46B9CA55.5090408@kanarip.com> Jeremy Katz wrote: > So, I commented a little on Colin's related patch... I'm leaning towards > this approach, though. > > On Sun, 2007-08-05 at 20:33 +0200, Jeroen van Meeuwen wrote: >> A patch to change the location of the yum cache directory. >> >> This enables existing yum cache to be used, which in our case is >> especially useful because that cache is populated already. Most >> importantly, livecd-creator doesn't bind mount the yum cache directory. > > Why not do the bind mount? By bind mounting the cache as /var/cache/yum > in the chroot, you don't have to do any mucking with the yum config > which should make it so that you just have to get the option and if it > doesn't exist, fall back to the default. It also makes the cachedir > available to the chroot in %post which people could take advantage of if > they wanted > I'm not sure I understand what you mean by 'any mucking with the yum config'. Is it the 'temp' yum config livecd-tools you're talking about, LiveCDYum._writeConf()? That config isn't used in our case so it doesn't need any mucking, but I understand your point -if the --yumcache option is in livecd-tools and it doesn't get bind mounted, that'd need mucking. Bind mounting or not bind mounting is a different matter; it doesn't need discussion as much, because there's no specific reason we currently don't bind mount. It's no show-stopper -that I know of. If the patch did the bind mount and let's one choose the yum cache directory to use (e.g., to bind mount), all is fine, right? Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Wed Aug 8 16:17:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:17:26 -0400 Subject: [Fedora-livecd-list] [PATCH] print out what urls are being downloaded, more verbose yum In-Reply-To: <1186523048.3674.33.camel@neutron.verbum.private> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> Message-ID: <1186589846.3096.24.camel@localhost.localdomain> On Tue, 2007-08-07 at 17:44 -0400, Colin Walters wrote: > +class TextProgress(object): > + def start(self, filename, url, *args, **kwargs): > + print "Retrieving %s" % (url,) > + self.url = url > + def update(self, *args): > + pass > + def end(self, *args): > + print "Retrieved %s OK" % (self.url,) Why two lines for every package? Seems like we should be able to just have the retrieving when it starts (and no newline) and then "OK" when it completes. > @@ -189,7 +198,7 @@ class LiveCDYum(yum.YumBase): > conf += "installroot=%s\n" % installroot > conf += "cachedir=/var/cache/yum\n" > conf += "plugins=0\n" > - conf += "debuglevel=2\n" > + conf += "debuglevel=3\n" > conf += "reposdir=\n" What does debuglevel of 3 vs 2 give you? 2 is the default with yum, and I don't really know that making it higher for livecd-tools makes sense. It probably does, though, make sense to think about a --quiet and --verbose as we get more things which output more. Jeremy From walters at redhat.com Wed Aug 8 16:36:36 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 08 Aug 2007 12:36:36 -0400 Subject: [Fedora-livecd-list] [PATCH] print out what urls are being downloaded, more verbose yum In-Reply-To: <1186589846.3096.24.camel@localhost.localdomain> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> <1186589846.3096.24.camel@localhost.localdomain> Message-ID: <1186590996.3187.2.camel@neutron.verbum.private> On Wed, 2007-08-08 at 12:17 -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 17:44 -0400, Colin Walters wrote: > > +class TextProgress(object): > > + def start(self, filename, url, *args, **kwargs): > > + print "Retrieving %s" % (url,) > > + self.url = url > > + def update(self, *args): > > + pass > > + def end(self, *args): > > + print "Retrieved %s OK" % (self.url,) > > Why two lines for every package? Seems like we should be able to just > have the retrieving when it starts (and no newline) and then "OK" when > it completes. Mainly because that creates the assumption that it will be the only function showing output during that time. > > @@ -189,7 +198,7 @@ class LiveCDYum(yum.YumBase): > > conf += "installroot=%s\n" % installroot > > conf += "cachedir=/var/cache/yum\n" > > conf += "plugins=0\n" > > - conf += "debuglevel=2\n" > > + conf += "debuglevel=3\n" > > conf += "reposdir=\n" > > What does debuglevel of 3 vs 2 give you? 2 is the default with yum, and > I don't really know that making it higher for livecd-tools makes sense. > It probably does, though, make sense to think about a --quiet and > --verbose as we get more things which output more. This change should probably not be included; I don't remember now why I did that. Anyways, this patch isn't really important; the only one I actually care about is the caching patch. From katzj at redhat.com Wed Aug 8 16:34:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:34:51 -0400 Subject: [Fedora-livecd-list] [PATCH] pick a better fs label by default In-Reply-To: <1186523065.3674.35.camel@neutron.verbum.private> References: <1186517353.3674.26.camel@neutron.verbum.private> <1186523065.3674.35.camel@neutron.verbum.private> Message-ID: <1186590891.3096.26.camel@localhost.localdomain> On Tue, 2007-08-07 at 17:44 -0400, Colin Walters wrote: > On Tue, 2007-08-07 at 16:09 -0400, Colin Walters wrote: > > This makes it so things aren't all named livecd-. Looks reasonable enough and seems to work okay even with super long label names. Applied. Thanks for the patch Jeremy From katzj at redhat.com Wed Aug 8 16:37:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:37:51 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <1186523381.3674.40.camel@neutron.verbum.private> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> <1186523381.3674.40.camel@neutron.verbum.private> Message-ID: <1186591071.3096.30.camel@localhost.localdomain> On Tue, 2007-08-07 at 17:49 -0400, Colin Walters wrote: > On Tue, 2007-08-07 at 17:26 -0400, Jeremy Katz wrote: > > So, I commented a little on Colin's related patch... I'm leaning towards > > this approach, though. > > If using the system yum cache works, that makes a lot of sense to me. The nice thing with allowing it to be specified is that you can either end up with a) unspecified does a private cache, just like now (this is an important case to keep working, especially when doing multiple builds at a time from a fast local source) b) you can specify the system cache if you're pointing at the same repos as your system. that can save you download time, etc if you do keepcache=0 in your system yum.conf or do your system update after creating a live image c) you can specify something like /var/tmp/livecd-cache if you want to have a livecd-specific cache. Jeremy From katzj at redhat.com Wed Aug 8 16:39:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:39:02 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <46B9CA55.5090408@kanarip.com> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> <46B9CA55.5090408@kanarip.com> Message-ID: <1186591142.3096.33.camel@localhost.localdomain> On Wed, 2007-08-08 at 15:51 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > So, I commented a little on Colin's related patch... I'm leaning towards > > this approach, though. > > > > On Sun, 2007-08-05 at 20:33 +0200, Jeroen van Meeuwen wrote: > >> A patch to change the location of the yum cache directory. > >> > >> This enables existing yum cache to be used, which in our case is > >> especially useful because that cache is populated already. Most > >> importantly, livecd-creator doesn't bind mount the yum cache directory. > > > > Why not do the bind mount? By bind mounting the cache as /var/cache/yum > > in the chroot, you don't have to do any mucking with the yum config > > which should make it so that you just have to get the option and if it > > doesn't exist, fall back to the default. It also makes the cachedir > > available to the chroot in %post which people could take advantage of if > > they wanted > > > > I'm not sure I understand what you mean by 'any mucking with the yum > config'. Is it the 'temp' yum config livecd-tools you're talking about, > LiveCDYum._writeConf()? Yep. > That config isn't used in our case so it doesn't > need any mucking, but I understand your point -if the --yumcache option > is in livecd-tools and it doesn't get bind mounted, that'd need mucking. > > Bind mounting or not bind mounting is a different matter; it doesn't > need discussion as much, because there's no specific reason we currently > don't bind mount. It's no show-stopper -that I know of. Right, I think that bind mounting makes the patch simpler and still gets the same result. So if there's not a reason the bind mount won't work for you, let's go that route > If the patch did the bind mount and let's one choose the yum cache > directory to use (e.g., to bind mount), all is fine, right? Yep, should be good to go Jeremy From katzj at redhat.com Wed Aug 8 16:43:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:43:48 -0400 Subject: [Fedora-livecd-list] [patch] Configuring Network after Configuring System In-Reply-To: <46B9A0A6.4000603@kanarip.com> References: <46B07996.90800@kanarip.com> <1186433881.20556.63.camel@erebor.boston.redhat.com> <46B78E0D.5010209@kanarip.com> <1186435583.9762.0.camel@localhost.localdomain> <46B79EBE.2070007@kanarip.com> <1186521724.11906.69.camel@localhost.localdomain> <46B9A0A6.4000603@kanarip.com> Message-ID: <1186591428.3096.38.camel@localhost.localdomain> On Wed, 2007-08-08 at 12:53 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Tue, 2007-08-07 at 00:20 +0200, Jeroen van Meeuwen wrote: > >> Jeremy Katz wrote: > >>> On Mon, 2007-08-06 at 23:09 +0200, Jeroen van Meeuwen wrote: > >>>> Jeremy Katz wrote: > >>>>> On Wed, 2007-08-01 at 14:16 +0200, Jeroen van Meeuwen wrote: > >>>>>> livecd-creator's InstallationTarget.install() seems to run > >>>>>> self.configureSystem(), then run self.configureNetwork(), possible > >>>>>> overriding some configuration files generated with %post. > >>>>> Hmm, the question is when is the best point at which to do this. After > >>>>> configuring the network or really as last as possible? The latter seems > >>>>> to fit better with when its run on an install > >>>> +1 > >>> Want to send a revised patch? :-) > >> Well, as it is now it does apply at the very last moment, exactly the > >> way the installer works, right? > > > > There are a few steps (relabeling, prelinking, making the initrd) that > > are happening after runPost() of your patch. If the %post is going to > > be the absolute last thing, it should probably be after all of these > > It'd be plausible to have relabeling, prelinking and making the initrd > occur after %post, but %post should apply to whatever else we do with > kickstart information, right? I think where it is now, it fits perfectly. Yeah, I can see it being plausible basically anywhere. That's why the position of %post has moved around from "right after packages installed" to "at the very end" to "at the very end, minus the CD eject" in anaconda over time. Hence, I lean towards at the very end just for consistency with current anaconda behavior Jeremy From katzj at redhat.com Wed Aug 8 16:47:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 12:47:09 -0400 Subject: [Fedora-livecd-list] [PATCH 1/6] Set the build directory In-Reply-To: <46B9A218.6000900@kanarip.com> References: <46B615F1.20500@kanarip.com> <1186433966.20556.65.camel@erebor.boston.redhat.com> <46B790EC.1010707@kanarip.com> <1186435698.9762.3.camel@localhost.localdomain> <46B79F0A.70203@kanarip.com> <46B830CD.6000801@filteredperception.org> <46B8E411.2050206@kanarip.com> <1186522662.11906.83.camel@localhost.localdomain> <46B9A218.6000900@kanarip.com> Message-ID: <1186591629.3096.42.camel@localhost.localdomain> On Wed, 2007-08-08 at 12:59 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > On Tue, 2007-08-07 at 23:28 +0200, Jeroen van Meeuwen wrote: > >> There's an addition problem with having tempfile.mkdtemp(), and that is > >> that mounts can not easily be unmounted in a next run, if the creation > >> of live media fails in one way or the other. Having a "static" > >> build_dir, it can be used to check for existance, and be unmounted. > >> You'd not be running out of loop devices anymore. If the directory > >> already exists, the app complains and exits appropriately, or allows the > >> user to act upon it and save his data. > > > > What/how are you expecting the user to do on the failure? Why not > > teardown immediately on failure (or at least, before you throw away the > > object you had)? Outside of cases where we're currently traceback'ing > > and not catching it[1], livecd-creator should be cleaning up after > > itself on error pretty much all the time and thus not running out of > > loop devices > > True. On the other hand one may need/want to inspect the tree, in our > case we usually do. If everything is tried and excepted, teardown on > failure should be optional, or requested feedback upon in the form of a > dialog: > > "We failed and now want to clean up. Do you want to inspect the tree > first? Navigate there and there and knock yourself out." > > "Now, do you want to keep this tree for further investigation? [y/N]: " And in this case, you just say "the tree is at /path/to/build_dir. be sure to clean up afterwards by running the following". Since you're going to have to say where it is _anyway_. And if they say they don't want to inspect it, then you can still have the object around to do the cleanup. Given the scariness of removing directories that are important to the system and the fact that there are other ways around the clean up case, I'm really having a hard time justifying this to myself. Jeremy From tim.wood at datawranglers.com Wed Aug 8 17:26:18 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Wed, 8 Aug 2007 11:26:18 -0600 Subject: [Fedora-livecd-list] [PATCH] print out what urls are being downloaded, more verbose yum In-Reply-To: <1186590996.3187.2.camel@neutron.verbum.private> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> <1186589846.3096.24.camel@localhost.localdomain> <1186590996.3187.2.camel@neutron.verbum.private> Message-ID: <435E2C12-7201-402E-B354-C50AFA44472F@datawranglers.com> FWIW, this would really help troubleshooting. Tim On Aug 8, 2007, at 10:36 AM, Colin Walters wrote: > On Wed, 2007-08-08 at 12:17 -0400, Jeremy Katz wrote: >> On Tue, 2007-08-07 at 17:44 -0400, Colin Walters wrote: >>> +class TextProgress(object): >>> + def start(self, filename, url, *args, **kwargs): >>> + print "Retrieving %s" % (url,) >>> + self.url = url >>> + def update(self, *args): >>> + pass >>> + def end(self, *args): >>> + print "Retrieved %s OK" % (self.url,) >> >> Why two lines for every package? Seems like we should be able to >> just >> have the retrieving when it starts (and no newline) and then "OK" >> when >> it completes. > > Mainly because that creates the assumption that it will be the only > function showing output during that time. > >>> @@ -189,7 +198,7 @@ class LiveCDYum(yum.YumBase): >>> conf += "installroot=%s\n" % installroot >>> conf += "cachedir=/var/cache/yum\n" >>> conf += "plugins=0\n" >>> - conf += "debuglevel=2\n" >>> + conf += "debuglevel=3\n" >>> conf += "reposdir=\n" >> >> What does debuglevel of 3 vs 2 give you? 2 is the default with >> yum, and >> I don't really know that making it higher for livecd-tools makes >> sense. >> It probably does, though, make sense to think about a --quiet and >> --verbose as we get more things which output more. > > This change should probably not be included; I don't remember now > why I > did that. > > Anyways, this patch isn't really important; the only one I actually > care > about is the caching patch. > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From walters at redhat.com Wed Aug 8 17:31:26 2007 From: walters at redhat.com (Colin Walters) Date: Wed, 08 Aug 2007 13:31:26 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <1186591071.3096.30.camel@localhost.localdomain> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> <1186523381.3674.40.camel@neutron.verbum.private> <1186591071.3096.30.camel@localhost.localdomain> Message-ID: <1186594286.3187.18.camel@neutron.verbum.private> On Wed, 2007-08-08 at 12:37 -0400, Jeremy Katz wrote: > On Tue, 2007-08-07 at 17:49 -0400, Colin Walters wrote: > > On Tue, 2007-08-07 at 17:26 -0400, Jeremy Katz wrote: > > > So, I commented a little on Colin's related patch... I'm leaning towards > > > this approach, though. > > > > If using the system yum cache works, that makes a lot of sense to me. > > The nice thing with allowing it to be specified is that you can either > end up with > a) unspecified does a private cache, just like now (this is an important > case to keep working, especially when doing multiple builds at a time > from a fast local source) I don't quite understand this one - the cache is in the tempdir as far as I can see; therefore it's not shared between builds? > b) you can specify the system cache if you're pointing at the same repos > as your system. that can save you download time, etc if you do > keepcache=0 in your system yum.conf or do your system update after > creating a live image (keepcache=1 I assume you mean) But is there the potential for things to break if multiple yum processes write to it? > c) you can specify something like /var/tmp/livecd-cache if you want to > have a livecd-specific cache. I don't really want it to be livecd-specific. The goal is just to have tools that by default do not repeatedly download huge files over the internet. I have plenty of gigs of hard drive space. Mock drove me absolutely nuts for this reason (yes, it has some magic --cache option that's not the default, requires manual intervention to update, and was broken anyways last I tried). Hmm. Would anything break if we just pointed all the tools at /var/cache/yum? Does yum delete all files it sees there if it has keepcache=0? And what about the concurrency issue? From katzj at redhat.com Wed Aug 8 19:47:10 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 08 Aug 2007 15:47:10 -0400 Subject: [Fedora-livecd-list] [PATCH 3/6] Setting the yumcache In-Reply-To: <1186594286.3187.18.camel@neutron.verbum.private> References: <46B617E5.9060704@kanarip.com> <1186522019.11906.73.camel@localhost.localdomain> <1186523381.3674.40.camel@neutron.verbum.private> <1186591071.3096.30.camel@localhost.localdomain> <1186594286.3187.18.camel@neutron.verbum.private> Message-ID: <1186602430.3096.52.camel@localhost.localdomain> On Wed, 2007-08-08 at 13:31 -0400, Colin Walters wrote: > On Wed, 2007-08-08 at 12:37 -0400, Jeremy Katz wrote: > > On Tue, 2007-08-07 at 17:49 -0400, Colin Walters wrote: > > > On Tue, 2007-08-07 at 17:26 -0400, Jeremy Katz wrote: > > > > So, I commented a little on Colin's related patch... I'm leaning towards > > > > this approach, though. > > > > > > If using the system yum cache works, that makes a lot of sense to me. > > > > The nice thing with allowing it to be specified is that you can either > > end up with > > a) unspecified does a private cache, just like now (this is an important > > case to keep working, especially when doing multiple builds at a time > > from a fast local source) > > I don't quite understand this one - the cache is in the tempdir as far > as I can see; therefore it's not shared between builds? Right -- because if I'm creating multiple images at a time, you otherwise run some risk (at least for now) of stomping over things. So having the default be the safe, though slower, route isn't a bad thing. > > b) you can specify the system cache if you're pointing at the same repos > > as your system. that can save you download time, etc if you do > > keepcache=0 in your system yum.conf or do your system update after > > creating a live image > > (keepcache=1 I assume you mean) But is there the potential for things > to break if multiple yum processes write to it? Yeah -- right now, the locking is at the "one yum process at a time" level. livecd-creator isn't taking that lock as, by default, we're not using those caches. It's probably worth looking at per-repo locks in yum for the future to avoid this sort of thing. But that starts to get a little bit more painful. > > c) you can specify something like /var/tmp/livecd-cache if you want to > > have a livecd-specific cache. > > I don't really want it to be livecd-specific. The goal is just to have > tools that by default do not repeatedly download huge files over the > internet. I have plenty of gigs of hard drive space. Mock drove me > absolutely nuts for this reason (yes, it has some magic --cache option > that's not the default, requires manual intervention to update, and was > broken anyways last I tried). > > Hmm. Would anything break if we just pointed all the tools > at /var/cache/yum? Does yum delete all files it sees there if it has > keepcache=0? And what about the concurrency issue? As of right now, pointing everything at the same place is likely a recipe for disaster. Making it _possible_ for things to share when the user is aware and wants to isn't unreasonable. And then, when we eventually get finer grained locking in place, we can look at moving the default to be shared between everything Jeremy From kanarip at kanarip.com Thu Aug 9 11:18:45 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 09 Aug 2007 13:18:45 +0200 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <1186523683.11906.89.camel@localhost.localdomain> References: <1186523683.11906.89.camel@localhost.localdomain> Message-ID: <46BAF815.5080200@kanarip.com> Jeremy Katz wrote: > Okay, I've finally gotten the git commit mail script to work with the > weird git setup on git.fedoraproject.org. Any objections to send the > commit mails to the list? > No, I'll filter them out from being forwarded to my cellphone if it's proving to be too much ;-) Can that script be shared amongst the other GIT repos at git.fp.org? I'd certainly be interested to use it with Revisor also. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Thu Aug 9 13:48:42 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 09 Aug 2007 09:48:42 -0400 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <46BAF815.5080200@kanarip.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> Message-ID: <1186667323.26986.1.camel@erebor.boston.redhat.com> On Thu, 2007-08-09 at 13:18 +0200, Jeroen van Meeuwen wrote: > Jeremy Katz wrote: > > Okay, I've finally gotten the git commit mail script to work with the > > weird git setup on git.fedoraproject.org. Any objections to send the > > commit mails to the list? > > No, I'll filter them out from being forwarded to my cellphone if it's > proving to be too much ;-) Heh :-) > Can that script be shared amongst the other GIT repos at git.fp.org? I'd > certainly be interested to use it with Revisor also. That's the plan -- I've been basically trying to test it out and make sure it's available to the other git projects that want it. Jeremy From rellonaut at gmail.com Thu Aug 9 13:52:06 2007 From: rellonaut at gmail.com (Durell Wilson) Date: Thu, 9 Aug 2007 13:52:06 +0000 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <1186667323.26986.1.camel@erebor.boston.redhat.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> <1186667323.26986.1.camel@erebor.boston.redhat.com> Message-ID: <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> Can I not receive these emails. I stopped using Fedora 7 a while ago. I am now a proud eLive Gem user. Enlightenment 17! Best ever! But I did enjoy Fedora while it lasted. You see, I am trying to get the most out of every good distro. I want to live it all. So I wish to get off the mailing list. Is there like a link or something to remove me? On 8/9/07, Jeremy Katz wrote: > > On Thu, 2007-08-09 at 13:18 +0200, Jeroen van Meeuwen wrote: > > Jeremy Katz wrote: > > > Okay, I've finally gotten the git commit mail script to work with the > > > weird git setup on git.fedoraproject.org. Any objections to send the > > > commit mails to the list? > > > > No, I'll filter them out from being forwarded to my cellphone if it's > > proving to be too much ;-) > > Heh :-) > > > Can that script be shared amongst the other GIT repos at git.fp.org? I'd > > certainly be interested to use it with Revisor also. > > That's the plan -- I've been basically trying to test it out and make > sure it's available to the other git projects that want it. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- Astronaut, Cosmonaut, Rellonaut... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rellonaut at gmail.com Thu Aug 9 13:53:02 2007 From: rellonaut at gmail.com (Durell Wilson) Date: Thu, 9 Aug 2007 13:53:02 +0000 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> <1186667323.26986.1.camel@erebor.boston.redhat.com> <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> Message-ID: <6cbe6ddf0708090653t413b4e95o6a1e1eb959ab8625@mail.gmail.com> Don't worry, I'll be back when Fedora 8 is released, he he. ^_^ On 8/9/07, Durell Wilson wrote: > > Can I not receive these emails. I stopped using Fedora 7 a while ago. I am > now a proud eLive Gem user. Enlightenment 17! Best ever! But I did enjoy > Fedora while it lasted. You see, I am trying to get the most out of every > good distro. I want to live it all. So I wish to get off the mailing list. > Is there like a link or something to remove me? > > On 8/9/07, Jeremy Katz wrote: > > > > On Thu, 2007-08-09 at 13:18 +0200, Jeroen van Meeuwen wrote: > > > Jeremy Katz wrote: > > > > Okay, I've finally gotten the git commit mail script to work with > > the > > > > weird git setup on git.fedoraproject.org. Any objections to send > > the > > > > commit mails to the list? > > > > > > No, I'll filter them out from being forwarded to my cellphone if it's > > > proving to be too much ;-) > > > > Heh :-) > > > > > Can that script be shared amongst the other GIT repos at git.fp.org? > > I'd > > > certainly be interested to use it with Revisor also. > > > > That's the plan -- I've been basically trying to test it out and make > > sure it's available to the other git projects that want it. > > > > Jeremy > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > > > -- > Astronaut, Cosmonaut, Rellonaut... -- Astronaut, Cosmonaut, Rellonaut... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at fedoraproject.org Thu Aug 9 13:58:21 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 09 Aug 2007 19:28:21 +0530 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> <1186667323.26986.1.camel@erebor.boston.redhat.com> <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> Message-ID: <46BB1D7D.3010303@fedoraproject.org> Durell Wilson wrote: > Can I not receive these emails. I stopped using Fedora 7 a while ago. I > am now a proud eLive Gem user. Enlightenment 17! Best ever! But I did > enjoy Fedora while it lasted. You see, I am trying to get the most out > of every good distro. I want to live it all. So I wish to get off the > mailing list. Is there like a link or something to remove me? > It's part of every mail's footer in this list. https://www.redhat.com/mailman/listinfo/fedora-livecd-list Rahul From vladimir.shebordaev at gmail.com Thu Aug 9 15:25:10 2007 From: vladimir.shebordaev at gmail.com (Vladimir Shebordaev) Date: Thu, 09 Aug 2007 19:25:10 +0400 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> <1186667323.26986.1.camel@erebor.boston.redhat.com> <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> Message-ID: <46BB31D6.6050005@gmail.com> Durell (Or Wilson?), sure, please please us with the click on this In the hope it helps. Regards, Vladimir Durell Wilson ?????: > Can I not receive these emails. I stopped using Fedora 7 a while ago. I > am now a proud eLive Gem user. Enlightenment 17! Best ever! But I did > enjoy Fedora while it lasted. You see, I am trying to get the most out > of every good distro. I want to live it all. So I wish to get off the > mailing list. Is there like a link or something to remove me? > > On 8/9/07, *Jeremy Katz* > wrote: > > On Thu, 2007-08-09 at 13:18 +0200, Jeroen van Meeuwen wrote: > > Jeremy Katz wrote: > > > Okay, I've finally gotten the git commit mail script to work > with the > > > weird git setup on git.fedoraproject.org > . Any objections to send the > > > commit mails to the list? > > > > No, I'll filter them out from being forwarded to my cellphone if it's > > proving to be too much ;-) > > Heh :-) > > > Can that script be shared amongst the other GIT repos at > git.fp.org ? I'd > > certainly be interested to use it with Revisor also. > > That's the plan -- I've been basically trying to test it out and make > sure it's available to the other git projects that want it. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > > -- > Astronaut, Cosmonaut, Rellonaut... > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From rellonaut at gmail.com Thu Aug 9 16:59:46 2007 From: rellonaut at gmail.com (Durell Wilson) Date: Thu, 9 Aug 2007 12:59:46 -0400 Subject: [Fedora-livecd-list] Commits to the list? In-Reply-To: <46BB31D6.6050005@gmail.com> References: <1186523683.11906.89.camel@localhost.localdomain> <46BAF815.5080200@kanarip.com> <1186667323.26986.1.camel@erebor.boston.redhat.com> <6cbe6ddf0708090652q6184146dga70a8fa1d41a3c29@mail.gmail.com> <46BB31D6.6050005@gmail.com> Message-ID: <6cbe6ddf0708090959w742ede0ibf227a59e74b2a16@mail.gmail.com> Thank you. I hope to return soon. Perhaps when Fedora 8 is released I get back on Fedora. Again, I did I like Fedora, however I am in the process of trying as many distros as I can. Thanks. On 8/9/07, Vladimir Shebordaev wrote: > > Durell (Or Wilson?), sure, > > please please us with the click on this > > < > https://www.redhat.com/mailman/options/fedora-livecd-list?email=rellonaut at gmail.com > > > > In the hope it helps. > > Regards, > Vladimir > > Durell Wilson ?????: > > Can I not receive these emails. I stopped using Fedora 7 a while ago. I > > am now a proud eLive Gem user. Enlightenment 17! Best ever! But I did > > enjoy Fedora while it lasted. You see, I am trying to get the most out > > of every good distro. I want to live it all. So I wish to get off the > > mailing list. Is there like a link or something to remove me? > > > > On 8/9/07, *Jeremy Katz* > > wrote: > > > > On Thu, 2007-08-09 at 13:18 +0200, Jeroen van Meeuwen wrote: > > > Jeremy Katz wrote: > > > > Okay, I've finally gotten the git commit mail script to work > > with the > > > > weird git setup on git.fedoraproject.org > > . Any objections to send the > > > > commit mails to the list? > > > > > > No, I'll filter them out from being forwarded to my cellphone if > it's > > > proving to be too much ;-) > > > > Heh :-) > > > > > Can that script be shared amongst the other GIT repos at > > git.fp.org ? I'd > > > certainly be interested to use it with Revisor also. > > > > That's the plan -- I've been basically trying to test it out and > make > > sure it's available to the other git projects that want it. > > > > Jeremy > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > > > > > > > -- > > Astronaut, Cosmonaut, Rellonaut... > > > > > > ------------------------------------------------------------------------ > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- Astronaut, Cosmonaut, Rellonaut... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.bjorndal at broadpark.no Sun Aug 12 15:55:28 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sun, 12 Aug 2007 17:55:28 +0200 Subject: [Fedora-livecd-list] error: Couldn't fork %post: Cannot allocate memory Message-ID: Hello! A lot of that message appeared after trying to make a livecd with the latest GIT version of livecd-creator. What could I do to get rid of them? Lars From dmc.fedora at filteredperception.org Mon Aug 13 04:13:44 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 12 Aug 2007 23:13:44 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements Message-ID: <46BFDA78.1000900@filteredperception.org> I have a few changes I'd like to request to mayflower. I'd like to get some feedback before actually laying down the effort of producing patches. #1 - mayflower.conf - add PROGRAMS and FILES I'd like it if mayflower, in addition to supporting MODULES+= lines, would also support PROGRAMS+= and FILES+= PROGRAMS+= would be used for example, in my prior persistence patch, to add things like ntfsmount. FILES+= would differ from PROGRAMS, in that the auto shared library dependency check would not apply to them. Maybe that doesn't matter, and you could just have FILES. #2 - support user specified mayflower.conf location (i.e. not just /etc/mayflower.conf) #3 - optional program, sort of like existing shell cmdline arg Have a cmdline argument of program= and eprogram= which would cause the specified program to be executed. program= would happen right after the current shell, and eprogram would happen right after the current eshell. You would of course supply your own custom program via #1 above. Now, you are no doubt asking, what would this be used for... Answers: 1) support SELinux enabled livecd creation from an SELinux disabled build system. 2) support building of anaconda rpm as a non root user 3) support livecd-creator as a non root user Now you are no doubt asking, how do #1 #2 & #3 get you 1) 2) and 3)? The answer is by implementing the qmkfs program I alluded to a long time ago on fedora-devel, and it's more general incarnation, qrr (qemu root run) The idea is this- qrr is a script. qrr reads it's input, a config file, describing a program and some data. qrr then invokes mayflower (as a user, not root, with #2) to generate an initramfs, that is basically the same as the livecd initramfs, but with extra programs, specified by the config file, and added with #1. Then, qemu is invoked with #3, somewhat like this- mkdir ./my_input_output_dir cp -av ./my_input_output_dir qemu-img create scratch.img 10G qemu -kernel /boot/vmlinuz-$(uname -r) \ -initrd ./my_mayflower_generated_initrd.img \ -append "program=/my_custom_qrr_program" \ -hda ./scratch.img \ -hdb fat:rw:./my_input_output_dir Thus, the mayflower initramfs boots, runs the user supplied my_custom_qrr_program, which mounts the my_input_output_dir, and proceeds to process it with root privs (i.e. it can do loopback mounts, selinux relabeling, etc...), and then leaves its output (e.g. a filesystem image) in my_input_output_dir. I think that the changes involved with #1 #2 and #3 are fairly minor, elegant, and safe. Actually implementing 1) and 2) are a bit tricky. 3) is probably a lot tricky, but arguably worth the effort. Mainly I want this feature (qrr) for my own currently private project, though I would definitely go ahead and implement 1) as part of the patchset to be submitted for merging, which I think is justification enough for #1 #2 and #3. In general, the ability to use mayflower to construct arbitrarily useful custom purpose initramfs-s, seems quite useful. I imagine that when people really start to think about this, and what it allows, they will come up with many uses that I would probably never imagine. Personally I am hoping for a koji/pungi/livecd-creator/revisor that does not require root privileges at all. It seems to me like there should be no reason why a non-root user cannot take the fedora cvs/git trees, and output (customized) F9 media sets. I realize this may sound like a lot of stuff, but please focus on how small and safe the patches to support #1 #2 and #3 really are. Also, I have basically done this somewhat manually. (tweaked mayflower, generated initramfs as user, booted qemu to get arbitrary program to run) questions/comments/criticisms? -dmc From dmc.fedora at filteredperception.org Mon Aug 13 04:28:13 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sun, 12 Aug 2007 23:28:13 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFDA78.1000900@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> Message-ID: <46BFDDDD.3000203@filteredperception.org> Douglas McClendon wrote: > I have a few changes I'd like to request to mayflower. I'd like to get > some feedback before actually laying down the effort of producing patches. ... > #3 - optional program, sort of like existing shell cmdline arg > > Have a cmdline argument of program= and eprogram= which would cause the > specified program to be executed. program= would happen right after the > current shell, and eprogram would happen right after the current eshell. Also, #3 would be invoked by an optional argument to mayflower, e.g. --program (as always, feel free to suggest better names for things) Likewise, in the scenario of my persistence patch, presumably an enable/disable flag (or configfile option somehow) would be passed to livecd-creator. Then, if appropriate, the persistence stuff (findoverlay script, vfat module, ntfsmount and fuse module maybe) would be added to the resultant livecd initramfs via the mayflower.conf. -dmc From tim.wood at datawranglers.com Mon Aug 13 05:24:13 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Sun, 12 Aug 2007 23:24:13 -0600 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFDA78.1000900@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> Message-ID: <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> The one comment I'd have is would it be possible to feed some (or all) of these options in as a config file? Then (I believe) someone could have a kickstart and a config file to handle everything. Then Revisor would need one additional field to select the path to this config file. A couple of advantages: * A sample kickstart and a sample config with lots of comments and all the options plus a basic tutorial would be all the documentation many people would need * It would make it much simpler to return to a project months later and tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. files there, notes somewhere else and maybe some custom bash code somewhere else) Tim Wood On Aug 12, 2007, at 10:13 PM, Douglas McClendon wrote: > I have a few changes I'd like to request to mayflower. I'd like to > get some feedback before actually laying down the effort of > producing patches. > > #1 - mayflower.conf - add PROGRAMS and FILES > > I'd like it if mayflower, in addition to supporting MODULES+= > lines, would also support PROGRAMS+= and FILES+= > > PROGRAMS+= would be used for example, in my prior persistence > patch, to add things like ntfsmount. > > FILES+= would differ from PROGRAMS, in that the auto shared library > dependency check would not apply to them. Maybe that doesn't > matter, and you could just have FILES. > > #2 - support user specified mayflower.conf location > (i.e. not just /etc/mayflower.conf) > > #3 - optional program, sort of like existing shell cmdline arg > > Have a cmdline argument of program= and eprogram= which would cause > the specified program to be executed. program= would happen right > after the current shell, and eprogram would happen right after the > current eshell. > > You would of course supply your own custom program via #1 above. > > Now, you are no doubt asking, what would this be used for... > > Answers: > > 1) support SELinux enabled livecd creation from an SELinux disabled > build system. > > 2) support building of anaconda rpm as a non root user > > 3) support livecd-creator as a non root user > > Now you are no doubt asking, how do #1 #2 & #3 get you 1) 2) and 3)? > > The answer is by implementing the qmkfs program I alluded to a long > time ago on fedora-devel, and it's more general incarnation, qrr > (qemu root run) > > The idea is this- qrr is a script. qrr reads it's input, a config > file, describing a program and some data. qrr then invokes > mayflower (as a user, not root, with #2) to generate an initramfs, > that is basically the same as the livecd initramfs, but with extra > programs, specified by the config file, and added with #1. Then, > qemu is invoked with #3, somewhat like this- > > mkdir ./my_input_output_dir > cp -av ./my_input_output_dir > qemu-img create scratch.img 10G > qemu -kernel /boot/vmlinuz-$(uname -r) \ > -initrd ./my_mayflower_generated_initrd.img \ > -append "program=/my_custom_qrr_program" \ > -hda ./scratch.img \ > -hdb fat:rw:./my_input_output_dir > > Thus, the mayflower initramfs boots, runs the user supplied > my_custom_qrr_program, which mounts the my_input_output_dir, and > proceeds to process it with root privs (i.e. it can do loopback > mounts, selinux relabeling, etc...), and then leaves its output > (e.g. a filesystem image) in my_input_output_dir. > > I think that the changes involved with #1 #2 and #3 are fairly > minor, elegant, and safe. Actually implementing 1) and 2) are a > bit tricky. 3) is probably a lot tricky, but arguably worth the > effort. > > Mainly I want this feature (qrr) for my own currently private > project, though I would definitely go ahead and implement 1) as > part of the patchset to be submitted for merging, which I think is > justification enough for #1 #2 and #3. > > In general, the ability to use mayflower to construct arbitrarily > useful custom purpose initramfs-s, seems quite useful. I imagine > that when people really start to think about this, and what it > allows, they will come up with many uses that I would probably > never imagine. > > Personally I am hoping for a koji/pungi/livecd-creator/revisor that > does not require root privileges at all. It seems to me like there > should be no reason why a non-root user cannot take the fedora cvs/ > git trees, and output (customized) F9 media sets. > > I realize this may sound like a lot of stuff, but please focus on > how small and safe the patches to support #1 #2 and #3 really are. > > Also, I have basically done this somewhat manually. (tweaked > mayflower, generated initramfs as user, booted qemu to get > arbitrary program to run) > > questions/comments/criticisms? > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From tim.wood at datawranglers.com Mon Aug 13 05:25:57 2007 From: tim.wood at datawranglers.com (Tim Wood) Date: Sun, 12 Aug 2007 23:25:57 -0600 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFDA78.1000900@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> Message-ID: follow up since I've no urge to look like a newb in the bat-it-over the fence group on this list... what is Mayflower? Link to let me RTFM is fine o'course... Tim On Aug 12, 2007, at 10:13 PM, Douglas McClendon wrote: > I have a few changes I'd like to request to mayflower. I'd like to > get some feedback before actually laying down the effort of > producing patches. > > #1 - mayflower.conf - add PROGRAMS and FILES > > I'd like it if mayflower, in addition to supporting MODULES+= > lines, would also support PROGRAMS+= and FILES+= > > PROGRAMS+= would be used for example, in my prior persistence > patch, to add things like ntfsmount. > > FILES+= would differ from PROGRAMS, in that the auto shared library > dependency check would not apply to them. Maybe that doesn't > matter, and you could just have FILES. > > #2 - support user specified mayflower.conf location > (i.e. not just /etc/mayflower.conf) > > #3 - optional program, sort of like existing shell cmdline arg > > Have a cmdline argument of program= and eprogram= which would cause > the specified program to be executed. program= would happen right > after the current shell, and eprogram would happen right after the > current eshell. > > You would of course supply your own custom program via #1 above. > > Now, you are no doubt asking, what would this be used for... > > Answers: > > 1) support SELinux enabled livecd creation from an SELinux disabled > build system. > > 2) support building of anaconda rpm as a non root user > > 3) support livecd-creator as a non root user > > Now you are no doubt asking, how do #1 #2 & #3 get you 1) 2) and 3)? > > The answer is by implementing the qmkfs program I alluded to a long > time ago on fedora-devel, and it's more general incarnation, qrr > (qemu root run) > > The idea is this- qrr is a script. qrr reads it's input, a config > file, describing a program and some data. qrr then invokes > mayflower (as a user, not root, with #2) to generate an initramfs, > that is basically the same as the livecd initramfs, but with extra > programs, specified by the config file, and added with #1. Then, > qemu is invoked with #3, somewhat like this- > > mkdir ./my_input_output_dir > cp -av ./my_input_output_dir > qemu-img create scratch.img 10G > qemu -kernel /boot/vmlinuz-$(uname -r) \ > -initrd ./my_mayflower_generated_initrd.img \ > -append "program=/my_custom_qrr_program" \ > -hda ./scratch.img \ > -hdb fat:rw:./my_input_output_dir > > Thus, the mayflower initramfs boots, runs the user supplied > my_custom_qrr_program, which mounts the my_input_output_dir, and > proceeds to process it with root privs (i.e. it can do loopback > mounts, selinux relabeling, etc...), and then leaves its output > (e.g. a filesystem image) in my_input_output_dir. > > I think that the changes involved with #1 #2 and #3 are fairly > minor, elegant, and safe. Actually implementing 1) and 2) are a > bit tricky. 3) is probably a lot tricky, but arguably worth the > effort. > > Mainly I want this feature (qrr) for my own currently private > project, though I would definitely go ahead and implement 1) as > part of the patchset to be submitted for merging, which I think is > justification enough for #1 #2 and #3. > > In general, the ability to use mayflower to construct arbitrarily > useful custom purpose initramfs-s, seems quite useful. I imagine > that when people really start to think about this, and what it > allows, they will come up with many uses that I would probably > never imagine. > > Personally I am hoping for a koji/pungi/livecd-creator/revisor that > does not require root privileges at all. It seems to me like there > should be no reason why a non-root user cannot take the fedora cvs/ > git trees, and output (customized) F9 media sets. > > I realize this may sound like a lot of stuff, but please focus on > how small and safe the patches to support #1 #2 and #3 really are. > > Also, I have basically done this somewhat manually. (tweaked > mayflower, generated initramfs as user, booted qemu to get > arbitrary program to run) > > questions/comments/criticisms? > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From dmc.fedora at filteredperception.org Mon Aug 13 06:06:18 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 01:06:18 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: References: <46BFDA78.1000900@filteredperception.org> Message-ID: <46BFF4DA.6000505@filteredperception.org> Tim Wood wrote: > follow up since I've no urge to look like a newb in the bat-it-over the > fence group on this list... what is Mayflower? Link to let me RTFM is > fine o'course... > > Tim mayflower is functionally akin to mkinitrd, except that it makes initramfss suitable for booting livecds, as opposed to booting normal systems. It is located in the livecd-tools rpm, and lives in /usr/lib/livecd-tools/mayflower. During livecd-creator, it gets copied to the system being built, run in a chroot to create the initramfs, which is then put in the livecds isolinux directory and used to boot it. Query- Does anybody else think its time to create some sort of mailinglist distinction between a) livecd users b) livecd-tools/revisor users c) livecd-tools/revisor developers -dmc From dmc.fedora at filteredperception.org Mon Aug 13 06:07:27 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 01:07:27 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> Message-ID: <46BFF51F.9040806@filteredperception.org> Tim Wood wrote: > The one comment I'd have is would it be possible to feed some (or all) > of these options in as a config file? Most of my RFC was basically about extending the functionality of the mayflower.conf config file. But currently, as far as livecd-creator (and presumably revisor) is concerned, a mayflower.conf is hard-coded. The question is whether or not there is any reason to expose the livecd-creator or revisor user to these sorts of options. For the selinux enabled on an selinux disabled system, I think this should all happen inside livecd creator, and cause things to 'just work' (versus now, where it detects the situation, and says 'too bad, you can't do this'). For the anaconda rpm build as non-root user, this really has nothing to do with livecd-creator or revisor. And for the vastly trickier idea of livecd-creator as non-root, again, there is no aspect that the livecd-creator or revisor user should care about, other than having it just work. Then (I believe) someone could > have a kickstart and a config file to handle everything. Then Revisor > would need one additional field to select the path to this config > file. A couple of advantages: > * A sample kickstart and a sample config with lots of comments and all > the options plus a basic tutorial would be all the documentation many > people would need > * It would make it much simpler to return to a project months later and > tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. files > there, notes somewhere else and maybe some custom bash code somewhere else) What you are getting at here, is really the crux of the debate I had with jeremy over the addsdir/addidir patch, and the ideal of reproducability from a _single_ config file. The basic problem, which I think you solved with your outline above, is that kickstart is simply not appropriate to be the one _single_ config file for a livecd project. The two examples that immediately spring to mind are 1) files added to the iso filesystem. E.g. like ubuntu's inclusion of the windows firefox installer. Or a generic web page to be viewed under windows when the livecd is inserted in a windows system. 2) the persistence feature. OTOH, here is how I guess I could imagine cramming everything into the kickstart- 1) have some truly magic livecd kickstart command to add files to the isodir. This command would be silently ignored in the non-livecd case (or perhaps files copied to /iso or some arbitrary directory in a non-livecd kickstart invocation). 2) and this is rather key- put the mayflower invocation in the %post of the kickstart. Perhaps even enclose it in a conditional, based on some variable that only gets defined in the livecd case. Then perhaps even merge the livecd-creator code back into anaconda, ala the old kadischi anaconda rootpath livecd creation facility. (yes Jeremy, I'm trying to give you nightmares ;) 2 as described (with or without remerge with anaconda) also gives you the ability to customize the initramfs (e.g. add persistence and similar mayflower optional features) in the %post of the kickstart. But I want to emphasize to anyone reading this far, that none of this really has anything to do with the simple modifications and simple functionality enhancements that I was aiming for in the parent RFC. This has been a tangent going down rearchitecting the kickstart/config file and invocation of livecd-creator. And actually, given what I described, I kind of like the uglier and uglier, but single kickstart solution. (the other aspects which I've complained about in the past, I think I can see workarounds for as well) -dmc From asdas at redhat.com Mon Aug 13 06:29:47 2007 From: asdas at redhat.com (ashok shankar das) Date: Mon, 13 Aug 2007 11:59:47 +0530 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFF51F.9040806@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> <46BFF51F.9040806@filteredperception.org> Message-ID: <46BFFA5B.7050003@redhat.com> Douglas McClendon wrote: > Tim Wood wrote: > >> The one comment I'd have is would it be possible to feed some (or >> all) of these options in as a config file? > > > Most of my RFC was basically about extending the functionality of the > mayflower.conf config file. But currently, as far as livecd-creator > (and presumably revisor) is concerned, a mayflower.conf is hard-coded. > > The question is whether or not there is any reason to expose the > livecd-creator or revisor user to these sorts of options. > > For the selinux enabled on an selinux disabled system, I think this > should all happen inside livecd creator, and cause things to 'just > work' (versus now, where it detects the situation, and says 'too bad, > you can't do this'). > > For the anaconda rpm build as non-root user, this really has nothing > to do with livecd-creator or revisor. > > And for the vastly trickier idea of livecd-creator as non-root, again, > there is no aspect that the livecd-creator or revisor user should care > about, other than having it just work. > > > Then (I believe) someone could > >> have a kickstart and a config file to handle everything. Then >> Revisor would need one additional field to select the path to this >> config file. A couple of advantages: >> * A sample kickstart and a sample config with lots of comments and >> all the options plus a basic tutorial would be all the documentation >> many people would need >> * It would make it much simpler to return to a project months later >> and tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. >> files there, notes somewhere else and maybe some custom bash code >> somewhere else) > > > > What you are getting at here, is really the crux of the debate I had > with jeremy over the addsdir/addidir patch, and the ideal of > reproducability from a _single_ config file. > > The basic problem, which I think you solved with your outline above, > is that kickstart is simply not appropriate to be the one _single_ > config file for a livecd project. The two examples that immediately > spring to mind are I agree, Kickstart should not be the_ only_ file for configuration. > > 1) files added to the iso filesystem. E.g. like ubuntu's inclusion of > the windows firefox installer. Or a generic web page to be viewed > under windows when the livecd is inserted in a windows system. Why only LiveCD, think beyond the liveCD. Eg. Small systems can be fit on to a USBstick, Rescue systems, small network servers, small streamers etc... > > 2) the persistence feature. It is a must have feature. But again this should be configurable. Currently Which I developed is doing a persistence at the time of instalation(again a bit hard coded). > > OTOH, here is how I guess I could imagine cramming everything into the > kickstart- > > 1) have some truly magic livecd kickstart command to add files to the > isodir. This command would be silently ignored in the non-livecd case > (or perhaps files copied to /iso or some arbitrary directory in a > non-livecd kickstart invocation). > > 2) and this is rather key- put the mayflower invocation in the %post > of the kickstart. Perhaps even enclose it in a conditional, based on > some variable that only gets defined in the livecd case. Then perhaps > even merge the livecd-creator code back into anaconda, ala the old > kadischi anaconda rootpath livecd creation facility. (yes Jeremy, I'm > trying to give you nightmares ;) > > 2 as described (with or without remerge with anaconda) also gives you > the ability to customize the initramfs (e.g. add persistence and > similar mayflower optional features) in the %post of the kickstart. > > But I want to emphasize to anyone reading this far, that none of this > really has anything to do with the simple modifications and simple > functionality enhancements that I was aiming for in the parent RFC. > This has been a tangent going down rearchitecting the kickstart/config > file and invocation of livecd-creator. > > And actually, given what I described, I kind of like the uglier and > uglier, but single kickstart solution. (the other aspects which I've > complained about in the past, I think I can see workarounds for as well) > > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From dmc.fedora at filteredperception.org Mon Aug 13 07:08:48 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 02:08:48 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFFA5B.7050003@redhat.com> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> <46BFF51F.9040806@filteredperception.org> <46BFFA5B.7050003@redhat.com> Message-ID: <46C00380.4050808@filteredperception.org> ashok shankar das wrote: > Douglas McClendon wrote: > >> Tim Wood wrote: >> >>> The one comment I'd have is would it be possible to feed some (or >>> all) of these options in as a config file? >> >> >> Most of my RFC was basically about extending the functionality of the >> mayflower.conf config file. But currently, as far as livecd-creator >> (and presumably revisor) is concerned, a mayflower.conf is hard-coded. >> >> The question is whether or not there is any reason to expose the >> livecd-creator or revisor user to these sorts of options. >> >> For the selinux enabled on an selinux disabled system, I think this >> should all happen inside livecd creator, and cause things to 'just >> work' (versus now, where it detects the situation, and says 'too bad, >> you can't do this'). >> >> For the anaconda rpm build as non-root user, this really has nothing >> to do with livecd-creator or revisor. >> >> And for the vastly trickier idea of livecd-creator as non-root, again, >> there is no aspect that the livecd-creator or revisor user should care >> about, other than having it just work. >> >> >> Then (I believe) someone could >> >>> have a kickstart and a config file to handle everything. Then >>> Revisor would need one additional field to select the path to this >>> config file. A couple of advantages: >>> * A sample kickstart and a sample config with lots of comments and >>> all the options plus a basic tutorial would be all the documentation >>> many people would need >>> * It would make it much simpler to return to a project months later >>> and tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. >>> files there, notes somewhere else and maybe some custom bash code >>> somewhere else) >> >> >> >> What you are getting at here, is really the crux of the debate I had >> with jeremy over the addsdir/addidir patch, and the ideal of >> reproducability from a _single_ config file. >> >> The basic problem, which I think you solved with your outline above, >> is that kickstart is simply not appropriate to be the one _single_ >> config file for a livecd project. The two examples that immediately >> spring to mind are > > I agree, Kickstart should not be the_ only_ file for configuration. Actually I sort of argued both sides of that coin. And I ended up changing my mind. What sorts of option and configuration do you think should not be in kickstart, but somewhere else? > >> >> 1) files added to the iso filesystem. E.g. like ubuntu's inclusion of >> the windows firefox installer. Or a generic web page to be viewed >> under windows when the livecd is inserted in a windows system. > > > Why only LiveCD, think beyond the liveCD. Eg. Small systems can be fit > on to a USBstick, Rescue systems, small network servers, small streamers > etc... usbstick (especially with livecd-iso-to-disk) is really just an alternate form of livecd. But yes, the changes I proposed to mayflower can also be used to generate initramfss that are useful as rescue systems, and perhaps even as entire-system-in-initramfs for small servers/routers. I never suggested it was useful for livecd only. >> >> 2) the persistence feature. > > It is a must have feature. But again this should be configurable. > Currently Which I developed is doing a persistence at the time of > instalation(again a bit hard coded). I'm still curious where this implementation you speak of that you claim was posted to this list is. Please repost or give a link to an archive post. I'm curious whether your implementation has design aspects that are better than the implementation I posted a couple weeks ago, and discussed at length on this list in the couple weeks before that. (as I've told Tim offlist, I'll be posting an updated version of that implementation within the next couple of days. I'm just honing my git skills at the moment) -dmc > >> >> OTOH, here is how I guess I could imagine cramming everything into the >> kickstart- >> >> 1) have some truly magic livecd kickstart command to add files to the >> isodir. This command would be silently ignored in the non-livecd case >> (or perhaps files copied to /iso or some arbitrary directory in a >> non-livecd kickstart invocation). >> >> 2) and this is rather key- put the mayflower invocation in the %post >> of the kickstart. Perhaps even enclose it in a conditional, based on >> some variable that only gets defined in the livecd case. Then perhaps >> even merge the livecd-creator code back into anaconda, ala the old >> kadischi anaconda rootpath livecd creation facility. (yes Jeremy, I'm >> trying to give you nightmares ;) >> >> 2 as described (with or without remerge with anaconda) also gives you >> the ability to customize the initramfs (e.g. add persistence and >> similar mayflower optional features) in the %post of the kickstart. >> >> But I want to emphasize to anyone reading this far, that none of this >> really has anything to do with the simple modifications and simple >> functionality enhancements that I was aiming for in the parent RFC. >> This has been a tangent going down rearchitecting the kickstart/config >> file and invocation of livecd-creator. >> >> And actually, given what I described, I kind of like the uglier and >> uglier, but single kickstart solution. (the other aspects which I've >> complained about in the past, I think I can see workarounds for as well) >> >> >> -dmc >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > From asdas at redhat.com Mon Aug 13 09:33:17 2007 From: asdas at redhat.com (ashok shankar das) Date: Mon, 13 Aug 2007 15:03:17 +0530 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46C00380.4050808@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> <46BFF51F.9040806@filteredperception.org> <46BFFA5B.7050003@redhat.com> <46C00380.4050808@filteredperception.org> Message-ID: <46C0255D.4010906@redhat.com> Douglas McClendon wrote: > ashok shankar das wrote: > >> Douglas McClendon wrote: >> >>> Tim Wood wrote: >>> >>>> The one comment I'd have is would it be possible to feed some (or >>>> all) of these options in as a config file? >>> >>> >>> >>> Most of my RFC was basically about extending the functionality of >>> the mayflower.conf config file. But currently, as far as >>> livecd-creator (and presumably revisor) is concerned, a >>> mayflower.conf is hard-coded. >>> >>> The question is whether or not there is any reason to expose the >>> livecd-creator or revisor user to these sorts of options. >>> >>> For the selinux enabled on an selinux disabled system, I think this >>> should all happen inside livecd creator, and cause things to 'just >>> work' (versus now, where it detects the situation, and says 'too >>> bad, you can't do this'). >>> >>> For the anaconda rpm build as non-root user, this really has nothing >>> to do with livecd-creator or revisor. >>> >>> And for the vastly trickier idea of livecd-creator as non-root, >>> again, there is no aspect that the livecd-creator or revisor user >>> should care about, other than having it just work. >>> >>> >>> Then (I believe) someone could >>> >>>> have a kickstart and a config file to handle everything. Then >>>> Revisor would need one additional field to select the path to this >>>> config file. A couple of advantages: >>>> * A sample kickstart and a sample config with lots of comments and >>>> all the options plus a basic tutorial would be all the >>>> documentation many people would need >>>> * It would make it much simpler to return to a project months later >>>> and tweak/tune/use it (find 2 files you left in /etc/revisor/... >>>> vs. files there, notes somewhere else and maybe some custom bash >>>> code somewhere else) >>> >>> >>> >>> >>> What you are getting at here, is really the crux of the debate I had >>> with jeremy over the addsdir/addidir patch, and the ideal of >>> reproducability from a _single_ config file. >>> >>> The basic problem, which I think you solved with your outline above, >>> is that kickstart is simply not appropriate to be the one _single_ >>> config file for a livecd project. The two examples that immediately >>> spring to mind are >> >> >> I agree, Kickstart should not be the_ only_ file for configuration. > > > Actually I sort of argued both sides of that coin. And I ended up > changing my mind. What sorts of option and configuration do you think > should not be in kickstart, but somewhere else? > >> >>> >>> 1) files added to the iso filesystem. E.g. like ubuntu's inclusion >>> of the windows firefox installer. Or a generic web page to be >>> viewed under windows when the livecd is inserted in a windows system. >> >> >> >> Why only LiveCD, think beyond the liveCD. Eg. Small systems can be >> fit on to a USBstick, Rescue systems, small network servers, small >> streamers etc... > > > usbstick (especially with livecd-iso-to-disk) is really just an > alternate form of livecd. > > But yes, the changes I proposed to mayflower can also be used to > generate initramfss that are useful as rescue systems, and perhaps > even as entire-system-in-initramfs for small servers/routers. I never > suggested it was useful for livecd only. > > > >>> >>> 2) the persistence feature. >> >> >> It is a must have feature. But again this should be configurable. >> Currently Which I developed is doing a persistence at the time of >> instalation(again a bit hard coded). > > > I'm still curious where this implementation you speak of that you > claim was posted to this list is. Please repost or give a link to an > archive post. I have a very vague vison fo what to be separated. I think the target specific things should be on a separate file. from which the KS file can read and work acordingly. As an example the drivers which goes into the initrd are hard coded. Suppose i got a weired hardware which needs some special drivers then i am helpless in current scenario. why should be there a ISO-to-USB script? This sort of configuration should go into separate config file too. Try using KS file only for the package instalation and post configuration of the installed system. Try to Implement a Config based image creation and target setup. I can say this much at this time. > > I'm curious whether your implementation has design aspects that are > better than the implementation I posted a couple weeks ago, and > discussed at length on this list in the couple weeks before that. > > (as I've told Tim offlist, I'll be posting an updated version of that > implementation within the next couple of days. I'm just honing my git > skills at the moment) > > -dmc > >> >>> >>> OTOH, here is how I guess I could imagine cramming everything into >>> the kickstart- >>> >>> 1) have some truly magic livecd kickstart command to add files to >>> the isodir. This command would be silently ignored in the >>> non-livecd case (or perhaps files copied to /iso or some arbitrary >>> directory in a non-livecd kickstart invocation). >>> >>> 2) and this is rather key- put the mayflower invocation in the %post >>> of the kickstart. Perhaps even enclose it in a conditional, based >>> on some variable that only gets defined in the livecd case. Then >>> perhaps even merge the livecd-creator code back into anaconda, ala >>> the old kadischi anaconda rootpath livecd creation facility. (yes >>> Jeremy, I'm trying to give you nightmares ;) >>> >>> 2 as described (with or without remerge with anaconda) also gives >>> you the ability to customize the initramfs (e.g. add persistence and >>> similar mayflower optional features) in the %post of the kickstart. >>> >>> But I want to emphasize to anyone reading this far, that none of >>> this really has anything to do with the simple modifications and >>> simple functionality enhancements that I was aiming for in the >>> parent RFC. This has been a tangent going down rearchitecting the >>> kickstart/config file and invocation of livecd-creator. >>> >>> And actually, given what I described, I kind of like the uglier and >>> uglier, but single kickstart solution. (the other aspects which >>> I've complained about in the past, I think I can see workarounds for >>> as well) >>> >>> >>> -dmc >>> >>> -- >>> Fedora-livecd-list mailing list >>> Fedora-livecd-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list >> >> >> >> > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From katzj at redhat.com Mon Aug 13 13:50:44 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 09:50:44 -0400 Subject: [Fedora-livecd-list] error: Couldn't fork %post: Cannot allocate memory In-Reply-To: References: Message-ID: <1187013044.1471.0.camel@localhost.localdomain> On Sun, 2007-08-12 at 17:55 +0200, Lars Bj?rndal wrote: > A lot of that message appeared after trying to make a livecd with the > latest GIT version of livecd-creator. What could I do to get rid of them? Can't fork usually means that you're out of memory... I've been creating images just fine with current git. Can you provide more details on your config as well as the exact output of the errors? Jeremy From katzj at redhat.com Mon Aug 13 14:04:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 10:04:40 -0400 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFDA78.1000900@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> Message-ID: <1187013880.1471.10.camel@localhost.localdomain> On Sun, 2007-08-12 at 23:13 -0500, Douglas McClendon wrote: > I have a few changes I'd like to request to mayflower. I'd like to get > some feedback before actually laying down the effort of producing patches. So from a big high-level point of view, I'd really rather _not_ add lots more that people depend on from mayflower. Having two different codebases to handle the initramfs (mayflower + mkinitrd) is incredibly painful for having to adapt both for changes in the OS, etc. And given that overall mkinitrd "does more", I think it's going to be better to get the live image specific stuff integrated into mkinitrd rather than spending a lot of time making mayflower more flexible for the sake of flexibility. But to comment on the concepts... > #1 - mayflower.conf - add PROGRAMS and FILES [snip] > FILES+= would differ from PROGRAMS, in that the auto shared library > dependency check would not apply to them. Maybe that doesn't matter, > and you could just have FILES. Having two different lists is just asking for people to pick the wrong one. Since I can't think of a real reason that you'd want a binary without its deps, just lump them together. > #2 - support user specified mayflower.conf location > (i.e. not just /etc/mayflower.conf) Not terribly against or for this. Having the ability to specify config locations is often useful enough for writing test cases that it's worthwhile > #3 - optional program, sort of like existing shell cmdline arg > > Have a cmdline argument of program= and eprogram= which would cause the > specified program to be executed. program= would happen right after the > current shell, and eprogram would happen right after the current eshell. Why not just use init= ? Other than the fact that doing so is currently broken with mayflower (... see above comments about two implementations of the same thing :-) Jeremy From katzj at redhat.com Mon Aug 13 14:12:05 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 10:12:05 -0400 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46BFF51F.9040806@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> <46BFF51F.9040806@filteredperception.org> Message-ID: <1187014325.1471.19.camel@localhost.localdomain> On Mon, 2007-08-13 at 01:07 -0500, Douglas McClendon wrote: > Tim Wood wrote: > Then (I believe) someone could > > have a kickstart and a config file to handle everything. Then Revisor > > would need one additional field to select the path to this config > > file. A couple of advantages: > > * A sample kickstart and a sample config with lots of comments and all > > the options plus a basic tutorial would be all the documentation many > > people would need > > * It would make it much simpler to return to a project months later and > > tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. files > > there, notes somewhere else and maybe some custom bash code somewhere else) > > What you are getting at here, is really the crux of the debate I had > with jeremy over the addsdir/addidir patch, and the ideal of > reproducability from a _single_ config file. > > The basic problem, which I think you solved with your outline above, is > that kickstart is simply not appropriate to be the one _single_ config > file for a livecd project. The two examples that immediately spring to > mind are People are caught up, though, on "you can't add anything to kickstart". Which is a patently false statement. Also, the idea is that we're also moving pungi also over to use the kickstart syntax (+parser). That way, you have _one_ config file that can be used for any of the following: 1) Create a live image 2) Create an installable tree 3) Install from an everything type tree Which starts to be pretty flexible. For some of the things like initial config, etc -- well, we're starting to want to let that be specified when creating an installable tree so that you can create an installable tree with a certain set of default config stuff that anaconda listens to. > 1) files added to the iso filesystem. E.g. like ubuntu's inclusion of > the windows firefox installer. Or a generic web page to be viewed under > windows when the livecd is inserted in a windows system. > > 1A) have some truly magic livecd kickstart command to add files to the > isodir. This command would be silently ignored in the non-livecd case > (or perhaps files copied to /iso or some arbitrary directory in a > non-livecd kickstart invocation). It's definitely going to be okay if there are things that livecd-creator + pungi use when they're doing things that the normal install case ignores. Much like today, livecd-creator ignores a few things that aren't relevant to it. > 2) the persistence feature. > 2A) and this is rather key- put the mayflower invocation in the %post of > the kickstart. Perhaps even enclose it in a conditional, based on some > variable that only gets defined in the livecd case. I'm not sure how persistence really requires anything in the config. There's not any reason why you wouldn't want your live image to be _capable_ of persistence. You may configure it to not enable it by default, but that's a different story (and from our earlier discussion, a boot arg is probably sufficient for this and with the handling of the bootloader argument that I was pointing kanarip to last week, this just falls out, voila! :-) > Then perhaps even > merge the livecd-creator code back into anaconda, ala the old kadischi > anaconda rootpath livecd creation facility. (yes Jeremy, I'm trying to > give you nightmares ;) FWIW, I keep coming back here -- the amount of code that we're basically copying and pasting from anaconda is a little depressing. And especially with markmc's patches to sort of abstract out the "what's being installed to", we get even closer. And by cleaning up anaconda and moving over to using it, we get a UI for "free". I don't know what the long-term answer here is :-/ Jeremy From dmc.fedora at filteredperception.org Mon Aug 13 17:03:51 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 12:03:51 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <1187013880.1471.10.camel@localhost.localdomain> References: <46BFDA78.1000900@filteredperception.org> <1187013880.1471.10.camel@localhost.localdomain> Message-ID: <46C08EF7.30904@filteredperception.org> Jeremy Katz wrote: > On Sun, 2007-08-12 at 23:13 -0500, Douglas McClendon wrote: >> I have a few changes I'd like to request to mayflower. I'd like to get >> some feedback before actually laying down the effort of producing patches. > > So from a big high-level point of view, I'd really rather _not_ add lots > more that people depend on from mayflower. Having two different > codebases to handle the initramfs (mayflower + mkinitrd) is incredibly > painful for having to adapt both for changes in the OS, etc. I agree that it would be cool if mayflower got absorbed into mkinitrd (or vice versa). But that seems a litte far off right now, wheras the changes I presented were all very small, and only served to structure mayflower in a better way, which I imagine would make it's absorbtion into mkinitrd easier, not harder. I.e. #1 - this can be used to replace all that ugly cp /bin/stuff bin/ with an elegant FILES= syntax in the existing mayflower.conf #2 - as you agreed, just makes sense to not hard-code /etc/mayflower.conf #3 - consider how my reply (--program) would be implemented, i.e. by creating scriptlets in variables that get conditionally expanded in the inline init creation. This sort of method of modularizing what gets put in the init (think the OLPC specific parts, and everything else), makes it much more elegant. > > And given that overall mkinitrd "does more", I think it's going to be > better to get the live image specific stuff integrated into mkinitrd > rather than spending a lot of time making mayflower more flexible for > the sake of flexibility. > > But to comment on the concepts... > >> #1 - mayflower.conf - add PROGRAMS and FILES > [snip] >> FILES+= would differ from PROGRAMS, in that the auto shared library >> dependency check would not apply to them. Maybe that doesn't matter, >> and you could just have FILES. > > Having two different lists is just asking for people to pick the wrong > one. Since I can't think of a real reason that you'd want a binary > without its deps, just lump them together. Agreed. >> #2 - support user specified mayflower.conf location >> (i.e. not just /etc/mayflower.conf) > > Not terribly against or for this. Having the ability to specify config > locations is often useful enough for writing test cases that it's > worthwhile > >> #3 - optional program, sort of like existing shell cmdline arg >> >> Have a cmdline argument of program= and eprogram= which would cause the >> specified program to be executed. program= would happen right after the >> current shell, and eprogram would happen right after the current eshell. > > Why not just use init= ? Other than the fact that doing so is currently > broken with mayflower (... see above comments about two implementations > of the same thing :-) The reason is that I very much like all the mayflower generated init stuff that happens up to the point of the existing shell escape. I.e. setting up an environment where bash can run and I can see my devices. By specifying my own init, I'd basically be duplicating the mayflower init generation code, except with my program= escape point, at which point... hey, I'm back where this proposal started. -dmc From dmc.fedora at filteredperception.org Mon Aug 13 17:13:26 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 12:13:26 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46C0255D.4010906@redhat.com> References: <46BFDA78.1000900@filteredperception.org> <5412C01A-0DF1-4848-B9C3-EA3D66B578F8@datawranglers.com> <46BFF51F.9040806@filteredperception.org> <46BFFA5B.7050003@redhat.com> <46C00380.4050808@filteredperception.org> <46C0255D.4010906@redhat.com> Message-ID: <46C09136.4050802@filteredperception.org> ashok shankar das wrote: > Douglas McClendon wrote: > >> ashok shankar das wrote: >> >>> Douglas McClendon wrote: >>> >>>> Tim Wood wrote: >>>> >>>>> The one comment I'd have is would it be possible to feed some (or >>>>> all) of these options in as a config file? >>>> >>>> >>>> >>>> Most of my RFC was basically about extending the functionality of >>>> the mayflower.conf config file. But currently, as far as >>>> livecd-creator (and presumably revisor) is concerned, a >>>> mayflower.conf is hard-coded. >>>> >>>> The question is whether or not there is any reason to expose the >>>> livecd-creator or revisor user to these sorts of options. >>>> >>>> For the selinux enabled on an selinux disabled system, I think this >>>> should all happen inside livecd creator, and cause things to 'just >>>> work' (versus now, where it detects the situation, and says 'too >>>> bad, you can't do this'). >>>> >>>> For the anaconda rpm build as non-root user, this really has nothing >>>> to do with livecd-creator or revisor. >>>> >>>> And for the vastly trickier idea of livecd-creator as non-root, >>>> again, there is no aspect that the livecd-creator or revisor user >>>> should care about, other than having it just work. >>>> >>>> >>>> Then (I believe) someone could >>>> >>>>> have a kickstart and a config file to handle everything. Then >>>>> Revisor would need one additional field to select the path to this >>>>> config file. A couple of advantages: >>>>> * A sample kickstart and a sample config with lots of comments and >>>>> all the options plus a basic tutorial would be all the >>>>> documentation many people would need >>>>> * It would make it much simpler to return to a project months later >>>>> and tweak/tune/use it (find 2 files you left in /etc/revisor/... >>>>> vs. files there, notes somewhere else and maybe some custom bash >>>>> code somewhere else) >>>> >>>> >>>> >>>> >>>> What you are getting at here, is really the crux of the debate I had >>>> with jeremy over the addsdir/addidir patch, and the ideal of >>>> reproducability from a _single_ config file. >>>> >>>> The basic problem, which I think you solved with your outline above, >>>> is that kickstart is simply not appropriate to be the one _single_ >>>> config file for a livecd project. The two examples that immediately >>>> spring to mind are >>> >>> >>> I agree, Kickstart should not be the_ only_ file for configuration. >> >> >> Actually I sort of argued both sides of that coin. And I ended up >> changing my mind. What sorts of option and configuration do you think >> should not be in kickstart, but somewhere else? >> >>> >>>> >>>> 1) files added to the iso filesystem. E.g. like ubuntu's inclusion >>>> of the windows firefox installer. Or a generic web page to be >>>> viewed under windows when the livecd is inserted in a windows system. >>> >>> >>> >>> Why only LiveCD, think beyond the liveCD. Eg. Small systems can be >>> fit on to a USBstick, Rescue systems, small network servers, small >>> streamers etc... >> >> >> usbstick (especially with livecd-iso-to-disk) is really just an >> alternate form of livecd. >> >> But yes, the changes I proposed to mayflower can also be used to >> generate initramfss that are useful as rescue systems, and perhaps >> even as entire-system-in-initramfs for small servers/routers. I never >> suggested it was useful for livecd only. >> >> >> >>>> >>>> 2) the persistence feature. >>> >>> >>> It is a must have feature. But again this should be configurable. >>> Currently Which I developed is doing a persistence at the time of >>> instalation(again a bit hard coded). >> >> >> I'm still curious where this implementation you speak of that you >> claim was posted to this list is. Please repost or give a link to an >> archive post. > > I have a very vague vison fo what to be separated. I think the target > specific things should be on a separate file. > from which the KS file can read and work acordingly. As an example the > drivers which goes into the initrd are hard coded. %post mayflower invocation > Suppose i got a weired hardware which needs some special drivers then i > am helpless in current scenario. > %post mayflower invocation > why should be there a ISO-to-USB script? because it's so blaringly obviously convenient and useful. Especially for people that downloaded the f7 livecd, want to boot from usb, and have no interest in running livecd-creator or something similar on their system. This sort of configuration > should go into separate config file too. > > Try using KS file only for the package instalation and post > configuration of the installed system. > Try to Implement a Config based image creation and target setup. I'm still not seeing any example where its necessary. > I can say this much at this time. So what you're saying, is that you are waving your hands about this alleged persistence implementation of yours, which offlist you claim has already been posted to the list, but when asked to actually provide a link to the post or the implementation, you've got nuthin. -dmc >> >> I'm curious whether your implementation has design aspects that are >> better than the implementation I posted a couple weeks ago, and >> discussed at length on this list in the couple weeks before that. >> >> (as I've told Tim offlist, I'll be posting an updated version of that >> implementation within the next couple of days. I'm just honing my git >> skills at the moment) >> >> -dmc >> >>> >>>> >>>> OTOH, here is how I guess I could imagine cramming everything into >>>> the kickstart- >>>> >>>> 1) have some truly magic livecd kickstart command to add files to >>>> the isodir. This command would be silently ignored in the >>>> non-livecd case (or perhaps files copied to /iso or some arbitrary >>>> directory in a non-livecd kickstart invocation). >>>> >>>> 2) and this is rather key- put the mayflower invocation in the %post >>>> of the kickstart. Perhaps even enclose it in a conditional, based >>>> on some variable that only gets defined in the livecd case. Then >>>> perhaps even merge the livecd-creator code back into anaconda, ala >>>> the old kadischi anaconda rootpath livecd creation facility. (yes >>>> Jeremy, I'm trying to give you nightmares ;) >>>> >>>> 2 as described (with or without remerge with anaconda) also gives >>>> you the ability to customize the initramfs (e.g. add persistence and >>>> similar mayflower optional features) in the %post of the kickstart. >>>> >>>> But I want to emphasize to anyone reading this far, that none of >>>> this really has anything to do with the simple modifications and >>>> simple functionality enhancements that I was aiming for in the >>>> parent RFC. This has been a tangent going down rearchitecting the >>>> kickstart/config file and invocation of livecd-creator. >>>> >>>> And actually, given what I described, I kind of like the uglier and >>>> uglier, but single kickstart solution. (the other aspects which >>>> I've complained about in the past, I think I can see workarounds for >>>> as well) >>>> >>>> >>>> -dmc >>>> >>>> -- >>>> Fedora-livecd-list mailing list >>>> Fedora-livecd-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list >>> >>> >>> >>> >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > From katzj at redhat.com Mon Aug 13 17:38:32 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 13 Aug 2007 13:38:32 -0400 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <46C08EF7.30904@filteredperception.org> References: <46BFDA78.1000900@filteredperception.org> <1187013880.1471.10.camel@localhost.localdomain> <46C08EF7.30904@filteredperception.org> Message-ID: <1187026712.4921.20.camel@localhost.localdomain> On Mon, 2007-08-13 at 12:03 -0500, Douglas McClendon wrote: > Jeremy Katz wrote: > > On Sun, 2007-08-12 at 23:13 -0500, Douglas McClendon wrote: > >> I have a few changes I'd like to request to mayflower. I'd like to get > >> some feedback before actually laying down the effort of producing patches. > > > > So from a big high-level point of view, I'd really rather _not_ add lots > > more that people depend on from mayflower. Having two different > > codebases to handle the initramfs (mayflower + mkinitrd) is incredibly > > painful for having to adapt both for changes in the OS, etc. > > I agree that it would be cool if mayflower got absorbed into mkinitrd > (or vice versa). But that seems a litte far off right now, wheras the > changes I presented were all very small, and only served to structure > mayflower in a better way, which I imagine would make it's absorbtion > into mkinitrd easier, not harder. I.e. It's actually not that much work. The first step (switching to using bash for the initramfs so that you don't have to implement conditionals in nash) is actually already done and working -- see the bash-branch of mkinitrd. I just haven't had time to then get the livecd bits using that. I had hoped to for F8, but time is rapidly running out and that's going to be lower on my "caring" list. And note, I'm not really against the changes, I just breathe a heavy sigh every time something else is done in mayflower rather than spending the time on fixing the whole "two initrd" infrastructures thing :/ > >> #3 - optional program, sort of like existing shell cmdline arg > >> > >> Have a cmdline argument of program= and eprogram= which would cause the > >> specified program to be executed. program= would happen right after the > >> current shell, and eprogram would happen right after the current eshell. > > > > Why not just use init= ? Other than the fact that doing so is currently > > broken with mayflower (... see above comments about two implementations > > of the same thing :-) > > The reason is that I very much like all the mayflower generated init > stuff that happens up to the point of the existing shell escape. I.e. > setting up an environment where bash can run and I can see my devices. > By specifying my own init, I'd basically be duplicating the mayflower > init generation code, except with my program= escape point, at which > point... hey, I'm back where this proposal started. init= doesn't replace the initramfs's init -- it's what is supposed to be run after you've got the real system. eg, init=/bin/bash to just get dropped to a shell rather than running /sbin/init. But yeah, after a quick try, something about it is busted with mayflower. Try it on a "normal" system, though, to get the effect that's intended Jeremy From lars.bjorndal at broadpark.no Mon Aug 13 17:40:01 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Mon, 13 Aug 2007 19:40:01 +0200 Subject: [Fedora-livecd-list] error: Couldn't fork %post: Cannot allocate memory In-Reply-To: <1187013044.1471.0.camel@localhost.localdomain> References: <1187013044.1471.0.camel@localhost.localdomain> Message-ID: <20070813174001.GH4505@lamasti.net> On Mon, Aug 13, 2007 at 09:50:44AM -0400, Jeremy Katz wrote: > On Sun, 2007-08-12 at 17:55 +0200, Lars Bj?rndal wrote: > > A lot of that message appeared after trying to make a livecd with the > > latest GIT version of livecd-creator. What could I do to get rid of them? > > Can't fork usually means that you're out of memory... I've been creating > images just fine with current git. Can you provide more details on your > config as well as the exact output of the errors? > I turned on swap, and no it works fine! But, thank you! Lars From jsteer at bitscout.com Mon Aug 13 17:45:47 2007 From: jsteer at bitscout.com (Jon Steer) Date: Mon, 13 Aug 2007 13:45:47 -0400 Subject: [Fedora-livecd-list] Can't boot LiveCD Boot on MS Virtual Server 2005 R2 Message-ID: <74e6f65d0708131045r7d60e1a8hb4da57d58a093142@mail.gmail.com> My LiveCD boot is hanging when booting from MS Virtual Server 2005 R2. F6 based LiveCD's worked fine. It hangs at Uncompressing Linux.. Ok, booting the kernel. Since the box is running on a Dell Dual Core box, I tried all the maxcpu suggestions but no joy. Any ideas? Any ideas on what I can enable to get some tracing? thanks, jon -- "Whereever you go, there you are" From dmc.fedora at filteredperception.org Mon Aug 13 17:47:47 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 12:47:47 -0500 Subject: [Fedora-livecd-list] RFC- improving livecd installer efficiency In-Reply-To: <1184235333.7592.12.camel@blaa> References: <46936879.50009@filteredperception.org> <1184146607.2997.139.camel@blaa> <4695347F.2010407@filteredperception.org> <1184225112.2820.27.camel@blaa> <4695F8A5.4050305@filteredperception.org> <1184235333.7592.12.camel@blaa> Message-ID: <46C09943.5010003@filteredperception.org> Mark McLoughlin wrote: > Hey, > Okay, I follow you now. Doing: > > - Create snapshot of os.img > - Resize it down to the smallest possible size > - Copy it to disk > - Resize it back up to the size of the disk > > has the dual advantages of being able to install to the small possible > disk size and not copying unallocated blocks. > > Sounds like a reasonable plan ... go ahead and give it a shot. turboLiveInst has been posted, polished, reposted with real world IMPRESSIVE performance results, and has now been collecting dust for a couple weeks. I don't suppose you'd be kind enough to give it a review for me Mark? Especially since you seem to understand the basic gist of the devicemapper snapshot resize2fs technique. I'd really like to get it into rawhide/f8t2 ASAP so that if there is some fundamental problem with the approach that we discover and deal with it (or trash it*) sooner rather than later. * obviously I'm kidding. There is no problem. Its solid, elegant, and the right answer, and nobody has suggested any reason to the contrary. Regards, -dmc > > Cheers, > Mark. From dmc.fedora at filteredperception.org Mon Aug 13 17:54:29 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 12:54:29 -0500 Subject: [Fedora-livecd-list] RFC- mayflower flexibility enhancements In-Reply-To: <1187026712.4921.20.camel@localhost.localdomain> References: <46BFDA78.1000900@filteredperception.org> <1187013880.1471.10.camel@localhost.localdomain> <46C08EF7.30904@filteredperception.org> <1187026712.4921.20.camel@localhost.localdomain> Message-ID: <46C09AD5.9050005@filteredperception.org> Jeremy Katz wrote: >> The reason is that I very much like all the mayflower generated init >> stuff that happens up to the point of the existing shell escape. I.e. >> setting up an environment where bash can run and I can see my devices. >> By specifying my own init, I'd basically be duplicating the mayflower >> init generation code, except with my program= escape point, at which >> point... hey, I'm back where this proposal started. > > init= doesn't replace the initramfs's init -- it's what is supposed to > be run after you've got the real system. eg, init=/bin/bash to just get > dropped to a shell rather than running /sbin/init. But yeah, after a > quick try, something about it is busted with mayflower. Try it on a > "normal" system, though, to get the effect that's intended Assuming mayflower gets fixed, would there be any issue with the fact that in my usage scenarios, there is no real root filesystem, and that the init I'm trying to specify is a program in the initramfs? -dmc From dmc.fedora at filteredperception.org Mon Aug 13 19:14:14 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 14:14:14 -0500 Subject: [Fedora-livecd-list] Can't boot LiveCD Boot on MS Virtual Server 2005 R2 In-Reply-To: <74e6f65d0708131045r7d60e1a8hb4da57d58a093142@mail.gmail.com> References: <74e6f65d0708131045r7d60e1a8hb4da57d58a093142@mail.gmail.com> Message-ID: <46C0AD86.1050500@filteredperception.org> Jon Steer wrote: > My LiveCD boot is hanging when booting from MS Virtual Server 2005 R2. > > F6 based LiveCD's worked fine. > > > It hangs at > Uncompressing Linux.. Ok, booting the kernel. > > Since the box is running on a Dell Dual Core box, I tried all the > maxcpu suggestions but no joy. > > Any ideas? Any ideas on what I can enable to get some tracing? Passing 'verbose' and not 'quiet' on the kernel command line will get more info for debugging. (press tab at isolinux boot choice screen, which I assume should work from MSVS though I've never used MSVS myself). If you've already tried that, the only other idea I have is that qemu had a bug with large initramfss, though I can't really imagine that info will help your situation in any way. Regards, -dmc From Matt_Domsch at dell.com Tue Aug 14 03:11:10 2007 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 13 Aug 2007 22:11:10 -0500 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? Message-ID: <20070814031110.GC24149@auslistsprd01.us.dell.com> I want to be sure, for license compliance, that all the binary bits on the final LiveCD have corresponding source code available. One of the "features" I'd like to see something in the stack of livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the RPMs that go into the LiveCD. Smooge and I have both done this ourselves, with varying degrees of ease, essentially querying all the installed RPMs on the LiveCD after-the-fact and generating the list, then grabbing the files etc. All very manual. I expect there's a better way, and I'm even open to helping code it, but am looking for direction from you - those who know the tools best... Maybe it's really an Anaconda feature? Advise please. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dmc.fedora at filteredperception.org Tue Aug 14 04:29:21 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 23:29:21 -0500 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070814031110.GC24149@auslistsprd01.us.dell.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> Message-ID: <46C12FA1.5030207@filteredperception.org> Matt Domsch wrote: > I want to be sure, for license compliance, that all the binary bits on > the final LiveCD have corresponding source code available. > > One of the "features" I'd like to see something in the stack of > livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the > RPMs that go into the LiveCD. Smooge and I have both done this > ourselves, with varying degrees of ease, essentially querying all the > installed RPMs on the LiveCD after-the-fact and generating the list, > then grabbing the files etc. All very manual. I expect there's a > better way, and I'm even open to helping code it, but am looking for > direction from you - those who know the tools best... A more 'during the fact' approach would be to do an rpm -qa at the end of your %post. Then maybe still in the %post, iterate over that list with rpm -qi, looking at the src rpm entry. I notice yum has disabled by default source repos. I can't immediately see how to use them, but perhaps you could then further take the list above, and still in the %post do something to query the source repos via yum, perhaps temporarily downloading the src rpm, generating sha1sum, such that the resulting livecd includes a list of sha1sums for every src rpm. Then it would be easy enough to after the fact, extract that list from the livecd, and pull a collection of the src rpms. Just some thoughts... Perhaps somebody can tell me why the source repos are there in the default yum config, and what can actually be done with them via yum. -dmc From dmc.fedora at filteredperception.org Tue Aug 14 04:50:58 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 13 Aug 2007 23:50:58 -0500 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C12FA1.5030207@filteredperception.org> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <46C12FA1.5030207@filteredperception.org> Message-ID: <46C134B2.3070408@filteredperception.org> Douglas McClendon wrote: > Matt Domsch wrote: >> I want to be sure, for license compliance, that all the binary bits on >> the final LiveCD have corresponding source code available. >> >> One of the "features" I'd like to see something in the stack of >> livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the >> RPMs that go into the LiveCD. Smooge and I have both done this >> ourselves, with varying degrees of ease, essentially querying all the >> installed RPMs on the LiveCD after-the-fact and generating the list, >> then grabbing the files etc. All very manual. I expect there's a >> better way, and I'm even open to helping code it, but am looking for >> direction from you - those who know the tools best... > > A more 'during the fact' approach would be to do an rpm -qa at the end > of your %post. Then maybe still in the %post, iterate over that list > with rpm -qi, looking at the src rpm entry. > > I notice yum has disabled by default source repos. I can't immediately > see how to use them, but perhaps you could then further take the list > above, and still in the %post do something to query the source repos via > yum, perhaps temporarily downloading the src rpm, generating sha1sum, > such that the resulting livecd includes a list of sha1sums for every src > rpm. Then it would be easy enough to after the fact, extract that list > from the livecd, and pull a collection of the src rpms. > > Just some thoughts... Perhaps somebody can tell me why the source repos > are there in the default yum config, and what can actually be done with > them via yum. Ok, so I found yum-utils. So you could iterate over your list of src rpms above, with yumdownloader --source, and yum-builddep to really make sure that you get all the source needed to rebuild the livecd. Of course the true end-all, would be to then create an alternate version of your livecd, which included all of those things (and presumably some list of binary rpms needed for bootstrapping), as well as livecd-tools, in a /rebuild directory, such that this alternate live-bluray was completely capable of self-hosted-recompilation/production from included source (preferably from a simple script/program executable from the booted live-bluray, that requires no user interaction if it can find a suitably large tmpdir, and also no root privileges, if my aforementioned qrr program exists and is fully integrated) That seems to me to be the most elegant way to distribute a gpl distribution :) -dmc From jonathansteffan at gmail.com Tue Aug 14 05:25:51 2007 From: jonathansteffan at gmail.com (Jonathan Steffan) Date: Mon, 13 Aug 2007 23:25:51 -0600 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070814031110.GC24149@auslistsprd01.us.dell.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> Message-ID: <1187069151.27477.9.camel@damaestro> On Mon, 2007-08-13 at 22:11 -0500, Matt Domsch wrote: > I want to be sure, for license compliance, that all the binary bits on > the final LiveCD have corresponding source code available. > > One of the "features" I'd like to see something in the stack of > livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the > RPMs that go into the LiveCD. Smooge and I have both done this > ourselves, with varying degrees of ease, essentially querying all the > installed RPMs on the LiveCD after-the-fact and generating the list, > then grabbing the files etc. All very manual. I expect there's a > better way, and I'm even open to helping code it, but am looking for > direction from you - those who know the tools best... We can just use the same concept that pungi uses. The revisor team is actually working on this and when we have progress we'll let the list know. If anyone wants to just get it done, please do. def getSRPMList(self): """Cycle through the list of package objects and find the sourcerpm for them. Requires yum still configured and a list of package objects""" for po in self.polist: srpm = po.sourcerpm.split('.src.rpm')[0] if not srpm in self.srpmlist: self.srpmlist.append(srpm) Start reading at line 327 of /usr/lib/python2.5/site-packages/pypungi/gather.py: def downloadSRPMs(self): """Cycle through the list of srpms and find the package objects for them, Then download them.""" [...] Jonathan Steffan From kanarip at kanarip.com Tue Aug 14 17:02:20 2007 From: kanarip at kanarip.com (Jeroen Van Meeuwen) Date: Tue, 14 Aug 2007 10:02:20 -0700 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? Message-ID: <0JMR00E1I7O2OR90@jes-fe2.zx.nl> Hey, this is done already. Downloading packages includes downloading the corresponding SRPMs, even for Live Media. /me, from his cell -----Oorspronkelijk bericht ----- Van: "Jonathan Steffan" Aan: fedora-livecd-list at redhat.com Verzonden: 07-08-13 22:25 Onderwerp: Re: [Fedora-livecd-list] SRPMS for installed RPMs? On Mon, 2007-08-13 at 22:11 -0500, Matt Domsch wrote: > I want to be sure, for license compliance, that all the binary bits on > the final LiveCD have corresponding source code available. > > One of the "features" I'd like to see something in the stack of > livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the > RPMs that go into the LiveCD. Smooge and I have both done this > ourselves, with varying degrees of ease, essentially querying all the > installed RPMs on the LiveCD after-the-fact and generating the list, > then grabbing the files etc. All very manual. I expect there's a > better way, and I'm even open to helping code it, but am looking for > direction from you - those who know the tools best... We can just use the same concept that pungi uses. The revisor team is actually working on this and when we have progress we'll let the list know. If anyone wants to just get it done, please do. def getSRPMList(self): """Cycle through the list of package objects and find the sourcerpm for them. Requires yum still configured and a list of package objects""" for po in self.polist: srpm = po.sourcerpm.split('.src.rpm')[0] if not srpm in self.srpmlist: self.srpmlist.append(srpm) Start reading at line 327 of /usr/lib/python2.5/site-packages/pypungi/gather.py: def downloadSRPMs(self): """Cycle through the list of srpms and find the package objects for them, Then download them.""" [...] Jonathan Steffan -- Fedora-livecd-list mailing list Fedora-livecd-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list From kanarip at kanarip.com Tue Aug 14 08:53:54 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 14 Aug 2007 10:53:54 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <0JMR00E1I7O2OR90@jes-fe2.zx.nl> References: <0JMR00E1I7O2OR90@jes-fe2.zx.nl> Message-ID: <46C16DA2.7060909@kanarip.com> Jeroen Van Meeuwen wrote: > Hey, this is done already. Downloading packages includes downloading the corresponding SRPMs, even for Live Media. > > /me, from his cell > That's a very short note not telling anyone how to get Revisor to also include source. In the model config, set getsource=1 (or True) Revisor, when having downloaded the RPMs, will list the repositories that were enabled, search for it's %s-source equivalent, enable that repository, and build a packageSack based on the src arch alone, then iterate over all tsInfo.getMembers() and download their src arch equivalents. Those SRPMs will end up in a tree similar to how Fedora distributed it's SRPMs. This should all magically work in 2.0.4.2-1.fc7 (although I might have fixed a few tracebacks since then -these would only occur if the %s-source repo doesn't exist or yum fails building a pkgSack from it). Kind regards, Jeroen van Meeuwen -kanarip > -----Oorspronkelijk bericht ----- > Van: "Jonathan Steffan" > Aan: fedora-livecd-list at redhat.com > Verzonden: 07-08-13 22:25 > Onderwerp: Re: [Fedora-livecd-list] SRPMS for installed RPMs? > > On Mon, 2007-08-13 at 22:11 -0500, Matt Domsch wrote: >> I want to be sure, for license compliance, that all the binary bits on >> the final LiveCD have corresponding source code available. >> >> One of the "features" I'd like to see something in the stack of >> livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the >> RPMs that go into the LiveCD. Smooge and I have both done this >> ourselves, with varying degrees of ease, essentially querying all the >> installed RPMs on the LiveCD after-the-fact and generating the list, >> then grabbing the files etc. All very manual. I expect there's a >> better way, and I'm even open to helping code it, but am looking for >> direction from you - those who know the tools best... > > We can just use the same concept that pungi uses. The revisor team is > actually working on this and when we have progress we'll let the list > know. If anyone wants to just get it done, please do. > > def getSRPMList(self): > """Cycle through the list of package objects and > find the sourcerpm for them. Requires yum still > configured and a list of package objects""" > > > for po in self.polist: > srpm = po.sourcerpm.split('.src.rpm')[0] > if not srpm in self.srpmlist: > self.srpmlist.append(srpm) > > Start reading at line 327 > of /usr/lib/python2.5/site-packages/pypungi/gather.py: > > def downloadSRPMs(self): > """Cycle through the list of srpms and > find the package objects for them, Then download them.""" > [...] > > Jonathan Steffan > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From katzj at redhat.com Tue Aug 14 14:34:20 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Aug 2007 10:34:20 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070814031110.GC24149@auslistsprd01.us.dell.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> Message-ID: <1187102060.22509.4.camel@localhost.localdomain> On Mon, 2007-08-13 at 22:11 -0500, Matt Domsch wrote: > I want to be sure, for license compliance, that all the binary bits on > the final LiveCD have corresponding source code available. > > One of the "features" I'd like to see something in the stack of > livecd-tools produce is a CD/DVD/whatever of the SRPMS that match the > RPMs that go into the LiveCD. Smooge and I have both done this > ourselves, with varying degrees of ease, essentially querying all the > installed RPMs on the LiveCD after-the-fact and generating the list, > then grabbing the files etc. All very manual. I expect there's a > better way, and I'm even open to helping code it, but am looking for > direction from you - those who know the tools best... The big problem is going to be that when we point to a repo, there's no guarantee that there's source in that repo. In fact, with the way we do repos, there isn't. And given that, doing this just within the confines of livecd-creator is going to be tricky. For the general Fedora case, it's a bit of a moot point (images are created pointing at the pungi'd everything repo which then has its source put up). For more general creation, though, I can see where it could be desired, I just don't see a good general path to get there. :-/ Jeremy From patrice.guay at nanotechnologies.qc.ca Tue Aug 14 14:59:23 2007 From: patrice.guay at nanotechnologies.qc.ca (Patrice Guay) Date: Tue, 14 Aug 2007 10:59:23 -0400 Subject: [Fedora-livecd-list] Missing boot option: default bootloader In-Reply-To: <435E2C12-7201-402E-B354-C50AFA44472F@datawranglers.com> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> <1186589846.3096.24.camel@localhost.localdomain> <1186590996.3187.2.camel@neutron.verbum.private> <435E2C12-7201-402E-B354-C50AFA44472F@datawranglers.com> Message-ID: <46C1C34B.3070203@nanotechnologies.qc.ca> I think there is a missing boot option on Live media created by livecd-creator: boot from the system default bootloader. Since the Live media (CDROM or USB key) created from livecd-creator is not ejected when the system is restarted or shut down, the user needs to remove it immediately after the system starts up if he doesn't to boot from the live media. The option to boot from the system default bootloader would be a nice addition for advanced users. -- Patrice Guay From katzj at redhat.com Tue Aug 14 16:47:52 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 14 Aug 2007 12:47:52 -0400 Subject: [Fedora-livecd-list] Missing boot option: default bootloader In-Reply-To: <46C1C34B.3070203@nanotechnologies.qc.ca> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> <1186589846.3096.24.camel@localhost.localdomain> <1186590996.3187.2.camel@neutron.verbum.private> <435E2C12-7201-402E-B354-C50AFA44472F@datawranglers.com> <46C1C34B.3070203@nanotechnologies.qc.ca> Message-ID: <1187110072.22509.11.camel@localhost.localdomain> On Tue, 2007-08-14 at 10:59 -0400, Patrice Guay wrote: > I think there is a missing boot option on Live media created by > livecd-creator: boot from the system default bootloader. Since the Live > media (CDROM or USB key) created from livecd-creator is not ejected when > the system is restarted or shut down, the user needs to remove it > immediately after the system starts up if he doesn't to boot from the > live media. The option to boot from the system default bootloader would > be a nice addition for advanced users. At least for x86, it should be easy enough to add localboot. It can't necessarily be guaranteed to work as there's dependencies on the BIOS not being broken, but we do it for the boot CDs. Can you file something in bugzilla and I'll take a look into it? Jeremy From patrice.guay at nanotechnologies.qc.ca Tue Aug 14 17:40:27 2007 From: patrice.guay at nanotechnologies.qc.ca (Patrice Guay) Date: Tue, 14 Aug 2007 13:40:27 -0400 Subject: [Fedora-livecd-list] Missing boot option: default bootloader In-Reply-To: <1187110072.22509.11.camel@localhost.localdomain> References: <1186517302.3674.23.camel@neutron.verbum.private> <1186523048.3674.33.camel@neutron.verbum.private> <1186589846.3096.24.camel@localhost.localdomain> <1186590996.3187.2.camel@neutron.verbum.private> <435E2C12-7201-402E-B354-C50AFA44472F@datawranglers.com> <46C1C34B.3070203@nanotechnologies.qc.ca> <1187110072.22509.11.camel@localhost.localdomain> Message-ID: <46C1E90B.6060902@nanotechnologies.qc.ca> Jeremy Katz wrote: > On Tue, 2007-08-14 at 10:59 -0400, Patrice Guay wrote: >> I think there is a missing boot option on Live media created by >> livecd-creator: boot from the system default bootloader. Since the Live >> media (CDROM or USB key) created from livecd-creator is not ejected when >> the system is restarted or shut down, the user needs to remove it >> immediately after the system starts up if he doesn't to boot from the >> live media. The option to boot from the system default bootloader would >> be a nice addition for advanced users. > > At least for x86, it should be easy enough to add localboot. It can't > necessarily be guaranteed to work as there's dependencies on the BIOS > not being broken, but we do it for the boot CDs. > > Can you file something in bugzilla and I'll take a look into it? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=252192 -- Patrice Guay From lars.bjorndal at broadpark.no Wed Aug 15 13:57:00 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Wed, 15 Aug 2007 15:57:00 +0200 Subject: [Fedora-livecd-list] How to install one package from a specific repo? Message-ID: 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 From kanarip at kanarip.com Wed Aug 15 14:03:06 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 15 Aug 2007 16:03:06 +0200 Subject: [Fedora-livecd-list] How to install one package from a specific repo? In-Reply-To: References: Message-ID: <46C3079A.7000504@kanarip.com> Lars Bj?rndal wrote: > 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 > Configure the development repository in the yum configuration you use for creating the livecd with, enable it and add a line: includepkgs=clamav Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Aug 15 14:07:50 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Aug 2007 10:07:50 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <1187102060.22509.4.camel@localhost.localdomain> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> Message-ID: <20070815100750.2ec2e54c@mentok.boston.redhat.com> On Tue, 14 Aug 2007 10:34:20 -0400 Jeremy Katz wrote: > The big problem is going to be that when we point to a repo, there's > no guarantee that there's source in that repo. In fact, with the way > we do repos, there isn't. And given that, doing this just within the > confines of livecd-creator is going to be tricky. Well you'd have to add a second repo to your configuration. Not only that, but you have to "reset" the yum object so that it will actually "see" the source rpms when it comes time to search for them and download them from your package sacks. In pungi I actually just create a second yum object to handle this instead of trying to reset the original object. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Wed Aug 15 14:49:20 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Wed, 15 Aug 2007 16:49:20 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070815100750.2ec2e54c@mentok.boston.redhat.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> Message-ID: <46C31270.6090209@kanarip.com> Jesse Keating wrote: > On Tue, 14 Aug 2007 10:34:20 -0400 > Jeremy Katz wrote: > >> The big problem is going to be that when we point to a repo, there's >> no guarantee that there's source in that repo. In fact, with the way >> we do repos, there isn't. And given that, doing this just within the >> confines of livecd-creator is going to be tricky. > > Well you'd have to add a second repo to your configuration. Not only > that, but you have to "reset" the yum object so that it will actually > "see" the source rpms when it comes time to search for them and > download them from your package sacks. In pungi I actually just create > a second yum object to handle this instead of trying to reset the > original object. > You could just use the existing yum object; and not reset it. http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l569 http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l589 Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Wed Aug 15 15:13:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 15 Aug 2007 11:13:12 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C31270.6090209@kanarip.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> Message-ID: <20070815111312.1b370537@mentok.boston.redhat.com> On Wed, 15 Aug 2007 16:49:20 +0200 Jeroen van Meeuwen wrote: > You could just use the existing yum object; and not reset it. > > http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l569 > > http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l589 Interesting. I'll play with this in Pungi. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Thu Aug 16 17:56:05 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 16 Aug 2007 19:56:05 +0200 Subject: [Fedora-livecd-list] How to remove groups in second config? Message-ID: <200708161956.14112.ml@deadbabylon.de> Hi. (This is for the new changes to livecd-creator from git which uses two kickstarts.) Is there a way to remove a group which is defined in the first config (here livecd-config-base-desktop.ks) in the second config (here livecd-fedora-kde.ks)? My problem is that the language groups (e.g. @estonian-support) pulls also the kde language files (kde-i18n-Estonian) and koffice language files (koffice-langpack-et) in the livecd. And I am not able to remove them in the second config (e.g. -kde-18n-* or -kde-i18n-et). Any hint how to fix this? The language files are about 325 megs and that's to big for the cd. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu Aug 16 18:05:51 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Aug 2007 14:05:51 -0400 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <200708161956.14112.ml@deadbabylon.de> References: <200708161956.14112.ml@deadbabylon.de> Message-ID: <1187287551.17169.10.camel@localhost.localdomain> On Thu, 2007-08-16 at 19:56 +0200, Sebastian Vahl wrote: > Is there a way to remove a group which is defined in the first config (here > livecd-config-base-desktop.ks) in the second config (here > livecd-fedora-kde.ks)? There's not really syntax for removing groups at present. Given the things causing you problems, you could just do -kde-i18n* -koffice-langpack* like has been done in the past for a few things. Alternately, we could move the lang-support groups into desktop instead of -base-desktop Jeremy From ml at deadbabylon.de Thu Aug 16 18:10:24 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 16 Aug 2007 20:10:24 +0200 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <1187287551.17169.10.camel@localhost.localdomain> References: <200708161956.14112.ml@deadbabylon.de> <1187287551.17169.10.camel@localhost.localdomain> Message-ID: <200708162010.33158.ml@deadbabylon.de> Am Do 16.August 2007 schrieb Jeremy Katz: > On Thu, 2007-08-16 at 19:56 +0200, Sebastian Vahl wrote: > > Is there a way to remove a group which is defined in the first config > > (here livecd-config-base-desktop.ks) in the second config (here > > livecd-fedora-kde.ks)? > > There's not really syntax for removing groups at present. Given the > things causing you problems, you could just do > -kde-i18n* > -koffice-langpack* > like has been done in the past for a few things. I don't know why but this is not working. I could remove eg. gnome-games but kde-i18n-* and koffice-langpack-* would anyway be installed. > Alternately, we could move the lang-support groups into desktop instead > of -base-desktop ATM I would think that's the best option. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Thu Aug 16 19:16:38 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Aug 2007 15:16:38 -0400 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <200708162010.33158.ml@deadbabylon.de> References: <200708161956.14112.ml@deadbabylon.de> <1187287551.17169.10.camel@localhost.localdomain> <200708162010.33158.ml@deadbabylon.de> Message-ID: <1187291798.637.9.camel@localhost.localdomain> On Thu, 2007-08-16 at 20:10 +0200, Sebastian Vahl wrote: > Am Do 16.August 2007 schrieb Jeremy Katz: > > On Thu, 2007-08-16 at 19:56 +0200, Sebastian Vahl wrote: > > > Is there a way to remove a group which is defined in the first config > > > (here livecd-config-base-desktop.ks) in the second config (here > > > livecd-fedora-kde.ks)? > > > > There's not really syntax for removing groups at present. Given the > > things causing you problems, you could just do > > -kde-i18n* > > -koffice-langpack* > > like has been done in the past for a few things. > > I don't know why but this is not working. I could remove eg. gnome-games but > kde-i18n-* and koffice-langpack-* would anyway be installed. Oh, ugh. I know why this doesn't work. /me stabs conditionals in comps a thousand times. > > Alternately, we could move the lang-support groups into desktop instead > > of -base-desktop > > ATM I would think that's the best option. Okay, will move them over later unless you beat me to it :) Jeremy From ml at deadbabylon.de Thu Aug 16 19:40:30 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Thu, 16 Aug 2007 21:40:30 +0200 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <1187291798.637.9.camel@localhost.localdomain> References: <200708161956.14112.ml@deadbabylon.de> <1187287551.17169.10.camel@localhost.localdomain> <200708162010.33158.ml@deadbabylon.de> <1187291798.637.9.camel@localhost.localdomain> Message-ID: <20070816214030.3c8b5157@localhost.localdomain> Am Thu, 16 Aug 2007 15:16:38 -0400 schrieb Jeremy Katz : > On Thu, 2007-08-16 at 20:10 +0200, Sebastian Vahl wrote: > > Am Do 16.August 2007 schrieb Jeremy Katz: > > > On Thu, 2007-08-16 at 19:56 +0200, Sebastian Vahl wrote: > > > > Is there a way to remove a group which is defined in the first > > > > config (here livecd-config-base-desktop.ks) in the second > > > > config (here livecd-fedora-kde.ks)? > > > > > > There's not really syntax for removing groups at present. Given > > > the things causing you problems, you could just do > > > -kde-i18n* > > > -koffice-langpack* > > > like has been done in the past for a few things. > > > > I don't know why but this is not working. I could remove eg. > > gnome-games but kde-i18n-* and koffice-langpack-* would anyway be > > installed. > > Oh, ugh. I know why this doesn't work. /me stabs conditionals in > comps a thousand times. Ah. Ok. > > > > Alternately, we could move the lang-support groups into desktop > > > instead of -base-desktop > > > > ATM I would think that's the best option. > > Okay, will move them over later unless you beat me to it :) Do it when you find the time. :) I could modify my local version. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From lars.bjorndal at broadpark.no Thu Aug 16 20:29:37 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Thu, 16 Aug 2007 22:29:37 +0200 Subject: [Fedora-livecd-list] How to install one package from a specific repo? In-Reply-To: <46C3079A.7000504@kanarip.com> (Jeroen van Meeuwen's message of "Wed, 15 Aug 2007 16:03:06 +0200") References: <46C3079A.7000504@kanarip.com> Message-ID: Jeroen van Meeuwen writes: > Lars Bj?rndal wrote: >> 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 >> > > Configure the development repository in the yum configuration you use > for creating the livecd with, enable it and add a line: > > includepkgs=clamav OK. I'm using livecd-creator to build the CD, should I add something like: repo --name=development\ --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch\ --includepkgs=clamav clamav-update etc.? I've tried to leave out the 'repo' lines in the .ks file. I thought doing so, would force livecd-creator to use the yum repositories configured on the build host, but the process would not start. Lars From lars.bjorndal at broadpark.no Fri Aug 17 13:37:03 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Fri, 17 Aug 2007 15:37:03 +0200 Subject: [Fedora-livecd-list] How to install one package from a specific repo? In-Reply-To: (Lars =?iso-8859-1?Q?Bj=F8rn?= =?iso-8859-1?Q?dal's?= message of "Thu, 16 Aug 2007 22:29:37 +0200") References: <46C3079A.7000504@kanarip.com> Message-ID: Hello! I'm still not able to get only one package, or just a few packages from the development repository to be installed onto a custom livecd I'm going to create. It would be great if you could explain this more in detail to me. Thank you! Lars From jkeating at redhat.com Fri Aug 17 13:51:51 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 09:51:51 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070815111312.1b370537@mentok.boston.redhat.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> Message-ID: <20070817095151.6c617c70@ender> On Wed, 15 Aug 2007 11:13:12 -0400 Jesse Keating wrote: > > You could just use the existing yum object; and not reset it. > > > > http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l569 > > > > http://git.fedoraproject.org/?p=hosted/revisor;a=blob;f=revisor/base.py#l589 > > Interesting. I'll play with this in Pungi. When is the last time you tried this on rawhide? I (and seth) thinks there are some issues with even the basic of 'resetting' the yum object (which you do with the 'self.cfg.yumobj._pkgSack = None'. Further calls to _getSacks return nothing. Perhaps if yours works and mine doesn't has to do with whether or not the source repo was enabled initially or not. I'm going to play with that some. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Aug 17 13:58:15 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 17 Aug 2007 09:58:15 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070817095151.6c617c70@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> Message-ID: <20070817095815.1a8cba29@ender> On Fri, 17 Aug 2007 09:51:51 -0400 Jesse Keating wrote: > Perhaps if yours works and mine doesn't has to do with whether or not > the source repo was enabled initially or not. I'm going to play with > that some. Yes that's it. Not a huge deal I can work with this. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From phillip at lougher.demon.co.uk Fri Aug 17 19:57:31 2007 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Fri, 17 Aug 2007 12:57:31 -0700 (PDT) Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46A27A42.2040900@filteredperception.org> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> Message-ID: <12205702.post@talk.nabble.com> Douglas McClendon-2 wrote: > > Douglas McClendon wrote: > > Ok, so there is a negative consequence of a large container. As I alluded > to > before, mksquashfs apparently does not give any special consideration to > sparse > files. Naturally it can compress a file containing huge blocks of 0s > pretty > well, but it still appears to be going to an aweful lot of work to do > that. > > Short of adding more intelligent handling of sparse files to squashfs > (feasible?), another alternative which satisfies the above resizing > scenarios > would be this- > Unfortunately, I have been aware for sometime that the Fedora liveCD uses sparse files, and Squashfs support was lacking. Happily Squashfs now has sparse file support (in CVS). Max block size has also been increased from 64K to 1Mbyte, with the default 128 Kbytes. Some stats based on the Fedora-8-Test-1-Live-i686.iso original squashfs.img 712495104 (681M) sparse squashfs.img 709820416 (678M) sparse squashfs.img with 128Kbyte blocks 700100608 (669M) So, the compressed 0s used to take up about 2.5 Mbytes. More significant is the data and seek time saving in not reading all these useless compressed 0s. time to do "dd if=os.img of=/dev/null" from CDROM original squashfs.img, 221 seconds sparse squashfs.img, 168 seconds sparse squashfs.img with 128byte blocks, 171 seconds on average about 20% speedup. Regards Phillip -- View this message in context: http://www.nabble.com/-PATCH--cleanupDeleted-and-container_size---saves-5.5--output-size-on-f7livecd-i686-tf4107972.html#a12205702 Sent from the Fedora Livecd List mailing list archive at Nabble.com. From dmc.fedora at filteredperception.org Fri Aug 17 21:02:55 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 16:02:55 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <12205702.post@talk.nabble.com> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> Message-ID: <46C60CFF.3040107@filteredperception.org> Phillip Lougher wrote: > > Douglas McClendon-2 wrote: >> Douglas McClendon wrote: >> >> Ok, so there is a negative consequence of a large container. As I alluded >> to >> before, mksquashfs apparently does not give any special consideration to >> sparse >> files. Naturally it can compress a file containing huge blocks of 0s >> pretty >> well, but it still appears to be going to an aweful lot of work to do >> that. >> >> Short of adding more intelligent handling of sparse files to squashfs >> (feasible?), another alternative which satisfies the above resizing >> scenarios >> would be this- >> > > Unfortunately, I have been aware for sometime that the Fedora liveCD uses > sparse files, and Squashfs support was lacking. Happily Squashfs now has > sparse file support (in CVS). Max block size has also been increased from > 64K to 1Mbyte, with the default 128 Kbytes. very cool. > > Some stats based on the Fedora-8-Test-1-Live-i686.iso > > original squashfs.img 712495104 (681M) > sparse squashfs.img 709820416 (678M) > sparse squashfs.img with 128Kbyte blocks 700100608 (669M) > > So, the compressed 0s used to take up about 2.5 Mbytes. More significant is > the data and seek time saving in not reading all these useless compressed > 0s. > > time to do "dd if=os.img of=/dev/null" from CDROM > > original squashfs.img, 221 seconds > sparse squashfs.img, 168 seconds > sparse squashfs.img with 128byte blocks, 171 seconds > > on average about 20% speedup. 20% speedup of reading data into /dev/null isn't all that useful. You didn't really mention what you were planning on using it for. Presumably you were also aware of my turboLiveInst patch, which accomplishes the 20% speedup in an actual copy situation. The sparse support could be used, perhaps with more code being written to support sparse copying to block devices with python, to gain the performance enhancements of turboLiveInst in an alternate manner. For reasons that I can only speculate to, Jeremy, and everyone else seems to have no interest in my turboLiveInst optimization approach. Perhaps this method will be more palatable for them for some reason. The other thing that I'm curious about, is the performance impact of moving to 128kbyte blocks. I presume that is the compressed data size. I would like to see if, in some typical usage scenarios, whether or not that has a detrimental impact to desktop and general performance during livecd oepration. (i.e. for every 5kb text file read, it needs to uncompress 128Kb of compressed data, adding ram and latency penalties). But the 3MB saved from the sparse support, is absolutely FREE. That is positively excellent, and what I had suspected was the case. Also, I'm guessing that the mksquashfs performance on a 4.0G sparse file with 2.0G of data will be vastly improved. (by my definition of vast, i.e. ~10%) This actually reopens the usefulness of the container-size option which I had included with the first version of the cleanupDeleted patch. I.e. now it is no penalty whatsoever to go with a much larger container size. This will remove the need to perform ugly device-mapper-zero tricks to expand the rootfs size at runtime, if you have enough memory in your overlay device to support that. And assuming of course that either you are using the turboLiveInst patch, or the alternate method described above which requires a little more code to be written. Jeremy- what do you think? I'd still like to get credit for all the work I did in discovering and fixing the problem. It would be a bit disappointing if you guys went and implemented the above alternate solution and took all the credit. I'd be willing to implement the above alternate solution, if you can give reasonable arguments as to why you think the existing turboLiveInst code is not acceptable. Regards, -dmc From dmc.fedora at filteredperception.org Fri Aug 17 21:11:32 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 16:11:32 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46C60CFF.3040107@filteredperception.org> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> Message-ID: <46C60F04.7020209@filteredperception.org> Douglas McClendon wrote: > Jeremy- what do you think? I'd still like to get credit for all the > work I did in discovering and fixing the problem. It would be a bit > disappointing if you guys went and implemented the above alternate > solution and took all the credit. I'd be willing to implement the above > alternate solution, if you can give reasonable arguments as to why you > think the existing turboLiveInst code is not acceptable. > Also, I forgot to include, that the alternate implementation using sparse copy to device, fails to achieve the benefit of supporting destination volumes of 2.1G->4.0G. (and if you utilize a larger container, which has the benefits I've discussed at length in prior threads relating to persistence, this problem scales. I.e. you might want a +10G container instead of the current +2G container, to support using 8GB of free space on your ipod as the persistent overlay device). -dmc From dmc.fedora at filteredperception.org Fri Aug 17 21:40:08 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 16:40:08 -0500 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <1187383816.18195.34.camel@erebor.boston.redhat.com> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> Message-ID: <46C615B8.4010906@filteredperception.org> 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 at 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 > From mclasen at redhat.com Fri Aug 17 21:43:49 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 17:43:49 -0400 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C615B8.4010906@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> Message-ID: <1187387029.1161.95.camel@localhost.localdomain> On Fri, 2007-08-17 at 16:40 -0500, Douglas McClendon wrote: > Lastly, wouldn't test2 require an approved feature? Thats the downside of the new feature process with all the approval and tracking and red tape. People start to think that they are not allowed to work on cool stuff unless it has been approved.... From dmc.fedora at filteredperception.org Fri Aug 17 21:49:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 16:49:53 -0500 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <1187387029.1161.95.camel@localhost.localdomain> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> Message-ID: <46C61801.2050705@filteredperception.org> Matthias Clasen wrote: > On Fri, 2007-08-17 at 16:40 -0500, Douglas McClendon wrote: > >> Lastly, wouldn't test2 require an approved feature? > > Thats the downside of the new feature process with all the approval and > tracking and red tape. People start to think that they are not allowed > to work on cool stuff unless it has been approved.... To who are you referring? I've already posted a (rough) implementation, and asdas at redhat.com claims to have an alternate implementation (though I doubt the claim that it was posted to livecd-list, as I don't remember seeing it). Clearly nobody, relating to the livecd persistence issue, thinks that they aren't allowed to work on cool stuff. We've already got 2 implementations, and it sounds like Jeremy may be starting a 3rd next week. -dmc From mclasen at redhat.com Fri Aug 17 21:56:55 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 17:56:55 -0400 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C61801.2050705@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> Message-ID: <1187387816.1161.98.camel@localhost.localdomain> On Fri, 2007-08-17 at 16:49 -0500, Douglas McClendon wrote: > Matthias Clasen wrote: > > On Fri, 2007-08-17 at 16:40 -0500, Douglas McClendon wrote: > > > >> Lastly, wouldn't test2 require an approved feature? > > > > Thats the downside of the new feature process with all the approval and > > tracking and red tape. People start to think that they are not allowed > > to work on cool stuff unless it has been approved.... > > To who are you referring? I've already posted a (rough) implementation, > and asdas at redhat.com claims to have an alternate implementation (though > I doubt the claim that it was posted to livecd-list, as I don't remember > seeing it). I was just referring to your question about an "approved feature", but maybe I just misunderstood what you were trying to say. > Clearly nobody, relating to the livecd persistence issue, thinks that > they aren't allowed to work on cool stuff. We've already got 2 > implementations, and it sounds like Jeremy may be starting a 3rd next week. > Thats very good, we need cool stuff, the more the better... From dmc.fedora at filteredperception.org Fri Aug 17 22:17:53 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 17:17:53 -0500 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <1187387816.1161.98.camel@localhost.localdomain> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> Message-ID: <46C61E91.8060308@filteredperception.org> Matthias Clasen wrote: > > I was just referring to your question about an "approved feature", but > maybe I just misunderstood what you were trying to say. > I was responding to Jeremy's original email, in which he suggested the impetus for immediate action was to get the code into f8t2. For that to happen, would require an "approved feature", if I understand the fedora policy correctly. I further tried to bring some onlist exposure to the offlist discussion I had with GDK regarding why I haven't personally signed the fedora CLA such that I could personally add the proposed feature to the wiki. The issue is, that the current (or as of a couple weeks ago) CLA would appear to give redhat the legal right to take works submitted under the CLA-related channels, and then modify and redistribute them without the GPL style restriction of requiring modifcations to be submitted back to the original author. GDK and fedora legal seemed to agree that this was in fact the case, but I have not yet heard back from GDK's reply which he also cc'd to Max. If those changes got 'committed' to the CLA to remove that (presumably unintentional, but still unpalatable) loophole, then I would personally sign the CLA, and submit the livecd persistence feature as a proposed feature, such that it could make it into f8t2, as Jeremy clearly has in mind. I hope that clarifies the issue I was trying to present. -dmc From mclasen at redhat.com Fri Aug 17 22:24:43 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 17 Aug 2007 18:24:43 -0400 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C61E91.8060308@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> <46C61E91.8060308@filteredperception.org> Message-ID: <1187389483.1161.102.camel@localhost.localdomain> On Fri, 2007-08-17 at 17:17 -0500, Douglas McClendon wrote: > Matthias Clasen wrote: > > > > > I was just referring to your question about an "approved feature", but > > maybe I just misunderstood what you were trying to say. > > > > I was responding to Jeremy's original email, in which he suggested the > impetus for immediate action was to get the code into f8t2. For that to > happen, would require an "approved feature", if I understand the fedora > policy correctly. > Ah, then I did not misunderstand what you were trying to say. There is no need to get prior approval to work on cool stuff in Fedora. And a lot of the cool stuff in Fedora 8 will just show up without being on any approved feature lists. From dmc.fedora at filteredperception.org Fri Aug 17 22:44:38 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 17:44:38 -0500 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <1187389483.1161.102.camel@localhost.localdomain> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> <46C61E91.8060308@filteredperception.org> <1187389483.1161.102.camel@localhost.localdomain> Message-ID: <46C624D6.9030605@filteredperception.org> Matthias Clasen wrote: > On Fri, 2007-08-17 at 17:17 -0500, Douglas McClendon wrote: >> Matthias Clasen wrote: >> >>> I was just referring to your question about an "approved feature", but >>> maybe I just misunderstood what you were trying to say. >>> >> I was responding to Jeremy's original email, in which he suggested the >> impetus for immediate action was to get the code into f8t2. For that to >> happen, would require an "approved feature", if I understand the fedora >> policy correctly. >> > > Ah, then I did not misunderstand what you were trying to say. There is > no need to get prior approval to work on cool stuff in Fedora. And a lot > of the cool stuff in Fedora 8 will just show up without being on any > approved feature lists. Yes, I was wrong in my interpretation of FeatureFreeze, and how it is a marketing/documentation thing, as opposed to DevelFreeze's which were what I was thinking more of. Still, I think it would be nice if LiveCD Persistence was on official feature, benefiting from that status and the related process. But again, I assume you are harping on the talking point of "no need to get prior approval to work on cool stuff in Fedora" because that needs to be advertised to readers of the list. And not because it actually has any bearing on the current issue. If not, then I am still misunderstanding your point. Regards, -dmc From dmc.fedora at filteredperception.org Fri Aug 17 23:03:10 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 17 Aug 2007 18:03:10 -0500 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C624D6.9030605@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> <46C61E91.8060308@filteredperception.org> <1187389483.1161.102.camel@localhost.localdomain> <46C624D6.9030605@filteredperception.org> Message-ID: <46C6292E.6070409@filteredperception.org> Douglas McClendon wrote: > Matthias Clasen wrote: >> >> Ah, then I did not misunderstand what you were trying to say. There is >> no need to get prior approval to work on cool stuff in Fedora. And a lot >> of the cool stuff in Fedora 8 will just show up without being on any >> approved feature lists. > > Still, I think it would be nice if LiveCD Persistence was on official > feature, benefiting from that status and the related process. Another reason why having LiveCD Persistence as an official feature is quite important, is if it is already getting talked about as an official feature. It's possible that in this quote, Max is just talking about traditional installation to external usb drive, but it's also possible(?) he is talking about livecd persistence (certainly adding dm-crypt to the base and or overlay images is not hard). http://www.technetra.com/writings/archive/2007/07/01/face-to-face-with-max-spevack " Q: What is the vision for Fedora tomorrow? Max: The two biggest goals for Fedora 7 were the live CD/live DVD stuff which was something Fedora needed in order to be able to compete at the same level as other distributions. So we've got that. In Fedora 8 and 9, over the next year let's say, we want to make the technology even better. For example, envision you take your whole computer around on your USB key and you stick it into any laptop and your desktop just appears. If you lose it, your data is encrypted, so it's not as much of a catastrophe as it could be ? at least your bank account is not all over the world. " -dmc From vladimir.shebordaev at gmail.com Fri Aug 17 23:13:16 2007 From: vladimir.shebordaev at gmail.com (Vladimir Shebordaev) Date: Sat, 18 Aug 2007 03:13:16 +0400 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C6292E.6070409@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> <46C61E91.8060308@filteredperception.org> <1187389483.1161.102.camel@localhost.localdomain> <46C624D6.9030605@filteredperception.org> <46C6292E.6070409@filteredperception.org> Message-ID: <46C62B8C.3000702@gmail.com> Douglas, but wouldn't you better ask Max himself about it just to make everything clear? :) Regards, Vladimir Douglas McClendon ?????: > Douglas McClendon wrote: >> Matthias Clasen wrote: > >>> >>> Ah, then I did not misunderstand what you were trying to say. There is >>> no need to get prior approval to work on cool stuff in Fedora. And a lot >>> of the cool stuff in Fedora 8 will just show up without being on any >>> approved feature lists. >> >> Still, I think it would be nice if LiveCD Persistence was on official >> feature, benefiting from that status and the related process. > > Another reason why having LiveCD Persistence as an official feature is > quite important, is if it is already getting talked about as an official > feature. It's possible that in this quote, Max is just talking about > traditional installation to external usb drive, but it's also > possible(?) he is talking about livecd persistence (certainly adding > dm-crypt to the base and or overlay images is not hard). > > http://www.technetra.com/writings/archive/2007/07/01/face-to-face-with-max-spevack > > > " > Q: What is the vision for Fedora tomorrow? > > Max: The two biggest goals for Fedora 7 were the live CD/live DVD stuff > which was something Fedora needed in order to be able to compete at the > same level as other distributions. So we've got that. > > In Fedora 8 and 9, over the next year let's say, we want to make the > technology even better. For example, envision you take your whole > computer around on your USB key and you stick it into any laptop and > your desktop just appears. If you lose it, your data is encrypted, so > it's not as much of a catastrophe as it could be ? at least your bank > account is not all over the world. > " > > -dmc > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > From sundaram at fedoraproject.org Sat Aug 18 00:37:03 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 18 Aug 2007 06:07:03 +0530 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C61E91.8060308@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> <1187387029.1161.95.camel@localhost.localdomain> <46C61801.2050705@filteredperception.org> <1187387816.1161.98.camel@localhost.localdomain> <46C61E91.8060308@filteredperception.org> Message-ID: <46C63F2F.6000707@fedoraproject.org> Douglas McClendon wrote: > The issue is, that the current (or as of a couple weeks ago) CLA would > appear to give redhat the legal right to take works submitted under the > CLA-related channels, and then modify and redistribute them without the > GPL style restriction of requiring modifcations to be submitted back to > the original author. > > GDK and fedora legal seemed to agree that this was in fact the case, but > I have not yet heard back from GDK's reply which he also cc'd to Max. > > If those changes got 'committed' to the CLA to remove that (presumably > unintentional, but still unpalatable) loophole, then I would personally > sign the CLA, and submit the livecd persistence feature as a proposed > feature, such that it could make it into f8t2, as Jeremy clearly has in > mind. IANAL but I don't think it is a loophole. Assigning copyright to any entity would give the entity the ability to change the copyright licensing terms as suitable. For example, FSF requires a CLA which allows it to relicense GNU projects from GPLv2 to GPLv3 which isn't otherwise possible under the terms of the license. This has been useful for Fedora Project earlier when we changed the documentation licensing. If there is any requirement to do similar things later, we don't have to track every single contributor to do it. Rahul From phillip at lougher.demon.co.uk Sat Aug 18 03:18:14 2007 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Sat, 18 Aug 2007 04:18:14 +0100 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46C60CFF.3040107@filteredperception.org> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> Message-ID: <46C664F6.40101@lougher.demon.co.uk> Douglas McClendon wrote: > 20% speedup of reading data into /dev/null isn't all that useful. I could write an irritable comment here, but I won't rise to the bait :-) Writing to /dev/null factors out any overhead due to writing. Therefore any time improvements are purely down to sparse file reading, which is what my tests were aimed at measuring. You and anyone else are welcome to carry out any additional tests in 'real-life' scenarios, and I'll be interested in the results. > > You didn't really mention what you were planning on using it for. Personally I have very little use for sparse file handling. Sparse file handling is simply part of my on-going improvements to Squashfs. Correct sparse file handling has been one of my desired improvements for more than two years, but has always been postponed for other higher priority tasks. Having downloaded a Fedora liveCD and noticing it used sparse files, made me decide to bump the priority of adding sparse file handling to Squashfs. The announcement of a Fedora liveCD was interesting because for a long time Fedora was badly lacking this. I was pleased to discover it used Squashfs, not so pleased to discover it used sparse files. > Presumably you were also aware of my turboLiveInst patch, which > accomplishes the 20% speedup in an actual copy situation. I seem to have barged into an on-going argument. I read this thread about sparse file handling in Squashfs, and read about your turboLiveInst patch. It seems a clever and creative solution to the problem, but I am not really qualified to judge, having no involvement in the Fedora liveCD except insofar as I wrote Squashfs. In fact I only came across this thread during a search to see if anyone was complaining about the lack of sparse file support in Squashfs. > > For reasons that I can only speculate to, Jeremy, and everyone else > seems to have no interest in my turboLiveInst optimization approach. > Perhaps this method will be more palatable for them for some reason. Politics, not my cup of tea really. > > The other thing that I'm curious about, is the performance impact of > moving to 128kbyte blocks. I presume that is the compressed data size. > I would like to see if, in some typical usage scenarios, whether or not > that has a detrimental impact to desktop and general performance during > livecd oepration. (i.e. for every 5kb text file read, it needs to > uncompress 128Kb of compressed data, adding ram and latency penalties). > Yes, spot on. Larger blocks add greater latency and larger ram usage, but improve compression ratio. It is very much a trade-off between what a Squashfs filesystem user values greater. There is unfortunately no silver bullet here. The latency increases due to larger block sizes are somewhat muddied by fragment blocks in Squashfs. Fragment blocks pack multiple files smaller than a single block into one compressed block. Paradoxically, this can minimise seek time if the files in the fragment block are read at the same time. Once the first file is read from a fragment, subsequent file reads are immediately satisfied from the cached fragment rather than incurring additional seek overhead. If the files are sorted in the Squashfs filesystem according to first access time, then the larger block size will probably improve boot up speed for many liveCDs. In any case the move to larger block sizes is encouraged by compression algorithms other than gzip (cough LZMA), where significant compression improvements may be achieved. I have not undertaken any measurements of this because I pretend not to know about any compression algorithms other than gzip (politics again). > But the 3MB saved from the sparse support, is absolutely FREE. That is > positively excellent, and what I had suspected was the case. Also, I'm > guessing that the mksquashfs performance on a 4.0G sparse file with 2.0G > of data will be vastly improved. (by my definition of vast, i.e. ~10%) > Yes, mksquashfs runs a *lot* faster. Regards Phillip From dmc.fedora at filteredperception.org Sat Aug 18 08:02:28 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 18 Aug 2007 03:02:28 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46C664F6.40101@lougher.demon.co.uk> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> <46C664F6.40101@lougher.demon.co.uk> Message-ID: <46C6A794.8030705@filteredperception.org> Phillip Lougher wrote: > Douglas McClendon wrote: > >> 20% speedup of reading data into /dev/null isn't all that useful. > > I could write an irritable comment here, but I won't rise to the > bait :-) Sorry, I did not realize from your post that you were the squashfs author. I assumed you were a more run of the mill fedora livecd-tools/revisor user/developer. In the pure squashfs context, your test does make sense, as simple proof that basic sparse file support is there. Though given that false assumption above, and all the other context of your post, and my subsequent replies, you can see how I jumped to the false conclusion that somehow this was shaping up to be an alternate implementation of my turboLiveInst improvements. And clearly I harbor some political issues... It is cool how I can see that a/the squashfs developer could easily google/search for "squashfs sparse" in an attempt to see how desired the functionality is, and no doubt end up finding that specific post. Again, my apologies for the defensive response, and much more than that, my gratitude for the support. When you are trying to fit lots of cool stuff into 700MB, getting 3 more for free, really is nice. And another 9 (or cough more) with various trade-offs is also a very nice option. And then there are devicemapper-livecd freaks like myself, who will appreciate the ability to for free, use a 1T sparse file, so that devicemapper snapshot overlay storage space permitting, I can online resize2fs my root filesystem as high as I want, without having to do a hacky thing like create a linear devicemapper addition of the original small sparse file, and a fake devicemapper zero device (together forming the base of a dm-snapshot device). Finally, (for any spectators reading this far), what you mentioned about sorting by access time, is one of a few key factors I had in mind for drastically reducing livecd boot time. It's a bit trickier for fedora than for kubuntu, because of the ext3 image file versus native squashfs, but it should be doable. Regards, -dmc From lars.bjorndal at broadpark.no Sat Aug 18 09:46:51 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sat, 18 Aug 2007 11:46:51 +0200 Subject: [Fedora-livecd-list] Is it possible to use yum setup on build host? Message-ID: 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 From kanarip at kanarip.com Sat Aug 18 22:58:21 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 00:58:21 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070817095815.1a8cba29@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> Message-ID: <46C7798D.2010301@kanarip.com> Jesse Keating wrote: > On Fri, 17 Aug 2007 09:51:51 -0400 > Jesse Keating wrote: > >> Perhaps if yours works and mine doesn't has to do with whether or not >> the source repo was enabled initially or not. I'm going to play with >> that some. > > Yes that's it. Not a huge deal I can work with this. > Right so what I'm reading is that the code needs to forcibly disable (not enable) source repositories initially then only enable them in enable_source_repositories() or none of this works? That's a ticket ;-) [1] Kind regards, Jeroen van Meeuwen -kanarip [1] https://hosted.fedoraproject.org/projects/revisor/ticket/266 From jkeating at redhat.com Sun Aug 19 00:09:23 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 18 Aug 2007 20:09:23 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C7798D.2010301@kanarip.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> Message-ID: <20070818200923.30f45961@ender> On Sun, 19 Aug 2007 00:58:21 +0200 Jeroen van Meeuwen wrote: > Right so what I'm reading is that the code needs to forcibly disable > (not enable) source repositories initially then only enable them in > enable_source_repositories() or none of this works? > > That's a ticket ;-) [1] Yeah, sounds about right. The trick is going to be figuring out what repos are source repos and which aren't, since they can be named anything (and keeping in mind that currently pykickstart just takes repo as an argument, it doesn't have the concept of a source-repo yet. Maybe an RFE?). -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jsteer at bitscout.com Sun Aug 19 04:40:03 2007 From: jsteer at bitscout.com (Jon Steer) Date: Sun, 19 Aug 2007 00:40:03 -0400 Subject: [Fedora-livecd-list] LiveCD as Xen Guest, existence proof? Message-ID: <74e6f65d0708182140n65acede9n4905f728206040c1@mail.gmail.com> 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" From kanarip at kanarip.com Sun Aug 19 10:54:25 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 12:54:25 +0200 Subject: [Fedora-livecd-list] Is it possible to use yum setup on build host? In-Reply-To: References: Message-ID: <46C82161.7070503@kanarip.com> Lars Bj?rndal wrote: > 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. > If you want full-blown yum configuration file functionality you may need Revisor instead of livecd-tools, as not all yum configuration directives have a kickstart repo command equivalent, and livecd-tools only creates a yum config from these repo commands in kickstart, and the --repo cli parameters you pass it. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Sun Aug 19 11:11:46 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 13:11:46 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070818200923.30f45961@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> Message-ID: <46C82572.5090403@kanarip.com> Jesse Keating wrote: > On Sun, 19 Aug 2007 00:58:21 +0200 > Jeroen van Meeuwen wrote: > >> Right so what I'm reading is that the code needs to forcibly disable >> (not enable) source repositories initially then only enable them in >> enable_source_repositories() or none of this works? >> >> That's a ticket ;-) [1] > > Yeah, sounds about right. The trick is going to be figuring out what > repos are source repos and which aren't, since they can be named > anything (and keeping in mind that currently pykickstart just takes > repo as an argument, it doesn't have the concept of a source-repo yet. > Maybe an RFE?). > One of the things Revisor assumes when forcibly enabling source repositories is that we can just append "-source" to whatever other enabled (non-source) repository (using the 'id' of course). It somewhat makes sense to require to append -source to a repositories name to indicate it's the repositories source equivalent, doesn't it? Technically though, one would want to be able to distinct a source repo from a non-source repo as obviously like you said they could be named anything. This makes me wonder if we /really/ need some directive that says the repo is a source repo, or whether we could just figure it out on our own and do something intelligent with it. Like, we could initially only _getSacks for the RPM compat arch list (minus src). Then when we want source, _getSacks for the src arch. Maybe ;-) This however would require that the user enables the source repositories initially if he/she/it wants the sources to be pulled in, and we neglect that we could be better off by appending -source to indicate it's a source repo equivalent... I'm not sure what is the best way to go here; specify 'source' somewhere manually -which you do with appending -source to the repos id anyway-, or detect automatically -in which case you would want -source appended but you don't really need it. Any thoughts on this? Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sun Aug 19 11:32:28 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 19 Aug 2007 07:32:28 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C82572.5090403@kanarip.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> Message-ID: <20070819073228.38bdeb9f@ender> On Sun, 19 Aug 2007 13:11:46 +0200 Jeroen van Meeuwen wrote: > This makes me wonder if we /really/ need some directive that says the > repo is a source repo, or whether we could just figure it out on our > own and do something intelligent with it. Like, we could initially > only _getSacks for the RPM compat arch list (minus src). Then when we > want source, _getSacks for the src arch. Maybe ;-) This was my original plan, except I ran afoul of the inability to "reset" the yum object to be able to get the src arch sacks out of it. > > This however would require that the user enables the source > repositories initially if he/she/it wants the sources to be pulled > in, and we neglect that we could be better off by appending -source > to indicate it's a source repo equivalent... Well, in pungi at least, we just enable all repos forcefully. I imagine the same goes for the livecd-tools, and whatever else moves over to kickstart config systems. Any repo listed via 'repo' would automatically get enabled. > > I'm not sure what is the best way to go here; specify 'source' > somewhere manually -which you do with appending -source to the repos > id anyway-, or detect automatically -in which case you would want > -source appended but you don't really need it. > > Any thoughts on this? I'd like to talk to Chris Lumens and Jeremy Katz about the idea of a --source flag to the repo directive in pykickstart. This could store some info in the repo object that could alert pykickstart consumers that the repo in question is designed for source and thus we can deal with it correctly when we want the source vs the binary/noarch. This still requires the user creating the config specify that this repo is --source, but I don't think that this is too much to ask. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 19 12:06:26 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 14:06:26 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070819073228.38bdeb9f@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> Message-ID: <46C83242.4030600@kanarip.com> Jesse Keating wrote: > On Sun, 19 Aug 2007 13:11:46 +0200 > Jeroen van Meeuwen wrote: >> Any thoughts on this? > > I'd like to talk to Chris Lumens and Jeremy Katz about the idea of a > --source flag to the repo directive in pykickstart. This could store > some info in the repo object that could alert pykickstart consumers > that the repo in question is designed for source and thus we can deal > with it correctly when we want the source vs the binary/noarch. This > still requires the user creating the config specify that this repo is > --source, but I don't think that this is too much to ask. > For composing tools with just kickstart configuration, I guess yum plugins such as protectbase and fastestmirror are out-of-scope now, would it be worth something to keep these in mind nonetheless? (--protect?) Other directives such as includepkgs or exclude could become worthwhile at some point, too. Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sun Aug 19 12:02:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 19 Aug 2007 08:02:12 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070819073228.38bdeb9f@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> Message-ID: <20070819080212.76ef3edb@ender> On Sun, 19 Aug 2007 07:32:28 -0400 Jesse Keating wrote: > I'd like to talk to Chris Lumens and Jeremy Katz about the idea of a > --source flag to the repo directive in pykickstart. This could store > some info in the repo object that could alert pykickstart consumers > that the repo in question is designed for source and thus we can deal > with it correctly when we want the source vs the binary/noarch. This > still requires the user creating the config specify that this repo is > --source, but I don't think that this is too much to ask. I've sent a patch doing exactly this over to anaconda-list (couldn't think of a better place to send pykickstart patches). We'll see what comes of the discussion. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 19 12:12:02 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 14:12:02 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070819080212.76ef3edb@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> <20070819080212.76ef3edb@ender> Message-ID: <46C83392.4000807@kanarip.com> Jesse Keating wrote: > On Sun, 19 Aug 2007 07:32:28 -0400 > Jesse Keating wrote: > >> I'd like to talk to Chris Lumens and Jeremy Katz about the idea of a >> --source flag to the repo directive in pykickstart. This could store >> some info in the repo object that could alert pykickstart consumers >> that the repo in question is designed for source and thus we can deal >> with it correctly when we want the source vs the binary/noarch. This >> still requires the user creating the config specify that this repo is >> --source, but I don't think that this is too much to ask. > > I've sent a patch doing exactly this over to anaconda-list (couldn't > think of a better place to send pykickstart patches). We'll see what > comes of the discussion. > Maybe the appropriate list is kickstart-list ;-) I hope this comes through, advancing kickstart is a huge deal in all this (e.g. customizing). Thanks, Kind regards, Jeroen van Meeuwen -kanarip From jkeating at redhat.com Sun Aug 19 12:23:09 2007 From: jkeating at redhat.com (Jesse Keating) Date: Sun, 19 Aug 2007 08:23:09 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C83242.4030600@kanarip.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> <46C83242.4030600@kanarip.com> Message-ID: <20070819082309.1451b1c1@ender> On Sun, 19 Aug 2007 14:06:26 +0200 Jeroen van Meeuwen wrote: > For composing tools with just kickstart configuration, I guess yum > plugins such as protectbase and fastestmirror are out-of-scope now, > would it be worth something to keep these in mind nonetheless? > (--protect?) Other directives such as includepkgs or exclude could > become worthwhile at some point, too. Yes, there is value in extending the repo attributes in pykickstart. I've discussed it some with Chris, at least the idea of --exclude and --includepkgs and what they would actually mean in the grand scheme of figuring out the package set. He didn't seem greatly opposed, so long as we keep the semantics clear. As for plugins, that's a larger question to answer. We may need a plugin to accomplish multilib installs by default in say Fedora 9 as we're discussing taking multilib resolution out of the hands of the compose tools and putting it into the hands of the system actually installing packages so that said system can define what multilib strategy they wish to follow. So if this goes through, there would be some precedence for using yum plugins at install time. How this would be accomplished sanely and extendably I know not. A conversation for another day. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From kanarip at kanarip.com Sun Aug 19 12:34:45 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 19 Aug 2007 14:34:45 +0200 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070819082309.1451b1c1@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> <46C83242.4030600@kanarip.com> <20070819082309.1451b1c1@ender> Message-ID: <46C838E5.5080404@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Keating wrote: > On Sun, 19 Aug 2007 14:06:26 +0200 > Jeroen van Meeuwen wrote: > >> For composing tools with just kickstart configuration, I guess yum >> plugins such as protectbase and fastestmirror are out-of-scope now, >> would it be worth something to keep these in mind nonetheless? >> (--protect?) Other directives such as includepkgs or exclude could >> become worthwhile at some point, too. > > Yes, there is value in extending the repo attributes in pykickstart. > I've discussed it some with Chris, at least the idea of --exclude and > --includepkgs and what they would actually mean in the grand scheme of > figuring out the package set. He didn't seem greatly opposed, so long > as we keep the semantics clear. > > As for plugins, that's a larger question to answer. We may need a > plugin to accomplish multilib installs by default in say Fedora 9 as > we're discussing taking multilib resolution out of the hands of the > compose tools and putting it into the hands of the system actually > installing packages so that said system can define what multilib > strategy they wish to follow. So if this goes through, there would be > some precedence for using yum plugins at install time. How this would > be accomplished sanely and extendably I know not. A conversation for > another day. > F9 FUDCon here we come ;-) Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGyDjlKN6f2pNCvwgRAjCDAKC6l01ChfdG3u6wY9WJzgp7mzKwJQCg0XYw HeDeHKQ2CX5PR3Xqy6EIiN4= =q8m+ -----END PGP SIGNATURE----- From chitlesh at fedoraproject.org Sun Aug 19 20:33:59 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 19 Aug 2007 22:33:59 +0200 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy Message-ID: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> Hello there, As proposed on the -devel mailing list, I've started to work on a livecd for "Fedora Electronic Lab". Hopefully, Jeremy's support still stands. with livecd-creator, I created a livecd with a kickstart file based on /usr/share/livecd-tools/livedvd-fedora-kde.ks The kickstart file for FEL is http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks I had a livecd of 741.6MB which I'll strip later on to less that 700Mb. However, each time I created a livecd with this process: livecd-creator --config=/home/chitlesh/livecd-fedora-electronic-lab.ks \ --repo=fedora7,file:///home/chitlesh/Public/Fedora7 \ --repo=updates7,file:///home/chitlesh/Public/updates7 \ --fslabel=Fedora-Electronic-Lab on booting the livecd it fails on: [..] unmounting Unable to load SELinux Policy. Machines is in enforcing mode. Halting now. kernel panic: see http://chitlesh.fedorapeople.org/FEL/panic.png The diff of /usr/share/livecd-tools/livedvd-fedora-kde.ks and http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks is http://chitlesh.fedorapeople.org/FEL/diff I'm booting on vmware server and my mirrors: fedora7 and updates7 are a rsync of the official mirrors, but the repodata was created with : createrepo comps/comps-f8.xml.in to ensure groups are considered. What could be missing or done wrong in this process ? Chitlesh -- http://clunixchit.blogspot.com From dmc.fedora at filteredperception.org Mon Aug 20 10:17:05 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 05:17:05 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only Message-ID: <46C96A21.30305@filteredperception.org> 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 From dmc.fedora at filteredperception.org Mon Aug 20 10:18:38 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 05:18:38 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only Message-ID: <46C96A7E.30108@filteredperception.org> 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 From dmc.fedora at filteredperception.org Mon Aug 20 10:23:51 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 05:23:51 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only Message-ID: <46C96BB7.6030400@filteredperception.org> (I'm getting a sense of deja vu, that I'm learning the same lesson someone else recently learned here. Lets see if the 3rd time is the charm...) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-persistence-overlay-implementation-first-pass.patch Type: text/x-patch Size: 68381 bytes Desc: not available URL: From lars.bjorndal at broadpark.no Mon Aug 20 11:35:52 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Mon, 20 Aug 2007 13:35:52 +0200 Subject: [Fedora-livecd-list] Get an error message with Revisor Message-ID: 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 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 From kanarip at kanarip.com Mon Aug 20 11:55:01 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 20 Aug 2007 13:55:01 +0200 Subject: [Fedora-livecd-list] Get an error message with Revisor In-Reply-To: References: Message-ID: <46C98115.4010005@kanarip.com> Presumably this isn't the first time you run Revisor, and a previous run has failed in some way, so that it couldn't cleanup after itself. What version of Revisor are you using? We fixed this some time ago. Kind regards, Jeroen van Meeuwen -kanarip Lars Bj?rndal wrote: > 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 > 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 > From katzj at redhat.com Mon Aug 20 14:14:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:14:04 -0400 Subject: [Fedora-livecd-list] Is it possible to use yum setup on build host? In-Reply-To: References: Message-ID: <1187619244.7085.18.camel@localhost.localdomain> On Sat, 2007-08-18 at 11:46 +0200, Lars Bj?rndal wrote: > 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? Use of the repo commands is far preferable as it keeps things more self-contained so that the config can be later used to recreate your live image without someone having to know the exact state of other files on your system. That said, if someone wanted to write a little utility to parse the .repo files and spit out a set of repo lines, I can definitely see that being something useful and we could include it in livecd-creator > 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. As Jeroen alluded to, at present, there's no way to do includepkgs (or excludepkgs) on a per-repo basis. It's something that has come up from time to time, though, and I wouldn't be against extending the repo syntax to support it. The first step would be filing a bug against pykickstart (cc me) asking for pykickstart to support it. Once it goes in, I'll get livecd-creator using the syntax. Jeremy From katzj at redhat.com Mon Aug 20 14:15:43 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:15:43 -0400 Subject: [Fedora-livecd-list] LiveCD as Xen Guest, existence proof? In-Reply-To: <74e6f65d0708182140n65acede9n4905f728206040c1@mail.gmail.com> References: <74e6f65d0708182140n65acede9n4905f728206040c1@mail.gmail.com> Message-ID: <1187619343.7085.22.camel@localhost.localdomain> On Sun, 2007-08-19 at 00:40 -0400, Jon Steer wrote: > Has anyone managed to boot an F7 LiveCD as an F7 Xen Guest? > > I can boot an F6 LiveCD, but not F7. I suspect this is due to bugs in the IDE emulation of older qemu. Xen and VirtualBox both have forks of qemu included in their source trees. qemu < 0.9 has serious problems in its IDE emulation not being compliant with the specs, leading to it not working with the new libata-based drivers used in Fedora 7. Jeremy From katzj at redhat.com Mon Aug 20 14:50:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:50:45 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <46C83392.4000807@kanarip.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <46C82572.5090403@kanarip.com> <20070819073228.38bdeb9f@ender> <20070819080212.76ef3edb@ender> <46C83392.4000807@kanarip.com> Message-ID: <1187621445.7085.42.camel@localhost.localdomain> On Sun, 2007-08-19 at 14:12 +0200, Jeroen van Meeuwen wrote: > Jesse Keating wrote: > > I've sent a patch doing exactly this over to anaconda-list (couldn't > > think of a better place to send pykickstart patches). We'll see what > > comes of the discussion. > > > Maybe the appropriate list is kickstart-list ;-) I hope this comes > through, advancing kickstart is a huge deal in all this (e.g. customizing). kickstart-list tends to be more focused on use of kickstart (the file format) and not as much the devel side. anaconda-devel-list is as probably as good as anything for that Jeremy From katzj at redhat.com Mon Aug 20 14:51:54 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:51:54 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070818200923.30f45961@ender> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> Message-ID: <1187621514.7085.44.camel@localhost.localdomain> On Sat, 2007-08-18 at 20:09 -0400, Jesse Keating wrote: > On Sun, 19 Aug 2007 00:58:21 +0200 > Jeroen van Meeuwen wrote: > > > Right so what I'm reading is that the code needs to forcibly disable > > (not enable) source repositories initially then only enable them in > > enable_source_repositories() or none of this works? > > > > That's a ticket ;-) [1] > > Yeah, sounds about right. The trick is going to be figuring out what > repos are source repos and which aren't, since they can be named > anything (and keeping in mind that currently pykickstart just takes > repo as an argument, it doesn't have the concept of a source-repo yet. > Maybe an RFE?). My first question would be "why does it matter?" Why not just have more repos listed and if you're doing something with sources, you deal with the repos and have your arches set to src as opposed to "binary" arches. Sure, it's more metadata, but at the end, you're going to end up churning through it all anyway, so I don't know that it's that large of a cost really Jeremy From katzj at redhat.com Mon Aug 20 14:52:12 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:52:12 -0400 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46C60CFF.3040107@filteredperception.org> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> Message-ID: <1187621532.7085.46.camel@localhost.localdomain> On Fri, 2007-08-17 at 16:02 -0500, Douglas McClendon wrote: > Phillip Lougher wrote: > > Douglas McClendon-2 wrote: > >> Douglas McClendon wrote: > > > > Some stats based on the Fedora-8-Test-1-Live-i686.iso > > > > original squashfs.img 712495104 (681M) > > sparse squashfs.img 709820416 (678M) > > sparse squashfs.img with 128Kbyte blocks 700100608 (669M) > > > > So, the compressed 0s used to take up about 2.5 Mbytes. More significant is > > the data and seek time saving in not reading all these useless compressed > > 0s. > > > > time to do "dd if=os.img of=/dev/null" from CDROM > > > > original squashfs.img, 221 seconds > > sparse squashfs.img, 168 seconds > > sparse squashfs.img with 128byte blocks, 171 seconds > > > > on average about 20% speedup. > > 20% speedup of reading data into /dev/null isn't all that useful. > > You didn't really mention what you were planning on using it for. > Presumably you were also aware of my turboLiveInst patch, which > accomplishes the 20% speedup in an actual copy situation. > > The sparse support could be used, perhaps with more code being written > to support sparse copying to block devices with python, to gain the > performance enhancements of turboLiveInst in an alternate manner. I suspect that it can... > For reasons that I can only speculate to, Jeremy, and everyone else > seems to have no interest in my turboLiveInst optimization approach. > Perhaps this method will be more palatable for them for some reason. It's a bit more palatable because it's not playing tricks with device-mapper and instead makes things know about sparse files and deal with them as sparse files. Which then makes the solution more general and less dependent on knowing very very intimate details about how things are constructed. > This actually reopens the usefulness of the container-size option which > I had included with the first version of the cleanupDeleted patch. I.e. > now it is no penalty whatsoever to go with a much larger container size. > This will remove the need to perform ugly device-mapper-zero tricks to > expand the rootfs size at runtime, if you have enough memory in your > overlay device to support that. And assuming of course that either you > are using the turboLiveInst patch, or the alternate method described > above which requires a little more code to be written. The big question is what is trying to be enabled by it and what the user experience of taking advantage of it is. If it's something that you end up passing lots of kernel command line options for, then I don't know if the added complexity is worth it. If it's something that can be a benefit for all cases without requiring a lot of knowledge from the user, then maybe it is more useful. Jeremy From katzj at redhat.com Mon Aug 20 14:57:54 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 10:57:54 -0400 Subject: [Fedora-livecd-list] Re: livecd persistence In-Reply-To: <46C615B8.4010906@filteredperception.org> References: <1187383816.18195.34.camel@erebor.boston.redhat.com> <46C615B8.4010906@filteredperception.org> Message-ID: <1187621874.7085.55.camel@localhost.localdomain> On Fri, 2007-08-17 at 16:40 -0500, Douglas McClendon wrote: > 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. Comfort of reviewing isn't something to worry about -- I'm okay with device-mapper as appropriate, I just sometimes think that there are better approaches than always using it (eg, actually making it so that sparseness is understood, etc). > Also, I need to make sure that this asdas at redhat.com person doesn't have > useful persistence code, which I would be wasting my time duplicating if > not necessary. I haven't seen any code either... but if they have it, now's the time to get it out there. I'm planning on getting _something_ in for persistence this week. If there's more than one patch so that we can look at alternate approaches and pull together all of the best aspects of each, that's fine. If there's just one, then we can iterate and get it to a good place. > Lastly, wouldn't test2 require an approved feature? I've been holding > off myself due to no feedback regarding the attached mail There's not a feature on the table for it right now because I didn't feel it was something that could be committed to. We'll get the code ready and then can go forward with it being a more official feature with all the accompanying stuff that it entails. And I can drive that to avoid your CLA questions. Jeremy From katzj at redhat.com Mon Aug 20 15:00:16 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 11:00:16 -0400 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy In-Reply-To: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> References: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> Message-ID: <1187622016.7085.58.camel@localhost.localdomain> On Sun, 2007-08-19 at 22:33 +0200, Chitlesh GOORAH wrote: > As proposed on the -devel mailing list, I've started to work on a > livecd for "Fedora Electronic Lab". Hopefully, Jeremy's support still > stands. Yep! > with livecd-creator, I created a livecd with a kickstart file based on > /usr/share/livecd-tools/livedvd-fedora-kde.ks It looks like you have a config which specifies selinux --enforcing, but isn't including an SELinux policy. If I had to guess, this is because you don't have the @core group included. That's definitely something you're going to want. Arguably, livecd-creator should just implicitly include it much like anaconda does. If people agree, then I'll get that change in soon. Jeremy From katzj at redhat.com Mon Aug 20 15:10:21 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 11:10:21 -0400 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46C96BB7.6030400@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> Message-ID: <1187622621.7085.68.camel@localhost.localdomain> On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: > (I'm getting a sense of deja vu, that I'm learning the same lesson > someone else recently learned here. Lets see if the 3rd time is the > charm...) It looks like you're getting hit by what Colin was where the list is eating some attachments :-/ FWIW, the "best" way of sending patches directly from git is git-format-patch followed by git-send-email; I need to sit down and write up some simple docs for using git + livecd-creator and best practices. Where's that 36 hour day? ;-) I'll try to get access to the list admin page later and try to tweak stuff to avoid the problem later as I suspect it's that one of the default mailman settings blocks attachments that look like mail to avoid some of the WINMAIL.DAT crap. > 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. Since the patch isn't attached, I'll guess. This is still doing a file which is loopback mounted and then added to the dm device? > 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?) There's work on doing unionfs via fuse which could be interesting for that in the medium term. But I'm not sure how useful tarballs/unionfs are when we think about the user experience. If it's going to persist, we want changes to "persist" as soon as they're done, not after some set of stuff is done to apply them. > 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). This sounds good. > - I've included modified /etc/rc.d/init.d/halt and functions, to handle > getting things cleanly shutdown (which is VERY important) And can see about getting these integrated with the initscripts bits. Shouldn't be too bad to do > - 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. Let's make things simpler for the moment and just ignore ntfs. If we get things happy with ext3 and vfat, then we can start to think about ntfs. > - rudimentary testing of the choice selection when multiple possible > overlay images are detected suggests it works. Cool. Jeremy From jkeating at redhat.com Mon Aug 20 15:22:47 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 11:22:47 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <1187621514.7085.44.camel@localhost.localdomain> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <1187621514.7085.44.camel@localhost.localdomain> Message-ID: <20070820112247.19685d1b@mentok.boston.redhat.com> On Mon, 20 Aug 2007 10:51:54 -0400 Jeremy Katz wrote: > My first question would be "why does it matter?" Why not just have > more repos listed and if you're doing something with sources, you > deal with the repos and have your arches set to src as opposed to > "binary" arches. Sure, it's more metadata, but at the end, you're > going to end up churning through it all anyway, so I don't know that > it's that large of a cost really Right now? Because yum throws out anything that doesn't match the compat arch list when getting package listings. So you get your package listings from your enabled repos, and it throws out all the source. There doesn't seem to be a good way to 'reset' the object to allow you to bring back in the source packages. Now you're going to say "fix it in yum instead" and that's fine, that's a reasonable answer. May not be an easy task either. We could make it not throw out those packages and make consumers of _getSacks do the filtering on their own. We could try to get yum objects to be able to 'reset' themselves. We can do the somewhat status quo of Pungi and just create a new yum object, add all the repos again, and do a _getSacks where the archlist is 'src'. Not sure what the best strategy is. I suppose "working around" it in pykickstart isn't the best. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Mon Aug 20 15:26:18 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 11:26:18 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <20070820112247.19685d1b@mentok.boston.redhat.com> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <1187621514.7085.44.camel@localhost.localdomain> <20070820112247.19685d1b@mentok.boston.redhat.com> Message-ID: <1187623578.7085.79.camel@localhost.localdomain> On Mon, 2007-08-20 at 11:22 -0400, Jesse Keating wrote: > On Mon, 20 Aug 2007 10:51:54 -0400 > Jeremy Katz wrote: > > My first question would be "why does it matter?" Why not just have > > more repos listed and if you're doing something with sources, you > > deal with the repos and have your arches set to src as opposed to > > "binary" arches. Sure, it's more metadata, but at the end, you're > > going to end up churning through it all anyway, so I don't know that > > it's that large of a cost really > > Right now? Because yum throws out anything that doesn't match the > compat arch list when getting package listings. So you get your > package listings from your enabled repos, and it throws out all the > source. There doesn't seem to be a good way to 'reset' the object to > allow you to bring back in the source packages. If you know you're going to be using sources initially, you could include src in your arch list. And then do filtering later. > Now you're going to say "fix it in yum instead" and that's fine, that's > a reasonable answer. May not be an easy task either. > > We could make it not throw out those packages and make consumers of > _getSacks do the filtering on their own. This seems like it's probably the best approach just from 2 seconds worth of thinking about it. > We could try to get yum objects to be able to 'reset' themselves. How is a reset different, though, than just creating a new object? > We can do the somewhat status quo of Pungi and just create a new yum > object, add all the repos again, and do a _getSacks where the archlist > is 'src'. > > Not sure what the best strategy is. I suppose "working around" it in > pykickstart isn't the best. Yeah, it just feels like it's enforcing things which really don't make a difference for the end-user Jeremy From jkeating at redhat.com Mon Aug 20 15:39:52 2007 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Aug 2007 11:39:52 -0400 Subject: [Fedora-livecd-list] SRPMS for installed RPMs? In-Reply-To: <1187623578.7085.79.camel@localhost.localdomain> References: <20070814031110.GC24149@auslistsprd01.us.dell.com> <1187102060.22509.4.camel@localhost.localdomain> <20070815100750.2ec2e54c@mentok.boston.redhat.com> <46C31270.6090209@kanarip.com> <20070815111312.1b370537@mentok.boston.redhat.com> <20070817095151.6c617c70@ender> <20070817095815.1a8cba29@ender> <46C7798D.2010301@kanarip.com> <20070818200923.30f45961@ender> <1187621514.7085.44.camel@localhost.localdomain> <20070820112247.19685d1b@mentok.boston.redhat.com> <1187623578.7085.79.camel@localhost.localdomain> Message-ID: <20070820113952.7502d4a4@mentok.boston.redhat.com> On Mon, 20 Aug 2007 11:26:18 -0400 Jeremy Katz wrote: > If you know you're going to be using sources initially, you could > include src in your arch list. And then do filtering later. > > > Now you're going to say "fix it in yum instead" and that's fine, > > that's a reasonable answer. May not be an easy task either. > > > > We could make it not throw out those packages and make consumers of > > _getSacks do the filtering on their own. > > This seems like it's probably the best approach just from 2 seconds > worth of thinking about it. Which now that I think about it gets us back up to suggestion #1. > > We could try to get yum objects to be able to 'reset' themselves. > > How is a reset different, though, than just creating a new object? Well you don't have to feed it all the config stuff over again, don't have to build up the logging system, don't have to re-add all the repos and such. It's a time and memory savor. I'm going to play with just adding 'src' to my arch list and doing my own filtering for a bit. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sundaram at fedoraproject.org Mon Aug 20 15:58:33 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 20 Aug 2007 21:28:33 +0530 Subject: [Fedora-livecd-list] [Fwd: RE : Persistancy in livecd achieved [Patch attached]] Message-ID: <46C9BA29.9060906@fedoraproject.org> 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 -------------- next part -------------- An embedded message was scrubbed... From: sachin Subject: RE : Persistancy in livecd achieved [Patch attached] Date: Fri, 20 Jul 2007 12:14:30 +0530 Size: 5707 URL: From katzj at redhat.com Mon Aug 20 18:24:02 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Aug 2007 14:24:02 -0400 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <1187622621.7085.68.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> Message-ID: <1187634242.7085.118.camel@localhost.localdomain> On Mon, 2007-08-20 at 11:10 -0400, Jeremy Katz wrote: > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: > > (I'm getting a sense of deja vu, that I'm learning the same lesson > > someone else recently learned here. Lets see if the 3rd time is the > > charm...) > > It looks like you're getting hit by what Colin was where the list is > eating some attachments :-/ This should hopefully be fixed now. We'll find out the next time someone tries :-) Jeremy From jsteer at bitscout.com Mon Aug 20 18:47:36 2007 From: jsteer at bitscout.com (Jon Steer) Date: Mon, 20 Aug 2007 14:47:36 -0400 Subject: [Fedora-livecd-list] LiveCD as Xen Guest, existence proof? In-Reply-To: <1187619343.7085.22.camel@localhost.localdomain> References: <74e6f65d0708182140n65acede9n4905f728206040c1@mail.gmail.com> <1187619343.7085.22.camel@localhost.localdomain> Message-ID: <74e6f65d0708201147v638a7a08h1f663560bc63f96a@mail.gmail.com> So, what VM do you test under? At the moment, I can boot an F7 LiveCD under VirtualBox, but not under Fedora7/Xen or Microsoft Virtual Server SP1 thanks, On 8/20/07, Jeremy Katz wrote: > On Sun, 2007-08-19 at 00:40 -0400, Jon Steer wrote: > > Has anyone managed to boot an F7 LiveCD as an F7 Xen Guest? > > > > I can boot an F6 LiveCD, but not F7. > > I suspect this is due to bugs in the IDE emulation of older qemu. Xen > and VirtualBox both have forks of qemu included in their source trees. > qemu < 0.9 has serious problems in its IDE emulation not being compliant > with the specs, leading to it not working with the new libata-based > drivers used in Fedora 7. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Whereever you go, there you are" From dmc.fedora at filteredperception.org Mon Aug 20 18:59:43 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 13:59:43 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <1187621532.7085.46.camel@localhost.localdomain> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> <1187621532.7085.46.camel@localhost.localdomain> Message-ID: <46C9E49F.6020705@filteredperception.org> Jeremy Katz wrote: > On Fri, 2007-08-17 at 16:02 -0500, Douglas McClendon wrote: >> Phillip Lougher wrote: >>> Douglas McClendon-2 wrote: >>>> Douglas McClendon wrote: >>> Some stats based on the Fedora-8-Test-1-Live-i686.iso >>> >>> original squashfs.img 712495104 (681M) >>> sparse squashfs.img 709820416 (678M) >>> sparse squashfs.img with 128Kbyte blocks 700100608 (669M) >>> >>> So, the compressed 0s used to take up about 2.5 Mbytes. More significant is >>> the data and seek time saving in not reading all these useless compressed >>> 0s. >>> >>> time to do "dd if=os.img of=/dev/null" from CDROM >>> >>> original squashfs.img, 221 seconds >>> sparse squashfs.img, 168 seconds >>> sparse squashfs.img with 128byte blocks, 171 seconds >>> >>> on average about 20% speedup. >> 20% speedup of reading data into /dev/null isn't all that useful. >> >> You didn't really mention what you were planning on using it for. >> Presumably you were also aware of my turboLiveInst patch, which >> accomplishes the 20% speedup in an actual copy situation. >> >> The sparse support could be used, perhaps with more code being written >> to support sparse copying to block devices with python, to gain the >> performance enhancements of turboLiveInst in an alternate manner. > > I suspect that it can... It can, but it doesn't solve the 2.1G->4.0G problem, which as mentioned, also scales if you want a +10G filesystem rather than +2G filesystem. (my prior statement using the word container could lead to confusion, as I meant filesystem). > >> For reasons that I can only speculate to, Jeremy, and everyone else >> seems to have no interest in my turboLiveInst optimization approach. >> Perhaps this method will be more palatable for them for some reason. > > It's a bit more palatable because it's not playing tricks with > device-mapper and instead makes things know about sparse files and deal > with them as sparse files. Which then makes the solution more general > and less dependent on knowing very very intimate details about how > things are constructed. Sorry, but I call bullshit. The 'tricks' here, are an elegant solution to more aspects of the problem than the alternate solution. It does not make the solution more general in any way whatsoever. The turboLiveInst solution is not "dependent on knowing very intimate details about how things are constructed". If by that statement you mean that people who read the code need to understand the very basic infrastructure of how the fedora livecd uses an ext3 image and a devicemapper snapshot to boot, and install from, then that is a GOOD thing. The fact that just about nobody other than myself and davidz understands that well, is why the livecd wiping the root partition bug slipped through the cracks. I will not argue this any further, but my stance remains that the turboLiveInst patch, is a _simple_ _elegant_ solution that fixes _more_ of the problem than an alternate sparse copy fix. > >> This actually reopens the usefulness of the container-size option which >> I had included with the first version of the cleanupDeleted patch. I.e. >> now it is no penalty whatsoever to go with a much larger container size. >> This will remove the need to perform ugly device-mapper-zero tricks to >> expand the rootfs size at runtime, if you have enough memory in your >> overlay device to support that. And assuming of course that either you >> are using the turboLiveInst patch, or the alternate method described >> above which requires a little more code to be written. > > The big question is what is trying to be enabled by it and what the user > experience of taking advantage of it is. If it's something that you end > up passing lots of kernel command line options for, then I don't know if > the added complexity is worth it. Jeremy, you have this habit of throwing replies to my strategies, clearly before you understand them. (see prior unanswered response regarding program= and eprogram= parameters to mayflower generated init). In this case (hoping I didn't confuse the issue by bringing up kernel parameters), there are NO KERNEL PARAMETERS involved. Not with turboLiveInst, nor with the larger container size. I mean, where did that come from, bringing that into this conversation? If it's something that can be a > benefit for all cases without requiring a lot of knowledge from the > user, then maybe it is more useful. I believe that sums up my attitude towards both turboLiveInst, and the larger container size feature. Both are benefits for all cases, and require *NO* knowledge from the user. -dmc From dmc.fedora at filteredperception.org Mon Aug 20 19:10:24 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 14:10:24 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <1187622621.7085.68.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> Message-ID: <46C9E720.3060705@filteredperception.org> Jeremy Katz wrote: > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: >> (I'm getting a sense of deja vu, that I'm learning the same lesson >> someone else recently learned here. Lets see if the 3rd time is the >> charm...) > > It looks like you're getting hit by what Colin was where the list is > eating some attachments :-/ FWIW, the "best" way of sending patches > directly from git is git-format-patch followed by git-send-email; I need > to sit down and write up some simple docs for using git + livecd-creator > and best practices. Where's that 36 hour day? ;-) > > I'll try to get access to the list admin page later and try to tweak > stuff to avoid the problem later as I suspect it's that one of the > default mailman settings blocks attachments that look like mail to avoid > some of the WINMAIL.DAT crap. Hmm... The 3rd time did appear to be the charm for me. Perhaps your email client is eating a broader class of attachments than the list itself. To see the patch, see the archive link of the post you replied to- https://www.redhat.com/archives/fedora-livecd-list/2007-August/msg00168.html > >> 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. > > Since the patch isn't attached, I'll guess. This is still doing a file > which is loopback mounted and then added to the dm device? > correct. >> 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?) > > There's work on doing unionfs via fuse which could be interesting for > that in the medium term. But I'm not sure how useful tarballs/unionfs > are when we think about the user experience. If it's going to persist, > we want changes to "persist" as soon as they're done, not after some set > of stuff is done to apply them. Well, the way ubuntu is trying to do it of course, is with unionfs (since of course they use unionfs rather than dm-snapshot to get cow in the first place). And as such, unionfs can provide just as persistful an implementation as the direction I've been going. In both cases you can think of the persistence as another embedded layer in the total root filesystem. > >> 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). > > This sounds good. > >> - I've included modified /etc/rc.d/init.d/halt and functions, to handle >> getting things cleanly shutdown (which is VERY important) > > And can see about getting these integrated with the initscripts bits. > Shouldn't be too bad to do > >> - 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. > > Let's make things simpler for the moment and just ignore ntfs. If we > get things happy with ext3 and vfat, then we can start to think about > ntfs. I was ignoring ntfs, though not enough to remove the stuff that could support it. -dmc > >> - rudimentary testing of the choice selection when multiple possible >> overlay images are detected suggests it works. > > Cool. > > Jeremy > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Mon Aug 20 19:25:11 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 14:25:11 -0500 Subject: [Fedora-livecd-list] [Fwd: RE : Persistancy in livecd achieved [Patch attached]] In-Reply-To: <46C9BA29.9060906@fedoraproject.org> References: <46C9BA29.9060906@fedoraproject.org> Message-ID: <46C9EA97.40906@filteredperception.org> Rahul Sundaram wrote: > 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. > No doubt you meant 'might *not* have reached the list before'. I didn't see it in my mailbox, or the www.redhat.com/mailmain/listinfo/fedora-livecd-list archives. And it appears that this thinclient-devel-list is another list that hasn't found its way to the www.redhat.com/mailman/listinfo list of lists. (and doesn't seem to have 'hidden' but accessible archives when I tried appending to listinfo/ as works with fedora-livecd-list). -dmc > Rahul > > ------------------------------------------------------------------------ > > Subject: > RE : Persistancy in livecd achieved [Patch attached] > From: > sachin > Date: > Fri, 20 Jul 2007 12:14:30 +0530 > To: > fedora-livecd-list at redhat.com > > To: > fedora-livecd-list at redhat.com > CC: > katzj at redhat.com, thinclient-devel-list at redhat.com > > > Hi all, > > As last time said, ashok and me achieved Persistancy in LiveCD and > here is the patch to mayflower. > > We tested this patch with pilgrim and working fine for us. > > regards, > SachinT > > > ------------------------------------------------------------------------ > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Mon Aug 20 20:12:25 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 15:12:25 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <1187621532.7085.46.camel@localhost.localdomain> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> <1187621532.7085.46.camel@localhost.localdomain> Message-ID: <46C9F5A9.6030801@filteredperception.org> Jeremy Katz wrote: > On Fri, 2007-08-17 at 16:02 -0500, Douglas McClendon wrote: >> Phillip Lougher wrote: >>> Douglas McClendon-2 wrote: >>>> Douglas McClendon wrote: >>> Some stats based on the Fedora-8-Test-1-Live-i686.iso >>> >>> original squashfs.img 712495104 (681M) >>> sparse squashfs.img 709820416 (678M) >>> sparse squashfs.img with 128Kbyte blocks 700100608 (669M) >>> >>> So, the compressed 0s used to take up about 2.5 Mbytes. More significant is >>> the data and seek time saving in not reading all these useless compressed >>> 0s. >>> >>> time to do "dd if=os.img of=/dev/null" from CDROM >>> >>> original squashfs.img, 221 seconds >>> sparse squashfs.img, 168 seconds >>> sparse squashfs.img with 128byte blocks, 171 seconds >>> >>> on average about 20% speedup. >> 20% speedup of reading data into /dev/null isn't all that useful. >> >> You didn't really mention what you were planning on using it for. >> Presumably you were also aware of my turboLiveInst patch, which >> accomplishes the 20% speedup in an actual copy situation. >> >> The sparse support could be used, perhaps with more code being written >> to support sparse copying to block devices with python, to gain the >> performance enhancements of turboLiveInst in an alternate manner. > > I suspect that it can... > >> For reasons that I can only speculate to, Jeremy, and everyone else >> seems to have no interest in my turboLiveInst optimization approach. >> Perhaps this method will be more palatable for them for some reason. > > It's a bit more palatable because it's not playing tricks with > device-mapper and instead makes things know about sparse files and deal > with them as sparse files. "not playing tricks?!?!". Have you been smoking crack? Tell me how implementing a new procedure, that involves copying a sparse file, but letting the destination have data preserved where the data in the sparse file is zeros, is any less "playing tricks" than the proven code I've already presented? I would argue that it is playing *more* tricks. Do you really want to get developers in the mindset that the _appropriate_ behavior for a sparse copy is to have the destination retain data, instead of having the destination match the source? > Which then makes the solution more general Again- yer wrong. Sorry there is no more diplomatic way to put it. But that statement is completely, utterly, wrong. Name one specific way that makes the as-yet-to-be-written 'fake sparse copy' solution more general than the already-written-and-tested turboLiveInst solution? Name just one way. -dmc From dmc.fedora at filteredperception.org Mon Aug 20 22:26:19 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 17:26:19 -0500 Subject: [Fedora-livecd-list] my livecd-tools git notes In-Reply-To: <1187622621.7085.68.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> Message-ID: <46CA150B.9060109@filteredperception.org> Jeremy Katz wrote: > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: >> (I'm getting a sense of deja vu, that I'm learning the same lesson >> someone else recently learned here. Lets see if the 3rd time is the >> charm...) > > It looks like you're getting hit by what Colin was where the list is > eating some attachments :-/ FWIW, the "best" way of sending patches > directly from git is git-format-patch followed by git-send-email; I need > to sit down and write up some simple docs for using git + livecd-creator > and best practices. Where's that 36 hour day? ;-) While I may use git-send-email someday, for the moment I prefer attaching the patch manually to a thunderbird composed email. What I did to get the 3rd one through, was to manually delete the 4 email header style lines from the git-format-patch patch (which I then verified is still a validly apply-able patch syntax). Anyway, FWIW, here are the notes I made to myself while learning the second minimal level of git functionality. Obviously no need for a livecd-tools rehash of the fine git tutorials and docs already available. Or at least not for anything much more complicated than what is attached. -dmc -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gitnotes.txt URL: From dmc.fedora at filteredperception.org Tue Aug 21 02:21:28 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 20 Aug 2007 21:21:28 -0500 Subject: [Fedora-livecd-list] installer efficiency - sparse hackery Message-ID: <46CA4C28.3040807@filteredperception.org> 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 From cha.gascon at gmail.com Tue Aug 21 03:31:29 2007 From: cha.gascon at gmail.com (Cha Gascon) Date: Tue, 21 Aug 2007 11:31:29 +0800 Subject: [Fedora-livecd-list] Adding files into the CD root file system In-Reply-To: <4684AE1B.10204@asic.udl.cat> References: <4680B602.3090405@asic.udl.cat> <1183057830.6629.1.camel@erebor.boston.redhat.com> <4684AE1B.10204@asic.udl.cat> Message-ID: The --add-extra-files feature proved useful for me. I use it to include a writable home directory symlinked to the actual home dir. Any way --add-extra-files can be included? Or have the %post --nochroot thing is also good, with PWD as /var/tmp/livecd-creator-XXXXXX/ ? =) On 6/29/07, Alexandre Magaz Gra?a wrote: > > Jeremy Katz escribi?: > > On Tue, 2007-06-26 at 08:45 +0200, Alexandre Magaz Gra?a wrote: > >> 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. > > > > While this is useful, more generally, you may want to add other > > directories as well. Or be able to modify the bootloader config. So I > > wonder if more accurately what's wanted is really implementing > > --nochroot for %post from the config. That way, you could do whatever > > you want. > > > > The reason against is that it's kind of scary to let an unchroot'd > > script run when creating live CDs as the config may or may not be > > trustable. > > > > Jeremy > > > > Well, you really can add as many directories as you want. You get the > contents of the directory into the root, not the directory itself. So if > you specify --add-extra-files dir and the contents of dir are a single > file named help.html, you get something like this: > > / > |-- sysroot > |-- isolinux > | |-- boot.cat > | |-- initrd.img > | |-- isolinux.bin > | |-- isolinux.cfg > | |-- splash.jpg > | |-- vesamenu.c32 > | `-- vmlinuz > |-- help.html > [...] > > instead of this other > > / > |-- sysroot > |-- isolinux > | |-- boot.cat > | |-- initrd.img > | |-- isolinux.bin > | |-- isolinux.cfg > | |-- splash.jpg > | |-- vesamenu.c32 > | `-- vmlinuz > |-- dir > | `-- help.html > [...] > > So, you only have to put directories inside dir. But yes, it doesn't > solves the boot loader problem and others :( > > Cheers, > ?lex > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- Marie Charisse L. Gascon http://www.chasys.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From phillip at lougher.demon.co.uk Tue Aug 21 11:20:33 2007 From: phillip at lougher.demon.co.uk (Phillip Lougher) Date: Tue, 21 Aug 2007 12:20:33 +0100 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46C6A794.8030705@filteredperception.org> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> <46C664F6.40101@lougher.demon.co.uk> <46C6A794.8030705@filteredperception.org> Message-ID: <46CACA81.6000007@lougher.demon.co.uk> Douglas McClendon wrote: > > Again, my apologies for the defensive response, and much more than that, > my gratitude for the support. When you are trying to fit lots of cool > stuff into 700MB, getting 3 more for free, really is nice. And another > 9 (or cough more) with various trade-offs is also a very nice option. > No problem. Thanks for your comments. > > Finally, (for any spectators reading this far), what you mentioned about > sorting by access time, is one of a few key factors I had in mind for > drastically reducing livecd boot time. It's a bit trickier for fedora > than for kubuntu, because of the ext3 image file versus native squashfs, > but it should be doable. > Yes. Another idea which I'm in the process of adding to Squashfs is selective metadata prefetch. Currently even with file sorting, you still experience some disk head seeking when inode and directory information is read. If on filesystem mount some or all of the metadata was prefetched this would minimise seek time. Regards Phillip From ml at deadbabylon.de Tue Aug 21 13:49:11 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 21 Aug 2007 15:49:11 +0200 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <1187291798.637.9.camel@localhost.localdomain> References: <200708161956.14112.ml@deadbabylon.de> <200708162010.33158.ml@deadbabylon.de> <1187291798.637.9.camel@localhost.localdomain> Message-ID: <200708211549.18715.ml@deadbabylon.de> Am Do 16.August 2007 schrieb Jeremy Katz: > On Thu, 2007-08-16 at 20:10 +0200, Sebastian Vahl wrote: > > Am Do 16.August 2007 schrieb Jeremy Katz: > > > On Thu, 2007-08-16 at 19:56 +0200, Sebastian Vahl wrote: > > > > Is there a way to remove a group which is defined in the first config > > > > (here livecd-config-base-desktop.ks) in the second config (here > > > > livecd-fedora-kde.ks)? > > > > > > There's not really syntax for removing groups at present. Given the > > > things causing you problems, you could just do > > > -kde-i18n* > > > -koffice-langpack* > > > like has been done in the past for a few things. > > > > I don't know why but this is not working. I could remove eg. gnome-games > > but kde-i18n-* and koffice-langpack-* would anyway be installed. > > Oh, ugh. I know why this doesn't work. /me stabs conditionals in comps > a thousand times. > > > > Alternately, we could move the lang-support groups into desktop instead > > > of -base-desktop > > > > ATM I would think that's the best option. > > Okay, will move them over later unless you beat me to it :) I've committed my changes to livecd-fedora-kde.ks. So I think, livecd-fedora-base-desktop.ks should also be changed. :) Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From katzj at redhat.com Tue Aug 21 19:36:48 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Aug 2007 15:36:48 -0400 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46C9E720.3060705@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46C9E720.3060705@filteredperception.org> Message-ID: <1187725008.4781.25.camel@localhost.localdomain> On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote: > Jeremy Katz wrote: > > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: > >> (I'm getting a sense of deja vu, that I'm learning the same lesson > >> someone else recently learned here. Lets see if the 3rd time is the > >> charm...) > > > > It looks like you're getting hit by what Colin was where the list is > > eating some attachments :-/ FWIW, the "best" way of sending patches > > directly from git is git-format-patch followed by git-send-email; I need > > to sit down and write up some simple docs for using git + livecd-creator > > and best practices. Where's that 36 hour day? ;-) > > > > I'll try to get access to the list admin page later and try to tweak > > stuff to avoid the problem later as I suspect it's that one of the > > default mailman settings blocks attachments that look like mail to avoid > > some of the WINMAIL.DAT crap. > > Hmm... The 3rd time did appear to be the charm for me. Perhaps your > email client is eating a broader class of attachments than the list > itself. To see the patch, see the archive link of the post you replied to- > > https://www.redhat.com/archives/fedora-livecd-list/2007-August/msg00168.html Weird. In any case, I'm also now an admin for the list, and like I said, I've _hopefully_ adjusted things so they should work anyway. We'll see I guess. And review coming up from looking at the patch next... > >> 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?) > > > > There's work on doing unionfs via fuse which could be interesting for > > that in the medium term. But I'm not sure how useful tarballs/unionfs > > are when we think about the user experience. If it's going to persist, > > we want changes to "persist" as soon as they're done, not after some set > > of stuff is done to apply them. > > Well, the way ubuntu is trying to do it of course, is with unionfs > (since of course they use unionfs rather than dm-snapshot to get cow in > the first place). > > And as such, unionfs can provide just as persistful an implementation as > the direction I've been going. In both cases you can think of the > persistence as another embedded layer in the total root filesystem. It's been quite a while since I looked at unionfs, but I vaguely remember that it was more subtree overlays. I guess you could perhaps do a subtree of /. But even so, I don't know that supporting multiple ways of achieving the same goal is really where we want to go. But it's somewhat academic at the moment, so probably not much discussion needed. > > Let's make things simpler for the moment and just ignore ntfs. If we > > get things happy with ext3 and vfat, then we can start to think about > > ntfs. > > I was ignoring ntfs, though not enough to remove the stuff that could > support it. I say let's just pull it. If it doesn't work right now, we might as well save the effort of testing it and/or someone trying it, finding it doesn't work, and filing a bug. Plus, it then makes the changes clearer for looking at. Jeremy From katzj at redhat.com Tue Aug 21 19:36:49 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Aug 2007 15:36:49 -0400 Subject: [Fedora-livecd-list] How to remove groups in second config? In-Reply-To: <200708211549.18715.ml@deadbabylon.de> References: <200708161956.14112.ml@deadbabylon.de> <200708162010.33158.ml@deadbabylon.de> <1187291798.637.9.camel@localhost.localdomain> <200708211549.18715.ml@deadbabylon.de> Message-ID: <1187725009.4781.27.camel@localhost.localdomain> On Tue, 2007-08-21 at 15:49 +0200, Sebastian Vahl wrote: > Am Do 16.August 2007 schrieb Jeremy Katz: > > On Thu, 2007-08-16 at 20:10 +0200, Sebastian Vahl wrote: > > > Am Do 16.August 2007 schrieb Jeremy Katz: > > > > Alternately, we could move the lang-support groups into desktop instead > > > > of -base-desktop > > > > > > ATM I would think that's the best option. > > > > Okay, will move them over later unless you beat me to it :) > > I've committed my changes to livecd-fedora-kde.ks. So I think, > livecd-fedora-base-desktop.ks should also be changed. :) And committed moving the groups. Thanks Jeremy From katzj at redhat.com Tue Aug 21 19:41:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Aug 2007 15:41:45 -0400 Subject: [Fedora-livecd-list] my livecd-tools git notes In-Reply-To: <46CA150B.9060109@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46CA150B.9060109@filteredperception.org> Message-ID: <1187725305.4781.31.camel@localhost.localdomain> On Mon, 2007-08-20 at 17:26 -0500, Douglas McClendon wrote: > Anyway, FWIW, here are the notes I made to myself while learning the > second minimal level of git functionality. Obviously no need for a > livecd-tools rehash of the fine git tutorials and docs already > available. Or at least not for anything much more complicated than > what is attached. One little addition for anyone else who might be in the same boat. > # set identity (commit complains if not set) > git config user.email "dmc at filteredperception.org" > git config user.name "Douglas McClendon" You can use "git config --global" to set this globally and not have to do so on a per-project basis. Jeremy From dmc.fedora at filteredperception.org Tue Aug 21 20:04:22 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 21 Aug 2007 15:04:22 -0500 Subject: [Fedora-livecd-list] [PATCH] cleanupDeleted and container_size - saves 5.5% output size on f7livecd-i686 In-Reply-To: <46CACA81.6000007@lougher.demon.co.uk> References: <469EDD1D.7060908@filteredperception.org> <46A27A42.2040900@filteredperception.org> <12205702.post@talk.nabble.com> <46C60CFF.3040107@filteredperception.org> <46C664F6.40101@lougher.demon.co.uk> <46C6A794.8030705@filteredperception.org> <46CACA81.6000007@lougher.demon.co.uk> Message-ID: <46CB4546.1000105@filteredperception.org> Phillip Lougher wrote: > Douglas McClendon wrote: > >> >> Finally, (for any spectators reading this far), what you mentioned >> about sorting by access time, is one of a few key factors I had in >> mind for drastically reducing livecd boot time. It's a bit trickier >> for fedora than for kubuntu, because of the ext3 image file versus >> native squashfs, but it should be doable. >> > > Yes. Another idea which I'm in the process of adding to Squashfs is > selective metadata prefetch. Currently even with file sorting, you > still experience some disk head seeking when inode and directory > information is read. If on filesystem mount some or all of the > metadata was prefetched this would minimise seek time. Why stop at metadata ;) :) :) :) I really love device mapper. -dmc From katzj at redhat.com Tue Aug 21 20:18:50 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 21 Aug 2007 16:18:50 -0400 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46C96BB7.6030400@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> Message-ID: <1187727530.4781.63.camel@localhost.localdomain> On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: > 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. Couple of little things just to make reviewing easier, but not huge problems * Might be good to keep the initscripts changes as patches rather than an orig and a modified version. Will make things work even if other things in initscripts change and also makes it easier to know what's going on. * It's good to get into the habit of doing git commits for each separate change. Then you can get a patch per change. And that would avoid having the addidir/addsdir stuff being in the same changes Now to get to the meat of things index 0000000..8962720 --- /dev/null +++ b/creator/etc_rc.d_init.d_functions I suspect that Bill might have some reservations about the hard-coded overlayfs piece. At the same time, it's all I can think of and it's not that out of line from other things in halt/rc.sysinit. For the overlay info bit, we could potentially just stuff it in /sbin/halt.local for now I think. diff --git a/creator/findoverlay b/creator/findoverlay new file mode 100755 index 0000000..e0674cc --- /dev/null +++ b/creator/findoverlay This looks pretty good to me... +# load filesystem modules that may be required for overlay +# TODO: only load these conditionally if vol_id detects a fs that needs them Do they not get loaded automatically on the filesystem mount? That at least used to work. +# IMPORTANT TODO: while mount scanning find a way to determine if the +# filesystem was not cleanly unmounted. If so, IGNORE IT, +# as it may be part of a hibernated OS !!!!!!! Maybe instead of using cleanly unmounted vs not as the key, we should look at swaps to see if they have the SWSUSP signature? That's a pretty straight-forward thing to check, but I can't quite convince myself if it's as safe or not. +# CAVEAT: If the overlay file has a kin file with the suffix .inuse, this +# is evidence that that the overlay device was not unmounted cleanly. +# In _this_ case, look at the filesystem(???) and determine whether +# or not the most recent mount of the filesystem is more recent than +# the inuse file. *If and only if* NOT, then it is safe to assume +# that the filesystem is not part of a hibernated OS, and rather was +# most recently used as a persistence device that failed to be +# shutdown cleanly, thus it is safe to fsck the overlayfs, and then +# fsck the overlay-rootfs If we checked for the swsusp case instead, would we be able to skip this? +# IMPORTANT TODO: since ext3 is such a pain (possible?) to mount readonly, +# and since similar issues may exist in other fs (ntfs???), +# I think it would be good to have a function called +# really_mount_readonly() which does a blockdev --setro, then +# does a devicemapper snapshot to ram, then does a mount of +# the snapshotted device, then checks for existence of +# overlay and .inuse files. If the blockdev is read-only, do we really need to snapshot it too? +# RELATED: Given the above function, if a persistence file is detected, +# but the above above inuse/recent-mount-stamp test fails, give +# the user a 30-60 second timeout option to force an fsck and mount +# of the uncleanly mounted overlayfs, defaulting to not using it. Probably fair. fsck in the initramfs might have fun around controlling terminals and sometimes wanting to drop to a shell, so needs some testing to make sure it's sane +# TODO: All this multiple candidate code hasn't been tested recently (can't +# remember if it ever really did work). Though I have tested the +# typical auto case where one overlay is found and used. Probably the most important one :) +# TODO: verify that filesystems other than ext3 work. I know this will +# probably mean some interesting special case code. + +# TODO: handle nfs/network(fuse-httpfs?) persistence devices. This will +# require the ability to set up the network here, which is probably +# not trivial. This is one of the reasons I want to get rid of mayflower and build up mkinitrd; mkinitrd already has all kinds of network setup code for nfs/iscsi root and then we could take advantage of that. And fwiw, I spent a little bit of time getting a branch of mkinitrd started being able to do so, but then ran into a need for modprobe to do something more. Will get back there eventually. On the plus side, trying to make sure that we can do that switch without it mattering much for things like the overlay finding code (just have to do the little plug-in similar to the mayflower change) +# TODO: handle fsck'ing the rootfs if need be correctly? Or does the right +# thing just happen. I know that trying to use a persistence file +# from something that got unmounted uncleanly, seems to cause problems +# VERY quickly. This may be a fatal flaw... (or at least require +# some work) fsck of the combined fs should happen fine once we get into the normal userspace. And the ro rootfs shouldn't need fsck'ing. So I *think* we should be fine. Only needing to then worry about the case of a persistence file from an uncleanly mounted filesystem. Which maybe can be punted by saying you use ext3 (with journal, therefore no need for fsck usually) or vfat (unclean unmount is less disasterous) + losetup /dev/loop119 /mnt/overlayfs/overlay + echo "overlayfs_dev=tmpfs" > /mnt/overlayfs/overlay.inuse + echo "overlayfs_fstype=tmpfs" >> /mnt/overlayfs/overlay.inuse + echo "overlayfs_path=/overlay" >> /mnt/overlayfs/overlay.inuse + echo "/mnt/overlayfs/overlay.inuse" > /overlay.info Am I missing where this is used or is it just informational? diff --git a/creator/mayflower b/creator/mayflower index c1c5258..29cc8ec 100755 --- a/creator/mayflower +++ b/creator/mayflower @@ -268,6 +290,21 @@ for o in \`cat /proc/cmdline\` ; do live_locale=*) live_locale=\${o#live_locale=} ;; + # + # dmc overlay: aesthetics, undecided about name persistence vs overlay I actually kind of like overlay. But yeah, aesthetics :) + # dmc overlay: if non-ram overlay searching is desired, do it, + # otherwise, create overlay in ram as usual + if [ "x\${overlay}" != "x" ]; then + /sbin/findoverlay "\$overlay" + else + mkdir -p /mnt/overlayfs + mount -n -t tmpfs -o mode=0755 none /mnt/overlayfs + dd if=/dev/null of=/mnt/overlayfs/overlay bs=1024 count=1 seek= $((512*1024)) 2> /dev/null + losetup /dev/loop119 /mnt/overlayfs/overlay + echo "overlayfs_dev=tmpfs" > /mnt/overlayfs/overlay.inuse + echo "overlayfs_fstype=tmpfs" >> /mnt/overlayfs/overlay.inuse + echo "/mnt/overlayfs/overlay.inuse" > /overlay.info + fi This looks good; though as we had previously discussed, once this is working, we probably want auto to be the default and to be able to have overlay=off or overlay=ram or something to go back to the current mode. So yeah, overall, this is looking pretty spiffily good to me and I'm leaning towards starting to get it merged in so that we can start getting real use of it Jeremy From dmc.fedora at filteredperception.org Tue Aug 21 21:29:29 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 21 Aug 2007 16:29:29 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <1187727530.4781.63.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> Message-ID: <46CB5939.3010903@filteredperception.org> Jeremy Katz wrote: > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: >> 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. > > Couple of little things just to make reviewing easier, but not huge > problems > * Might be good to keep the initscripts changes as patches rather than > an orig and a modified version. Will make things work even if other > things in initscripts change and also makes it easier to know what's > going on. Agreed, this was still just a second pass.... > * It's good to get into the habit of doing git commits for each separate > change. Then you can get a patch per change. And that would avoid > having the addidir/addsdir stuff being in the same changes Actually, I was sort of making a combined point, that I was using addsdir as my method of including the modified initscripts. Long term, some sort elegant flexible permanent change to the initscripts are needed. Medium term, I was planning on having just the patches, and actually copying the patches into the initrd and having the livecd boot sequence patch the init scripts. Hopefully this illustrates why as a developer, having addsdir (or better named, --add-dir-to-system) functionality is very nice. If you can show me a better workflow... > > Now to get to the meat of things > > index 0000000..8962720 > --- /dev/null > +++ b/creator/etc_rc.d_init.d_functions > > I suspect that Bill might have some reservations about the hard-coded > overlayfs piece. At the same time, it's all I can think of and it's not > that out of line from other things in halt/rc.sysinit. I agree with the reservations. I'm open to suggestions. For the moment, there is a lot of much uglier stuff to deal with first. > > For the overlay info bit, we could potentially just stuff it > in /sbin/halt.local for now I think. I saw halt.local. I don't think you noticed how brutally ugly what I was doing was. The goal of that code after halt.local is to get the overlayfs cleanly unmounted. The way I currently accomplished that, was to YANK the snapshot overlay out of the root device. The only thing that makes this even remotely palatable, is the fact that the root device has been remounted read only. Which is the one thing that has happened between this code and the halt.local. (thus making halt.local not a workable place for this code) Thinking about it, the way to make it less horrendously ugly, would be to copy the binaries used from the rootfs (dmsetup, losetup, rm, mount) to a tmpfs first, since after the yanking, there is really no guarantee that any data read from the rootfs can be relied on. Or at least those are my thoughts on the issue right now. > > > diff --git a/creator/findoverlay b/creator/findoverlay > new file mode 100755 > index 0000000..e0674cc > --- /dev/null > +++ b/creator/findoverlay > > This looks pretty good to me... > > +# load filesystem modules that may be required for overlay > +# TODO: only load these conditionally if vol_id detects a fs that needs > them > > Do they not get loaded automatically on the filesystem mount? That at > least used to work. Probably. These were liberal notes. Though maybe the fuse ntfs doesn't work as nicely. Not a big deal. > > +# IMPORTANT TODO: while mount scanning find a way to determine if the > +# filesystem was not cleanly unmounted. If so, IGNORE IT, > +# as it may be part of a hibernated OS !!!!!!! > > Maybe instead of using cleanly unmounted vs not as the key, we should > look at swaps to see if they have the SWSUSP signature? That's a pretty > straight-forward thing to check, but I can't quite convince myself if > it's as safe or not. My worry about this- is things like *3* current hibernate implementations for linux. That means that you have many possible signatures to check, and there is no way to predict signature changes in future versions of hibernation. Another possible clincher is things like suspend2's (sorry, 'tux-on-ice' now) support for hibernation to files in the rootfs. I.e. I used to, and intend in the future, set up my system with no swap partition at all, doing swapfiles, and suspend2-suspend-to-file. (though I admit I'm currently getting some milage out of F7's much improved suspend out of the box) > > +# CAVEAT: If the overlay file has a kin file with the suffix .inuse, this > +# is evidence that that the overlay device was not unmounted cleanly. > +# In _this_ case, look at the filesystem(???) and determine whether > +# or not the most recent mount of the filesystem is more recent than > +# the inuse file. *If and only if* NOT, then it is safe to assume > +# that the filesystem is not part of a hibernated OS, and rather was > +# most recently used as a persistence device that failed to be > +# shutdown cleanly, thus it is safe to fsck the overlayfs, and then > +# fsck the overlay-rootfs > > If we checked for the swsusp case instead, would we be able to skip this? see above... Also, I just noticed that dumpe2fs does get me cleanly vs uncleanly mounted detection for ext2/3. And vfat I almost don't care about. I would like the same for ntfs, but as I'll mention again, I agree, ntfs support can be saved for the long term. > > +# IMPORTANT TODO: since ext3 is such a pain (possible?) to mount readonly, > +# and since similar issues may exist in other fs (ntfs???), > +# I think it would be good to have a function called > +# really_mount_readonly() which does a blockdev --setro, then > +# does a devicemapper snapshot to ram, then does a mount of > +# the snapshotted device, then checks for existence of > +# overlay and .inuse files. > > If the blockdev is read-only, do we really need to snapshot it too? The point is that when blockdev is read-only, you just can't mount it. (I think. I'm pretty sure I even tried mounting ro as ext2 and that failed. But that seems so wrong, I wouldn't bet on it without trying first.). I'll do more experimentation and things will become clearer. > > +# RELATED: Given the above function, if a persistence file is detected, > +# but the above above inuse/recent-mount-stamp test fails, give > +# the user a 30-60 second timeout option to force an fsck and mount > +# of the uncleanly mounted overlayfs, defaulting to not using it. > > Probably fair. fsck in the initramfs might have fun around controlling > terminals and sometimes wanting to drop to a shell, so needs some > testing to make sure it's sane > > +# TODO: All this multiple candidate code hasn't been tested recently (can't > +# remember if it ever really did work). Though I have tested the > +# typical auto case where one overlay is found and used. > > Probably the most important one :) Actually this was a relic. As I mentioned in the mail, I actually had tested this. And in fact, I learned, or relearned, a bit more about bash arrays, and the code doing this will look much cleaner soon. > > +# TODO: verify that filesystems other than ext3 work. I know this will > +# probably mean some interesting special case code. > + > +# TODO: handle nfs/network(fuse-httpfs?) persistence devices. This will > +# require the ability to set up the network here, which is probably > +# not trivial. > > This is one of the reasons I want to get rid of mayflower and build up > mkinitrd; mkinitrd already has all kinds of network setup code for > nfs/iscsi root and then we could take advantage of that. And fwiw, I > spent a little bit of time getting a branch of mkinitrd started being > able to do so, but then ran into a need for modprobe to do something > more. Will get back there eventually. On the plus side, trying to make > sure that we can do that switch without it mattering much for things > like the overlay finding code (just have to do the little plug-in > similar to the mayflower change) Yeah, I had noticed the nfs root stuff, which is part of what made me think of network sorts of possibilities here. > > +# TODO: handle fsck'ing the rootfs if need be correctly? Or does the right > +# thing just happen. I know that trying to use a persistence file > +# from something that got unmounted uncleanly, seems to cause problems > +# VERY quickly. This may be a fatal flaw... (or at least require > +# some work) > > fsck of the combined fs should happen fine once we get into the normal > userspace. And the ro rootfs shouldn't need fsck'ing. So I *think* we > should be fine. Only needing to then worry about the case of a > persistence file from an uncleanly mounted filesystem. Which maybe can > be punted by saying you use ext3 (with journal, therefore no need for > fsck usually) or vfat (unclean unmount is less disasterous) As mentioned by the 'fatal flaw', my apprehension is based on seeing how _very quickly_ things seem to fall over dead when trying to use a persistence file that did not get cleanly shut down. (while trying to access the fsck binary even...?) More experimentation again, will flush this issue out. Obviously if the whole system/mechanism cannot robustly deal with repeated yank-the-plug situations, then it isn't going to work for real users. I think I can put together a much more testable-quality patch fairly soon. I'm not entirely sure about merge worthy within a week... But we'll see. And I guess I can see something safe enough to merge within a week, given the safe default code paths (i.e. not default to auto for f8t2) > + losetup /dev/loop119 /mnt/overlayfs/overlay > + echo "overlayfs_dev=tmpfs" > /mnt/overlayfs/overlay.inuse > + echo "overlayfs_fstype=tmpfs" >> /mnt/overlayfs/overlay.inuse > + echo "overlayfs_path=/overlay" >> /mnt/overlayfs/overlay.inuse > + echo "/mnt/overlayfs/overlay.inuse" > /overlay.info > > Am I missing where this is used or is it just informational? This isn't really necessary in the traditional tmpfs overlay case that you referenced here. I did it mainly for consistency. Also, as alluded to before, a userspace tool that could online grow the overlay file, would use this. As this /overlay.info file becomes the .inuse file which is visible later. (again, maybe unnecessary. We'll see if I actually find a real use for it) > diff --git a/creator/mayflower b/creator/mayflower > index c1c5258..29cc8ec 100755 > --- a/creator/mayflower > +++ b/creator/mayflower > @@ -268,6 +290,21 @@ for o in \`cat /proc/cmdline\` ; do > live_locale=*) > live_locale=\${o#live_locale=} > ;; > + # > + # dmc overlay: aesthetics, undecided about name persistence vs > overlay > > I actually kind of like overlay. But yeah, aesthetics :) I agree. Persistence is perhaps a better description of the feature for end users. But overlay has the dual benefits of being easier to type, and exposes a fairly appropriate amount of information about how it is implemented. > > + # dmc overlay: if non-ram overlay searching is desired, do it, > + # otherwise, create overlay in ram as usual > + if [ "x\${overlay}" != "x" ]; then > + /sbin/findoverlay "\$overlay" > + else > + mkdir -p /mnt/overlayfs > + mount -n -t tmpfs -o mode=0755 none /mnt/overlayfs > + dd if=/dev/null of=/mnt/overlayfs/overlay bs=1024 count=1 seek= > $((512*1024)) 2> /dev/null > + losetup /dev/loop119 /mnt/overlayfs/overlay > + echo "overlayfs_dev=tmpfs" > /mnt/overlayfs/overlay.inuse > + echo "overlayfs_fstype=tmpfs" >> /mnt/overlayfs/overlay.inuse > + echo "/mnt/overlayfs/overlay.inuse" > /overlay.info > + fi > > This looks good; though as we had previously discussed, once this is > working, we probably want auto to be the default and to be able to have > overlay=off or overlay=ram or something to go back to the current mode. Agreed. But this may be a safe avenue if you really want to put code this immature in f8t2. > > So yeah, overall, this is looking pretty spiffily good to me and I'm > leaning towards starting to get it merged in so that we can start > getting real use of it We'll see where I'm at in another 24-48 hours, cleaning up the most obviously ugly things and perhaps making a more testable patch. -dmc From dmc.fedora at filteredperception.org Tue Aug 21 21:39:52 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Tue, 21 Aug 2007 16:39:52 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <1187725008.4781.25.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46C9E720.3060705@filteredperception.org> <1187725008.4781.25.camel@localhost.localdomain> Message-ID: <46CB5BA8.4050405@filteredperception.org> Jeremy Katz wrote: > On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote: >> Well, the way ubuntu is trying to do it of course, is with unionfs >> (since of course they use unionfs rather than dm-snapshot to get cow in >> the first place). >> >> And as such, unionfs can provide just as persistful an implementation as >> the direction I've been going. In both cases you can think of the >> persistence as another embedded layer in the total root filesystem. > > It's been quite a while since I looked at unionfs, but I vaguely > remember that it was more subtree overlays. I guess you could perhaps > do a subtree of /. But even so, I don't know that supporting multiple > ways of achieving the same goal is really where we want to go. But it's > somewhat academic at the moment, so probably not much discussion needed. I'm not sure if there is some meaning of subtree that is different than subdir. But the way most livecds work, is by having a big squashfs with your root filesystem (all of it, not seperated into subdirs or anything), and then having a tmpfs, and then using unionfs to make the tmpfs act as a layer over the squashfs, and then doing pivotroot to that single unionfs filesystem. Kadischi used the method that was predominant before that unionfs method, which was to have many subdirs (/usr, /opt) be read only, and then have some subdirs (/tmp, /var, ...) be read only. Perhaps using bindmounting or symlinks to handle some specific sub-subdirs. Back to unionfs- The major disadvantage of unionfs is that it is not 'perfect' as a real rootfs (why AFAIK fedora/rh refused to merge it). I.e. there are some known bugs, which knoppix and ubuntu just take as an acceptable tradeoff. The major advantage of unionfs, for the specific persistence topic at hand, is that when you delete a file from the COW rootfs, in unionfs, the memory is actually freed. Whereas for the dm-snapshot implementation of persistence, that is not the case. This may be acceptible. There may be workarounds for it (using shred to delete files into 0's, and then resparsifying the persistence overlay?) Anyway... yes, academic. And unionfs can't get rebootless installation (bwa ha ha....) -dmc From walters at redhat.com Tue Aug 21 23:03:03 2007 From: walters at redhat.com (Colin Walters) Date: Tue, 21 Aug 2007 19:03:03 -0400 Subject: [Fedora-livecd-list] local caching Message-ID: Hi, What's the status of the persistent local RPM caching patches? -------------- next part -------------- An HTML attachment was scrubbed... URL: From asdas at redhat.com Wed Aug 22 05:50:10 2007 From: asdas at redhat.com (ashok shankar das) Date: Wed, 22 Aug 2007 11:20:10 +0530 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46CB5BA8.4050405@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46C9E720.3060705@filteredperception.org> <1187725008.4781.25.camel@localhost.localdomain> <46CB5BA8.4050405@filteredperception.org> Message-ID: <46CBCE92.3000402@redhat.com> Douglas McClendon wrote: > Jeremy Katz wrote: > >> On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote: > > >>> Well, the way ubuntu is trying to do it of course, is with unionfs >>> (since of course they use unionfs rather than dm-snapshot to get cow >>> in the first place). >>> >>> And as such, unionfs can provide just as persistful an >>> implementation as the direction I've been going. In both cases you >>> can think of the persistence as another embedded layer in the total >>> root filesystem. >> >> >> It's been quite a while since I looked at unionfs, but I vaguely >> remember that it was more subtree overlays. I guess you could perhaps >> do a subtree of /. But even so, I don't know that supporting multiple >> ways of achieving the same goal is really where we want to go. But it's >> somewhat academic at the moment, so probably not much discussion needed. > > > > I'm not sure if there is some meaning of subtree that is different > than subdir. But the way most livecds work, is by having a big > squashfs with your root filesystem (all of it, not seperated into > subdirs or anything), and then having a tmpfs, and then using unionfs > to make the tmpfs act as a layer over the squashfs, and then doing > pivotroot to that single unionfs filesystem. > > Kadischi used the method that was predominant before that unionfs > method, which was to have many subdirs (/usr, /opt) be read only, and > then have some subdirs (/tmp, /var, ...) be read only. Perhaps using > bindmounting or symlinks to handle some specific sub-subdirs. > > Back to unionfs- The major disadvantage of unionfs is that it is not > 'perfect' as a real rootfs (why AFAIK fedora/rh refused to merge it). > I.e. there are some known bugs, which knoppix and ubuntu just take as > an acceptable tradeoff. > the problem is in symlinks(unionfs). incase of devmaper this problem is not there. But there is another issue. The snapshot size. The method I follow is ofcourse Devmaper. But i tryed with fuse and funionfs but not tested vigourously. > The major advantage of unionfs, for the specific persistence topic at > hand, is that when you delete a file from the COW rootfs, in unionfs, > the memory is actually freed. Whereas for the dm-snapshot > implementation of persistence, that is not the case. > > This may be acceptible. There may be workarounds for it (using shred > to delete files into 0's, and then resparsifying the persistence > overlay?) > > Anyway... yes, academic. > > And unionfs can't get rebootless installation (bwa ha ha....) > > -dmc > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From katzj at redhat.com Wed Aug 22 14:04:08 2007 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 22 Aug 2007 10:04:08 -0400 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46CB5939.3010903@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> <46CB5939.3010903@filteredperception.org> Message-ID: <1187791448.25291.36.camel@localhost.localdomain> On Tue, 2007-08-21 at 16:29 -0500, Douglas McClendon wrote: > Jeremy Katz wrote: > > On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: > > For the overlay info bit, we could potentially just stuff it > > in /sbin/halt.local for now I think. > > I saw halt.local. I don't think you noticed how brutally ugly what I > was doing was. > > The goal of that code after halt.local is to get the overlayfs cleanly > unmounted. > > The way I currently accomplished that, was to YANK the snapshot overlay > out of the root device. The only thing that makes this even remotely > palatable, is the fact that the root device has been remounted read > only. Which is the one thing that has happened between this code and > the halt.local. (thus making halt.local not a workable place for this code) Ah yeah, oh well. Was at least a thought. Although, continuing with just stupid thinking out loud, why yank it? We've mounted the root device ro, so we should also be able to make the overlay device read only at that point. Which would then lead to it being clean on the next boot and should be reliable. Unless I'm missing something, which I probably am since it's still early > Thinking about it, the way to make it less horrendously ugly, would be > to copy the binaries used from the rootfs (dmsetup, losetup, rm, mount) > to a tmpfs first, since after the yanking, there is really no guarantee > that any data read from the rootfs can be relied on. Alternately (and I've had this discussion before with someone, although I forget whom), we really want to be able to get back to running from the initramfs on shutdown. eg, that's the only way we'll ever be able to eject the CD for reboot. And at that point, we do have the binaries we care about and can rely on them and maybe could have this be cleaner. > > +# IMPORTANT TODO: while mount scanning find a way to determine if the > > +# filesystem was not cleanly unmounted. If so, IGNORE IT, > > +# as it may be part of a hibernated OS !!!!!!! > > > > Maybe instead of using cleanly unmounted vs not as the key, we should > > look at swaps to see if they have the SWSUSP signature? That's a pretty > > straight-forward thing to check, but I can't quite convince myself if > > it's as safe or not. > > My worry about this- is things like *3* current hibernate > implementations for linux. That means that you have many possible > signatures to check, and there is no way to predict signature changes in > future versions of hibernation. There's no way to predict the future, period. Generally, as the world around the live image being created changes, things like initrds, etc have to evolve too. But, I'm not at all tied one way or another. I wonder if we could actually just take advantage of fsck to tell us if it's clean or dirty -- I guess only if we did a "don't change anything run" and not anything more programatic. [snip] > > So yeah, overall, this is looking pretty spiffily good to me and I'm > > leaning towards starting to get it merged in so that we can start > > getting real use of it > > We'll see where I'm at in another 24-48 hours, cleaning up the most > obviously ugly things and perhaps making a more testable patch. If we want to get to where it's available by default in F8, it'll definitely be good to have something for test2, even if some of the "pull the plug" corner cases aren't happy. The only reason I feel okay with making the auto case the default is that while it's automatic to use if setup, you still have to setup the overlay file. So unless you've already done the setup work to opt-in, you're not going to get hit that hard. Jeremy From dmc.fedora at filteredperception.org Wed Aug 22 18:26:13 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 22 Aug 2007 13:26:13 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <1187791448.25291.36.camel@localhost.localdomain> References: <46C96BB7.6030400@filteredperception.org> <1187727530.4781.63.camel@localhost.localdomain> <46CB5939.3010903@filteredperception.org> <1187791448.25291.36.camel@localhost.localdomain> Message-ID: <46CC7FC5.60703@filteredperception.org> Jeremy Katz wrote: > On Tue, 2007-08-21 at 16:29 -0500, Douglas McClendon wrote: >> Jeremy Katz wrote: >>> On Mon, 2007-08-20 at 05:23 -0500, Douglas McClendon wrote: >>> For the overlay info bit, we could potentially just stuff it >>> in /sbin/halt.local for now I think. >> I saw halt.local. I don't think you noticed how brutally ugly what I >> was doing was. >> >> The goal of that code after halt.local is to get the overlayfs cleanly >> unmounted. >> >> The way I currently accomplished that, was to YANK the snapshot overlay >> out of the root device. The only thing that makes this even remotely >> palatable, is the fact that the root device has been remounted read >> only. Which is the one thing that has happened between this code and >> the halt.local. (thus making halt.local not a workable place for this code) > > Ah yeah, oh well. Was at least a thought. Although, continuing with > just stupid thinking out loud, why yank it? We've mounted the root > device ro, so we should also be able to make the overlay device read > only at that point. Which would then lead to it being clean on the next > boot and should be reliable. Unless I'm missing something, which I > probably am since it's still early No, I think you you're right. The same thought hit me last night. I think the key (if it works) is using losetup -r to change the overlay loopback device to readonly before trying the unmount. I think not realizing that that is possible is what put me on the wrong track. > >> Thinking about it, the way to make it less horrendously ugly, would be >> to copy the binaries used from the rootfs (dmsetup, losetup, rm, mount) >> to a tmpfs first, since after the yanking, there is really no guarantee >> that any data read from the rootfs can be relied on. > > Alternately (and I've had this discussion before with someone, although > I forget whom), we really want to be able to get back to running from > the initramfs on shutdown. eg, that's the only way we'll ever be able > to eject the CD for reboot. And at that point, we do have the binaries > we care about and can rely on them and maybe could have this be cleaner. I also came to this conclusion. It is also quite logical in the sense of tearing things down in the reverse order of how they are built up. Also if the ideas about putting gdm and other stuff into initramfs, that also makes more sense. Part of it, would be doing something similar to what I did with /mnt/overlayfs to make the originial initramfs mount point remain visible after the pivotroot. I'll give it a shot. > >>> +# IMPORTANT TODO: while mount scanning find a way to determine if the >>> +# filesystem was not cleanly unmounted. If so, IGNORE IT, >>> +# as it may be part of a hibernated OS !!!!!!! >>> >>> Maybe instead of using cleanly unmounted vs not as the key, we should >>> look at swaps to see if they have the SWSUSP signature? That's a pretty >>> straight-forward thing to check, but I can't quite convince myself if >>> it's as safe or not. >> My worry about this- is things like *3* current hibernate >> implementations for linux. That means that you have many possible >> signatures to check, and there is no way to predict signature changes in >> future versions of hibernation. > > There's no way to predict the future, period. Generally, as the world > around the live image being created changes, things like initrds, etc > have to evolve too. But, I'm not at all tied one way or another. I > wonder if we could actually just take advantage of fsck to tell us if > it's clean or dirty -- I guess only if we did a "don't change anything > run" and not anything more programatic. That sounds promising. > > [snip] >>> So yeah, overall, this is looking pretty spiffily good to me and I'm >>> leaning towards starting to get it merged in so that we can start >>> getting real use of it >> We'll see where I'm at in another 24-48 hours, cleaning up the most >> obviously ugly things and perhaps making a more testable patch. > > If we want to get to where it's available by default in F8, it'll > definitely be good to have something for test2, even if some of the > "pull the plug" corner cases aren't happy. The only reason I feel okay > with making the auto case the default is that while it's automatic to > use if setup, you still have to setup the overlay file. So unless > you've already done the setup work to opt-in, you're not going to get > hit that hard. The reason why I would disagree (fairly strongly), is that even if you haven't set up the persistent device, all this code is going to be running at boot time, that is probing and looking at all the partitions on the system, in a much drastically more invasive fashion than has historically been the case. I don't think that there is anything that could happen in a week or two that would make me feel comfortable enough about the solidness of the code that I would endorse that. Now, only doing that if the f8t2 user reads the disclaimer in the docs before finding out they need to type "overlay=auto" at the boot prompt, that I have no problem with. -dmc From dmc.fedora at filteredperception.org Wed Aug 22 21:16:57 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 22 Aug 2007 16:16:57 -0500 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46CBCE92.3000402@redhat.com> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46C9E720.3060705@filteredperception.org> <1187725008.4781.25.camel@localhost.localdomain> <46CB5BA8.4050405@filteredperception.org> <46CBCE92.3000402@redhat.com> Message-ID: <46CCA7C9.6010506@filteredperception.org> ashok shankar das wrote: > Douglas McClendon wrote: > >> Jeremy Katz wrote: >> >>> On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote: >> >> >>>> Well, the way ubuntu is trying to do it of course, is with unionfs >>>> (since of course they use unionfs rather than dm-snapshot to get cow >>>> in the first place). >>>> >>>> And as such, unionfs can provide just as persistful an >>>> implementation as the direction I've been going. In both cases you >>>> can think of the persistence as another embedded layer in the total >>>> root filesystem. >>> >>> >>> It's been quite a while since I looked at unionfs, but I vaguely >>> remember that it was more subtree overlays. I guess you could perhaps >>> do a subtree of /. But even so, I don't know that supporting multiple >>> ways of achieving the same goal is really where we want to go. But it's >>> somewhat academic at the moment, so probably not much discussion needed. >> >> >> >> I'm not sure if there is some meaning of subtree that is different >> than subdir. But the way most livecds work, is by having a big >> squashfs with your root filesystem (all of it, not seperated into >> subdirs or anything), and then having a tmpfs, and then using unionfs >> to make the tmpfs act as a layer over the squashfs, and then doing >> pivotroot to that single unionfs filesystem. >> >> Kadischi used the method that was predominant before that unionfs >> method, which was to have many subdirs (/usr, /opt) be read only, and >> then have some subdirs (/tmp, /var, ...) be read only. Perhaps using >> bindmounting or symlinks to handle some specific sub-subdirs. >> >> Back to unionfs- The major disadvantage of unionfs is that it is not >> 'perfect' as a real rootfs (why AFAIK fedora/rh refused to merge it). >> I.e. there are some known bugs, which knoppix and ubuntu just take as >> an acceptable tradeoff. >> > the problem is in symlinks(unionfs). incase of devmaper this problem is > not there. But there is another issue. The snapshot size. The method I > follow is ofcourse Devmaper. But i tryed with fuse and funionfs but not > tested vigourously. Yes, I just ran across a page describing how ubuntu actually used to use devicemapper snapshot, but switched to unionfs, because they said it was faster and more flexible (and the overlay memory usage not decreasing when cow created files get deleted). As mentioned, it might be interesting work (for some day far from today), to see if you could get rm to zero out files, and then have them not take up space in the overlay device afterwords. I notice from man chattr(and shred) there is already some work on the zero-out parts, and perhaps dm-snapshot is already smart enough to detect that the newly changed overlay blocks match the base blocks (0s in both cases), and free the associated memory. It would be nice however if there was a bulletproof unionfs implementation though... that was as reliable for the rootfs as say, LVM has proven to be. -dmc > >> The major advantage of unionfs, for the specific persistence topic at >> hand, is that when you delete a file from the COW rootfs, in unionfs, >> the memory is actually freed. Whereas for the dm-snapshot >> implementation of persistence, that is not the case. >> >> This may be acceptible. There may be workarounds for it (using shred >> to delete files into 0's, and then resparsifying the persistence >> overlay?) >> >> Anyway... yes, academic. >> >> And unionfs can't get rebootless installation (bwa ha ha....) >> >> -dmc >> >> >> -- >> Fedora-livecd-list mailing list >> Fedora-livecd-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > From jsteer at bitscout.com Thu Aug 23 01:45:16 2007 From: jsteer at bitscout.com (Jon Steer) Date: Wed, 22 Aug 2007 20:45:16 -0500 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? Message-ID: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> I would like to customize the kickstart file that anaconda uses during a liveinst install of my liveCD. The kickstart file that is used for the install, is not the same kickstart file that was used to create the LiveCD. A cursory inspection of anaconda doesn't yield any clues about how that kickstart is created, or where it comes from. Any pointers? thanks, jon -- "Whereever you go, there you are" From dmc.fedora at filteredperception.org Thu Aug 23 01:57:37 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Wed, 22 Aug 2007 20:57:37 -0500 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> Message-ID: <46CCE991.4060506@filteredperception.org> Jon Steer wrote: > I would like to customize the kickstart file that anaconda uses during > a liveinst install of my liveCD. There is no kickstart. It copies the installed (ext3 file)system right from the livecd onto the disk. Alternately you can launch anaconda yourself with a kickstart, assuming it defines the appropriately visable network repos. I've had thoughts about kickstart applied the filesystem copy method. It might be doable with code similar to what livecd-creator uses for it's "base-on-iso" codepath. The only benefit there, is that it wouldn't hit the network for packages already installed on the iso. -dmc > The kickstart file that is used for the install, is not the same > kickstart file that was used to create the LiveCD. > > A cursory inspection of anaconda doesn't yield any clues about how > that kickstart is created, or where it comes from. > > > Any pointers? > thanks, > jon > > From jsteer at bitscout.com Thu Aug 23 03:07:58 2007 From: jsteer at bitscout.com (Jon Steer) Date: Wed, 22 Aug 2007 22:07:58 -0500 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: <46CCE991.4060506@filteredperception.org> References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> <46CCE991.4060506@filteredperception.org> Message-ID: <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> When I use liveinst, I get grub options that are different than what was on the original liveCD. For example, the original LiveCD had selinux off and no X, the installed version had both. I am using the stock anaconda and livecd tools, so perhaps I am missing some of the patches that would correct this? jon On 8/22/07, Douglas McClendon wrote: > Jon Steer wrote: > > I would like to customize the kickstart file that anaconda uses during > > a liveinst install of my liveCD. > > There is no kickstart. It copies the installed (ext3 file)system right > from the livecd onto the disk. > > Alternately you can launch anaconda yourself with a kickstart, assuming > it defines the appropriately visable network repos. > > I've had thoughts about kickstart applied the filesystem copy method. > It might be doable with code similar to what livecd-creator uses for > it's "base-on-iso" codepath. The only benefit there, is that it > wouldn't hit the network for packages already installed on the iso. > > -dmc > > > The kickstart file that is used for the install, is not the same > > kickstart file that was used to create the LiveCD. > > > > A cursory inspection of anaconda doesn't yield any clues about how > > that kickstart is created, or where it comes from. > > > > > > Any pointers? > > thanks, > > jon > > > > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Whereever you go, there you are" From Mohammed_Khan at Dell.com Thu Aug 23 03:25:53 2007 From: Mohammed_Khan at Dell.com (Mohammed_Khan at Dell.com) Date: Wed, 22 Aug 2007 22:25:53 -0500 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com><46CCE991.4060506@filteredperception.org> <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> Message-ID: You can actually feed liveinst a kickstart by adding a $1 to the end of the line in liveinst where it invokes anaconda... then you can do liveinst --kickstart=somefile.cfg and it passes the --kickstart= part to anaconda.. If have not tried to feed it packages this way, but partitioning, network, password, %post, etc work fine... Thanks, Mfk -----Original Message----- From: fedora-livecd-list-bounces at redhat.com [mailto:fedora-livecd-list-bounces at redhat.com] On Behalf Of Jon Steer Sent: Wednesday, August 22, 2007 10:08 PM To: fedora-livecd-list at redhat.com Subject: Re: [Fedora-livecd-list] liveinst ,where does it get it's kickstart file from? When I use liveinst, I get grub options that are different than what was on the original liveCD. For example, the original LiveCD had selinux off and no X, the installed version had both. I am using the stock anaconda and livecd tools, so perhaps I am missing some of the patches that would correct this? jon On 8/22/07, Douglas McClendon wrote: > Jon Steer wrote: > > I would like to customize the kickstart file that anaconda uses during > > a liveinst install of my liveCD. > > There is no kickstart. It copies the installed (ext3 file)system right > from the livecd onto the disk. > > Alternately you can launch anaconda yourself with a kickstart, assuming > it defines the appropriately visable network repos. > > I've had thoughts about kickstart applied the filesystem copy method. > It might be doable with code similar to what livecd-creator uses for > it's "base-on-iso" codepath. The only benefit there, is that it > wouldn't hit the network for packages already installed on the iso. > > -dmc > > > The kickstart file that is used for the install, is not the same > > kickstart file that was used to create the LiveCD. > > > > A cursory inspection of anaconda doesn't yield any clues about how > > that kickstart is created, or where it comes from. > > > > > > Any pointers? > > thanks, > > jon > > > > > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Whereever you go, there you are" -- Fedora-livecd-list mailing list Fedora-livecd-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list From jsteer at bitscout.com Thu Aug 23 03:37:50 2007 From: jsteer at bitscout.com (Jon Steer) Date: Wed, 22 Aug 2007 22:37:50 -0500 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> <46CCE991.4060506@filteredperception.org> <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> Message-ID: <74e6f65d0708222037r13a42c96o2319fa703ed8972a@mail.gmail.com> Thank you! for the existence proof that alterations could get done this way.. I wondered if anaconda would ignore most of the command line arguments if it had been invoked with livecd. jon On 8/22/07, Mohammed_Khan at dell.com wrote: > You can actually feed liveinst a kickstart by adding a $1 to the end of > the line in liveinst where it invokes anaconda... then you can do > liveinst --kickstart=somefile.cfg and it passes the --kickstart= part to > anaconda.. > > If have not tried to feed it packages this way, but partitioning, > network, password, %post, etc work fine... > > Thanks, > > Mfk > > -----Original Message----- > From: fedora-livecd-list-bounces at redhat.com > [mailto:fedora-livecd-list-bounces at redhat.com] On Behalf Of Jon Steer > Sent: Wednesday, August 22, 2007 10:08 PM > To: fedora-livecd-list at redhat.com > Subject: Re: [Fedora-livecd-list] liveinst ,where does it get it's > kickstart file from? > > When I use liveinst, I get grub options that are different than what > was on the original liveCD. For example, the original LiveCD had > selinux off and no X, the installed version had both. > > I am using the stock anaconda and livecd tools, so perhaps I am > missing some of the patches that would correct this? > > jon > > On 8/22/07, Douglas McClendon wrote: > > Jon Steer wrote: > > > I would like to customize the kickstart file that anaconda uses > during > > > a liveinst install of my liveCD. > > > > There is no kickstart. It copies the installed (ext3 file)system > right > > from the livecd onto the disk. > > > > Alternately you can launch anaconda yourself with a kickstart, > assuming > > it defines the appropriately visable network repos. > > > > I've had thoughts about kickstart applied the filesystem copy method. > > It might be doable with code similar to what livecd-creator uses for > > it's "base-on-iso" codepath. The only benefit there, is that it > > wouldn't hit the network for packages already installed on the iso. > > > > -dmc > > > > > The kickstart file that is used for the install, is not the same > > > kickstart file that was used to create the LiveCD. > > > > > > A cursory inspection of anaconda doesn't yield any clues about how > > > that kickstart is created, or where it comes from. > > > > > > > > > Any pointers? > > > thanks, > > > jon > > > > > > > > > > -- > > Fedora-livecd-list mailing list > > Fedora-livecd-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > > > > -- > > "Whereever you go, there you are" > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > -- "Whereever you go, there you are" From asdas at redhat.com Thu Aug 23 06:02:11 2007 From: asdas at redhat.com (ashok shankar das) Date: Thu, 23 Aug 2007 11:32:11 +0530 Subject: [Fedora-livecd-list] [PATCH] overlay/persistence second pass - for developer reference only In-Reply-To: <46CCA7C9.6010506@filteredperception.org> References: <46C96BB7.6030400@filteredperception.org> <1187622621.7085.68.camel@localhost.localdomain> <46C9E720.3060705@filteredperception.org> <1187725008.4781.25.camel@localhost.localdomain> <46CB5BA8.4050405@filteredperception.org> <46CBCE92.3000402@redhat.com> <46CCA7C9.6010506@filteredperception.org> Message-ID: <46CD22E3.1090705@redhat.com> Douglas McClendon wrote: > ashok shankar das wrote: > >> Douglas McClendon wrote: >> >>> Jeremy Katz wrote: >>> >>>> On Mon, 2007-08-20 at 14:10 -0500, Douglas McClendon wrote: >>> >>> >>> >>>>> Well, the way ubuntu is trying to do it of course, is with unionfs >>>>> (since of course they use unionfs rather than dm-snapshot to get >>>>> cow in the first place). >>>>> >>>>> And as such, unionfs can provide just as persistful an >>>>> implementation as the direction I've been going. In both cases >>>>> you can think of the persistence as another embedded layer in the >>>>> total root filesystem. >>>> >>>> >>>> >>>> It's been quite a while since I looked at unionfs, but I vaguely >>>> remember that it was more subtree overlays. I guess you could perhaps >>>> do a subtree of /. But even so, I don't know that supporting multiple >>>> ways of achieving the same goal is really where we want to go. But >>>> it's >>>> somewhat academic at the moment, so probably not much discussion >>>> needed. >>> >>> >>> >>> >>> I'm not sure if there is some meaning of subtree that is different >>> than subdir. But the way most livecds work, is by having a big >>> squashfs with your root filesystem (all of it, not seperated into >>> subdirs or anything), and then having a tmpfs, and then using >>> unionfs to make the tmpfs act as a layer over the squashfs, and then >>> doing pivotroot to that single unionfs filesystem. >>> >>> Kadischi used the method that was predominant before that unionfs >>> method, which was to have many subdirs (/usr, /opt) be read only, >>> and then have some subdirs (/tmp, /var, ...) be read only. Perhaps >>> using bindmounting or symlinks to handle some specific sub-subdirs. >>> >>> Back to unionfs- The major disadvantage of unionfs is that it is >>> not 'perfect' as a real rootfs (why AFAIK fedora/rh refused to merge >>> it). I.e. there are some known bugs, which knoppix and ubuntu just >>> take as an acceptable tradeoff. >>> >> the problem is in symlinks(unionfs). incase of devmaper this problem >> is not there. But there is another issue. The snapshot size. The >> method I follow is ofcourse Devmaper. But i tryed with fuse and >> funionfs but not tested vigourously. > > > Yes, I just ran across a page describing how ubuntu actually used to > use devicemapper snapshot, but switched to unionfs, because they said > it was faster and more flexible (and the overlay memory usage not > decreasing when cow created files get deleted). > > As mentioned, it might be interesting work (for some day far from > today), to see if you could get rm to zero out files, and then have > them not take up space in the overlay device afterwords. I notice > from man chattr(and shred) there is already some work on the zero-out > parts, and perhaps dm-snapshot is already smart enough to detect that > the newly changed overlay blocks match the base blocks (0s in both > cases), and free the associated memory. > > It would be nice however if there was a bulletproof unionfs > implementation though... that was as reliable for the rootfs as say, > LVM has proven to be. I agree with your views. And The LVM stuffs are really nice, but why not experiment with new things? That is why if sombody can make *unionfs/funionfs* rock solid then the livecd/persistent issue would be solved. Even i could dream of a diskless persistent handheld device too ;) > > -dmc > > >> >>> The major advantage of unionfs, for the specific persistence topic >>> at hand, is that when you delete a file from the COW rootfs, in >>> unionfs, the memory is actually freed. Whereas for the dm-snapshot >>> implementation of persistence, that is not the case. >>> >>> This may be acceptible. There may be workarounds for it (using >>> shred to delete files into 0's, and then resparsifying the >>> persistence overlay?) >>> >>> Anyway... yes, academic. >>> >>> And unionfs can't get rebootless installation (bwa ha ha....) >>> >>> -dmc >>> >>> >>> -- >>> Fedora-livecd-list mailing list >>> Fedora-livecd-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-livecd-list >> >> >> >> > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From dmc.fedora at filteredperception.org Thu Aug 23 10:30:32 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 23 Aug 2007 05:30:32 -0500 Subject: [Fedora-livecd-list] [PATCH] livecd persistence - devicemapper style - v3 - still not robust Message-ID: <46CD61C8.7060807@filteredperception.org> The 3rd pass at my overlay/persistence patch for livecd-tools, isn't really bigger than the 2nd, but it is fairly big, and definitely not the final version. So if you want it, or any further updates if and as they become available, see http://filteredperception.org/downloads/overlay/ Summary of changes from the last version - - much better remount read-only teardown of overlayfs - findoverlay script debugging cleaned up, and obeys 'quiet' kernel arg - live script will technically work for initialization of an overlay image file, but it is still pretty much a placeholder - more organized, and revised todo/notes in findoverlay script. - very ugly (but maybe a bit less than before) mechanism for patching the halt and functions scripts to support clean shutdown. I'm _very_ open to suggestions for better ways to do it, than the livecd-creator->mayflower->initramfs->/etc/rc.d/init.d/fedora-live path currently. Also note that to get that done I had to put the same ugly temporary hack in 3 different config files. Maybe it is time to take care of the TODO that suggests getting fedora-live out of the kickstart and into a package. Of particular note, is that at this point in time, I'm getting a bit wary as to whether or not, short of 'fixing' problems that are probably beyond my abilities and/or desires, that this entire devicemapper snapshot mechanism, using overlay image files on disk, may be fatally flawed. See notes at end of findoverlay script for exact ext3 corruption error messages, and my random musings on the subject. I think it may well be that a vastly simpler implementation using only raw partitions, such as Ashok's might actually work better. At least for the short term, until I can figure out the problems I'm seeing. Or perhaps even an implementation with unionfs/funionfs. I would _really_ like to see my method work, but there are also other unrelated lower hanging fruit of interest to me that I think I might rather be working on. That said, my code is there, and I'll be more than happy to answer questions or brainstorm about it if anybody inquires. And maybe some idea will hit me or someone else soon, and I'll actually be able to make it work robustly. Or really, I may have just run into one bad failure case that isn't even reproducable, and further testing will show that it works pretty well. -dmc From jkeating at redhat.com Thu Aug 23 11:39:12 2007 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 23 Aug 2007 07:39:12 -0400 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> <46CCE991.4060506@filteredperception.org> <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> Message-ID: <20070823073912.6e38bd1a@ender> On Wed, 22 Aug 2007 22:07:58 -0500 "Jon Steer" wrote: > When I use liveinst, I get grub options that are different than what > was on the original liveCD. For example, the original LiveCD had > selinux off and no X, the installed version had both. > > I am using the stock anaconda and livecd tools, so perhaps I am > missing some of the patches that would correct this? The selinux question is asked in firstboot. We default to on so that files are labeled correctly. This is a little funny if you're coming from a Live image without selinux labeling. X or not is a decision made based on a couple factors. A) did you do a gui install (not text mode), B) did you install graphical bits (X, Gnome, GDM, etc.., and maybe a few other factors, but that's about it. Since the install you do from Live image is a standard interactive install these things are all done just like the install you would do from other media. -- Jesse Keating Fedora -- All my bits are free, are yours? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Thu Aug 23 12:01:27 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 23 Aug 2007 14:01:27 +0200 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy In-Reply-To: <1187622016.7085.58.camel@localhost.localdomain> References: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> <1187622016.7085.58.camel@localhost.localdomain> Message-ID: <13dbfe4f0708230501x6ba03b4fma83429921ba8ce3a@mail.gmail.com> On 8/20/07, Jeremy Katz wrote: > It looks like you have a config which specifies selinux --enforcing, but > isn't including an SELinux policy. If I had to guess, this is because > you don't have the @core group included. That's definitely something > you're going to want. Thanks. I'm now using rawhide mirrors. I noticed that anaconda requires firefox thus requiring more libraries. Thus more space is required, which on a livecd there are barely any. The KDE spin might suffer from this as well. Is there any specific reason why anaconda needs firefox ? Also I've seen on KDE Livecd (moonshine), the rhgb isn't launched. After installing KDE desktop from the KDE spin, there is still no rhgb. yum install rhgb. rhgb is installed but doesn't launch on boot. RexDieter recommended the installation of @base-x on the newly installed fedora to ensure rhgb's launch. Thus surely rhgb misses some requires. However even though @base-x rhgb are listed in the kickstart file for livecd. On booting the livecd, there is still no rghb. Are the more missing requires ? Chitlesh -- http://clunixchit.blogspot.com From katzj at redhat.com Thu Aug 23 14:47:24 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Aug 2007 10:47:24 -0400 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> <46CCE991.4060506@filteredperception.org> <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> Message-ID: <1187880444.1215.10.camel@localhost.localdomain> Note: this isn't really very kickstart related -- more just general anaconda. On Wed, 2007-08-22 at 22:07 -0500, Jon Steer wrote: > When I use liveinst, I get grub options that are different than what > was on the original liveCD. For example, the original LiveCD had > selinux off and no X, the installed version had both. To be honest, this is probably because most of the testing has been with the stock live images which have SELinux and X. We should probably do detection of when that's not the case and do things appropriately. If you have cases where that doesn't happen, just file bugs against anaconda and I can fix them up. Jeremy From katzj at redhat.com Thu Aug 23 14:48:34 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Aug 2007 10:48:34 -0400 Subject: [Fedora-livecd-list] liveinst , where does it get it's kickstart file from? In-Reply-To: References: <74e6f65d0708221845u552a7a68i388bd1bd958c3c99@mail.gmail.com> <46CCE991.4060506@filteredperception.org> <74e6f65d0708222007r1787afe2uebf8fe1864b96e6@mail.gmail.com> Message-ID: <1187880514.1215.13.camel@localhost.localdomain> On Wed, 2007-08-22 at 22:25 -0500, Mohammed_Khan at Dell.com wrote: > You can actually feed liveinst a kickstart by adding a $1 to the end of > the line in liveinst where it invokes anaconda... then you can do > liveinst --kickstart=somefile.cfg and it passes the --kickstart= part to > anaconda.. > > If have not tried to feed it packages this way, but partitioning, > network, password, %post, etc work fine... Packages won't work. If you want to do packages, then instead of running liveinst, you can just run anaconda directly with the appropriate command line options for the kickstart config and a "network" method Jeremy From katzj at redhat.com Thu Aug 23 14:52:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Aug 2007 10:52:45 -0400 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy In-Reply-To: <13dbfe4f0708230501x6ba03b4fma83429921ba8ce3a@mail.gmail.com> References: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> <1187622016.7085.58.camel@localhost.localdomain> <13dbfe4f0708230501x6ba03b4fma83429921ba8ce3a@mail.gmail.com> Message-ID: <1187880765.1215.18.camel@localhost.localdomain> On Thu, 2007-08-23 at 14:01 +0200, Chitlesh GOORAH wrote: > I noticed that anaconda requires firefox thus requiring more > libraries. Thus more space is required, which on a livecd there are > barely any. > The KDE spin might suffer from this as well. > Is there any specific reason why anaconda needs firefox ? Dependency insanity for directory ownership :/ anaconda doesn't require firefox, it requires zenity (so that we can give a way for people to do progress in some cases). zenity requires yelp because of having a help file in a directory and that then spirals onward. Work on fixing it is underway > Also I've seen on KDE Livecd (moonshine), the rhgb isn't launched. > After installing KDE desktop from the KDE spin, there is still no > rhgb. > > yum install rhgb. rhgb is installed but doesn't launch on boot. > RexDieter recommended the installation of @base-x on the newly > installed fedora to ensure rhgb's launch. Thus surely rhgb misses some > requires. There's more than just the package being installed that's needed. You also need rhgb on the kernel command line. We don't do this on the live images because the last time I tried, even with rhgb installed, it didn't work. There was a problem with it not liking a lack of /etc/mtab, but even after I fixed that, it wasn't wanting to work. Jeremy From katzj at redhat.com Thu Aug 23 14:58:28 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Aug 2007 10:58:28 -0400 Subject: [Fedora-livecd-list] [PATCH] livecd persistence - devicemapper style - v3 - still not robust In-Reply-To: <46CD61C8.7060807@filteredperception.org> References: <46CD61C8.7060807@filteredperception.org> Message-ID: <1187881108.1215.21.camel@localhost.localdomain> On Thu, 2007-08-23 at 05:30 -0500, Douglas McClendon wrote: > Of particular note, is that at this point in time, I'm getting a bit > wary as to whether or not, short of 'fixing' problems that are probably > beyond my abilities and/or desires, that this entire devicemapper > snapshot mechanism, using overlay image files on disk, may be fatally > flawed. See notes at end of findoverlay script for exact ext3 > corruption error messages, and my random musings on the subject. I'll do some testing to see if I hit the same problems. Jeremy From chitlesh at fedoraproject.org Thu Aug 23 15:35:28 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 23 Aug 2007 17:35:28 +0200 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy In-Reply-To: <1187880765.1215.18.camel@localhost.localdomain> References: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> <1187622016.7085.58.camel@localhost.localdomain> <13dbfe4f0708230501x6ba03b4fma83429921ba8ce3a@mail.gmail.com> <1187880765.1215.18.camel@localhost.localdomain> Message-ID: <13dbfe4f0708230835o5f6aed25p25c897b08564a4ec@mail.gmail.com> On 8/23/07, Jeremy Katz wrote: > Dependency insanity for directory ownership :/ anaconda doesn't require > firefox, it requires zenity (so that we can give a way for people to do > progress in some cases). zenity requires yelp because of having a help > file in a directory and that then spirals onward. Work on fixing it is > underway Nice, I'll follow that closely :) > There's more than just the package being installed that's needed. You > also need rhgb on the kernel command line. We don't do this on the live > images because the last time I tried, even with rhgb installed, it > didn't work. There was a problem with it not liking a lack > of /etc/mtab, but even after I fixed that, it wasn't wanting to work. I've added rhgb on the kernel command line manually. it work. Rhgb launches automatically. I've @base-x and rhgb installed on the livecd. Chitlesh -- http://clunixchit.blogspot.com From katzj at redhat.com Thu Aug 23 18:06:26 2007 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 23 Aug 2007 14:06:26 -0400 Subject: [Fedora-livecd-list] kernel panic, unable to load selinux policy In-Reply-To: <13dbfe4f0708230835o5f6aed25p25c897b08564a4ec@mail.gmail.com> References: <13dbfe4f0708191333k2efb72d5sdfe4579af9610fde@mail.gmail.com> <1187622016.7085.58.camel@localhost.localdomain> <13dbfe4f0708230501x6ba03b4fma83429921ba8ce3a@mail.gmail.com> <1187880765.1215.18.camel@localhost.localdomain> <13dbfe4f0708230835o5f6aed25p25c897b08564a4ec@mail.gmail.com> Message-ID: <1187892388.3230.1.camel@erebor.boston.redhat.com> On Thu, 2007-08-23 at 17:35 +0200, Chitlesh GOORAH wrote: > On 8/23/07, Jeremy Katz wrote: > > There's more than just the package being installed that's needed. You > > also need rhgb on the kernel command line. We don't do this on the live > > images because the last time I tried, even with rhgb installed, it > > didn't work. There was a problem with it not liking a lack > > of /etc/mtab, but even after I fixed that, it wasn't wanting to work. > > I've added rhgb on the kernel command line manually. it work. Rhgb > launches automatically. Okay, cool -- added logic to livecd-creator so that it'll do this automatically if you have rhgb installed Jeremy From lars.bjorndal at broadpark.no Fri Aug 24 10:23:49 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Fri, 24 Aug 2007 12:23:49 +0200 Subject: [Fedora-livecd-list] Error with Revisor Message-ID: Three days ago, I installed the GIT version of Revisor. Today, whil trying it out, I got the following error: Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 0.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 1.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: 2.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 3.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: # 4.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 5.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 6.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ## 7.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 8.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: ### 9.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 10.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 11.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: #### 12.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 13.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ##### 14.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 15.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 16.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ###### 17.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 18.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ####### 19.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 20.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 21.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######## 22.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 23.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ######### 24.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 25.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 26.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########## 27.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 28.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ########### 29.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 30.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 31.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############ 32.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 33.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############# 34.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 35.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 36.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############## 37.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 38.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ############### 39.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 40.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 41.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################ 42.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 43.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################# 44.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 45.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 46.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################## 47.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 48.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: ################### 49.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 50.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 51.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: #################### 52.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 53.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ##################### 54.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 55.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 56.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ###################### 57.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 58.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ####################### 59.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 60.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 61.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################## 62.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 63.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ######################### 64.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 65.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 66.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################## 67.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 68.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ########################### 69.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 70.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 71.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################ 72.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 73.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################# 74.0%Resolving Dependencies: Resolving Dependencies: ############################## 75.0%Resolving Dependencies: Resolving Dependencies: ######################################## 100.0% Populating statistics: Populating statistics: 0.0%Traceback (most recent call last): File "/usr/sbin/revisor", line 288, in revisorBase.run() File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 47, in run self.base.lift_off() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 813, in lift_off self.check_dependencies(style=self.check_dependencies_no_conflicts) File "/usr/lib/python2.5/site-packages/revisor/base.py", line 565, in check_dependencies self.populate_stats() File "/usr/lib/python2.5/site-packages/revisor/base.py", line 844, in populate_stats installsize += pkg.po.installedsize File "/usr/lib/python2.5/site-packages/yum/packages.py", line 725, in __getattr__ return self.hdr[thing] KeyError: 'unknown header tag' What should I do to solve this? Lars From kanarip at kanarip.com Fri Aug 24 10:41:09 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 24 Aug 2007 12:41:09 +0200 Subject: [Fedora-livecd-list] Error with Revisor In-Reply-To: References: Message-ID: <46CEB5C5.8000504@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Bj?rndal wrote: > Three days ago, I installed the GIT version of Revisor. Today, whil > trying it out, I got the following error: [...snip...] > Populating statistics: Populating statistics: 0.0%Traceback (most recent call last): > File "/usr/sbin/revisor", line 288, in > revisorBase.run() > File "/usr/lib/python2.5/site-packages/revisor/cli.py", line 47, in run > self.base.lift_off() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 813, in lift_off > self.check_dependencies(style=self.check_dependencies_no_conflicts) > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 565, in check_dependencies > self.populate_stats() > File "/usr/lib/python2.5/site-packages/revisor/base.py", line 844, in populate_stats > installsize += pkg.po.installedsize > File "/usr/lib/python2.5/site-packages/yum/packages.py", line 725, in __getattr__ > return self.hdr[thing] > KeyError: 'unknown header tag' > > What should I do to solve this? > > Lars > Next time please strip your message of any non-relevant details (such as a million lines just saying "Resolving Dependencies". This has been fixed in GIT already, it seems not all RPMs have installedsize headers/metadata. New code snippet: - ---- try: pkgsize += pkg.po.packagesize except KeyError, e: self.log.debug(_("Package %s-%s:%s-%s.%s does not seem to have a package size header") % (pkg.po.name, pkg.po.epoch, pkg.po.version, pkg.po.release, pkg.po.arch)) try: installsize += pkg.po.installedsize except KeyError, e: self.log.debug(_("Package %s-%s:%s-%s.%s does not seem to have a package size header") % (pkg.po.name, pkg.po.epoch, pkg.po.version, pkg.po.release, pkg.po.arch)) - ---- - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGzrXEKN6f2pNCvwgRAo4SAKCYd//O7VqzR0al2f1G5AeIhLO9fQCeJ0cN H3LRR3QnEMeXFVmj8U7/xnk= =B/gj -----END PGP SIGNATURE----- From lars.bjorndal at broadpark.no Fri Aug 24 13:35:46 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Fri, 24 Aug 2007 15:35:46 +0200 Subject: [Fedora-livecd-list] Error with Revisor In-Reply-To: <46CEB5C5.8000504@kanarip.com> References: <46CEB5C5.8000504@kanarip.com> Message-ID: <20070824133546.GI10130@lamasti.net> On Fri, Aug 24, 2007 at 12:41:09PM +0200, Jeroen van Meeuwen wrote: > Lars Bj?rndal wrote: > > Three days ago, I installed the GIT version of Revisor. Today, whil > > trying it out, I got the following error: > > [...snip...] > > Populating statistics: > [...] > Next time please strip your message of any non-relevant details (such as > a million lines just saying "Resolving Dependencies". Oh yes, I'm sorry. That was a mistake. > This has been fixed in GIT already, it seems not all RPMs have > installedsize headers/metadata. It seems to work now, with todays GIT version. Thank you! Lars From walters at redhat.com Fri Aug 24 22:09:48 2007 From: walters at redhat.com (Colin Walters) Date: Fri, 24 Aug 2007 18:09:48 -0400 Subject: [Fedora-livecd-list] [PATCH] Re: local caching In-Reply-To: References: Message-ID: Ok just to repost - here's the current delta to livecd-creator that I can't live without. The first part is answering "Why is my network pegged?" (though does anyone know if there's a nice way to use something like Wireshark to get this info?) The second is defaulting to a persistent cache for downloads. This is not protected against concurrent execution - should we go ahead and add a --nocache option for those people who have a local fedora mirror? Finally one random tip unrelated to this mail: use "ionice -c3 livecd-creator [OPTIONS]" if you're actually trying to use your laptop at the same time yum is making your CD. I wonder if it would make sense to just do this by default in yum? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6d4a897b468067cd93b2e185720e465a39c3bb8a.patch Type: text/x-patch Size: 2447 bytes Desc: not available URL: From lars.bjorndal at broadpark.no Sat Aug 25 11:36:45 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sat, 25 Aug 2007 13:36:45 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. Message-ID: Hi! With yesterday's GIT version of Revisor, I got the following error message: Downloading Packages: Filesystem label=livecd-20070825 OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 325120 inodes, 649728 blocks 6497 blocks (1.00%) reserved for the super user First data block=0 Maximum filesystem blocks=666894336 20 block groups 32768 blocks per group, 32768 fragments per group 16256 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Writing inode tables: Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 38 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. tune2fs 1.40.2 (12-Jul-2007) Setting maximal mount count to -1 Setting interval between checks to 0 seconds Cannot setup installation target. Aborting. Do you want to continue? [Y/n] y What's wrong here, do you think? Lars From kanarip at kanarip.com Sat Aug 25 13:01:36 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 25 Aug 2007 15:01:36 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: References: Message-ID: <46D02830.90305@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Bj?rndal wrote: > Hi! > > With yesterday's GIT version of Revisor, I got the following error message: > > Downloading Packages: > Filesystem label=livecd-20070825 > OS type: Linux > Block size=4096 (log=2) > Fragment size=4096 (log=2) > 325120 inodes, 649728 blocks > 6497 blocks (1.00%) reserved for the super user > First data block=0 > Maximum filesystem blocks=666894336 > 20 block groups > 32768 blocks per group, 32768 fragments per group > 16256 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912 > > Writing inode tables: > Creating journal (16384 blocks): done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 38 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > tune2fs 1.40.2 (12-Jul-2007) > Setting maximal mount count to -1 > Setting interval between checks to 0 seconds > Cannot setup installation target. Aborting. > Do you want to continue? [Y/n] y > > What's wrong here, do you think? > > Lars > There was an error in this as I recall, and I was under the impression I got it fixed. I'll test again and come back to this. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG0CgvKN6f2pNCvwgRAr/AAJwLM08rFdaTJtrHnpsikWTUeduAywCfWI1s wcthksVIghjW0Et7iw3T+/s= =B/an -----END PGP SIGNATURE----- From lars.bjorndal at broadpark.no Sat Aug 25 15:23:10 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sat, 25 Aug 2007 17:23:10 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D02830.90305@kanarip.com> References: <46D02830.90305@kanarip.com> Message-ID: <20070825152310.GB4485@lamasti.net> On l?r, aug 25, 2007 at 03:01:36 +0200, Jeroen van Meeuwen wrote: > Lars Bj?rndal wrote: > > Hi! > > > > With yesterday's GIT version of Revisor, I got the following error message: > > > > Downloading Packages: > > Filesystem label=livecd-20070825 > > OS type: Linux > > Block size=4096 (log=2) > > Fragment size=4096 (log=2) > > 325120 inodes, 649728 blocks > > 6497 blocks (1.00%) reserved for the super user > > First data block=0 > > Maximum filesystem blocks=666894336 > > 20 block groups > > 32768 blocks per group, 32768 fragments per group > > 16256 inodes per group > > Superblock backups stored on blocks: > > 32768, 98304, 163840, 229376, 294912 > > > > Writing inode tables: > > Creating journal (16384 blocks): done > > Writing superblocks and filesystem accounting information: done > > > > This filesystem will be automatically checked every 38 mounts or > > 180 days, whichever comes first. Use tune2fs -c or -i to override. > > tune2fs 1.40.2 (12-Jul-2007) > > Setting maximal mount count to -1 > > Setting interval between checks to 0 seconds > > Cannot setup installation target. Aborting. > > Do you want to continue? [Y/n] y > > > > What's wrong here, do you think? > > > > Lars > > > > There was an error in this as I recall, and I was under the impression I > got it fixed. I'll test again and come back to this. Thank you! Could it be related to Livecd-tools, and not to Revisor? Lars From kanarip at kanarip.com Sat Aug 25 15:36:42 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sat, 25 Aug 2007 17:36:42 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <20070825152310.GB4485@lamasti.net> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> Message-ID: <46D04C8A.5010209@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Bj?rndal wrote: > On l?r, aug 25, 2007 at 03:01:36 +0200, Jeroen van Meeuwen wrote: >> Lars Bj?rndal wrote: >>> Hi! >>> >>> With yesterday's GIT version of Revisor, I got the following error message: >>> >>> Downloading Packages: >>> Filesystem label=livecd-20070825 >>> OS type: Linux >>> Block size=4096 (log=2) >>> Fragment size=4096 (log=2) >>> 325120 inodes, 649728 blocks >>> 6497 blocks (1.00%) reserved for the super user >>> First data block=0 >>> Maximum filesystem blocks=666894336 >>> 20 block groups >>> 32768 blocks per group, 32768 fragments per group >>> 16256 inodes per group >>> Superblock backups stored on blocks: >>> 32768, 98304, 163840, 229376, 294912 >>> >>> Writing inode tables: >>> Creating journal (16384 blocks): done >>> Writing superblocks and filesystem accounting information: done >>> >>> This filesystem will be automatically checked every 38 mounts or >>> 180 days, whichever comes first. Use tune2fs -c or -i to override. >>> tune2fs 1.40.2 (12-Jul-2007) >>> Setting maximal mount count to -1 >>> Setting interval between checks to 0 seconds >>> Cannot setup installation target. Aborting. >>> Do you want to continue? [Y/n] y >>> >>> What's wrong here, do you think? >>> >>> Lars >>> >> There was an error in this as I recall, and I was under the impression I >> got it fixed. I'll test again and come back to this. > > Thank you! > > Could it be related to Livecd-tools, and not to Revisor? > > Lars > My guess is the error is in Revisor ;-) - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG0EyJKN6f2pNCvwgRAj8DAJ99EbOPTkcUuayke9eTH1zx36d0HQCfW+O2 CaATeyDiS/uUC7lrJjMzwuw= =CAdN -----END PGP SIGNATURE----- From jsteer at bitscout.com Sat Aug 25 21:19:56 2007 From: jsteer at bitscout.com (Jon Steer) Date: Sat, 25 Aug 2007 17:19:56 -0400 Subject: [Fedora-livecd-list] /etc/statetab and persistence Message-ID: <74e6f65d0708251419k42e64784o2c06d63b41f95e29@mail.gmail.com> I just noticed that there is apparently a /etc/statetab which allows you to specify directory paths to load from other sources upon bootup. So, on a liveCD,mounting /etc or mounting /var on another partition, especially on USB keys would work pretty handily. What am I missing? jon - From dmc.fedora at filteredperception.org Sat Aug 25 23:39:28 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Sat, 25 Aug 2007 18:39:28 -0500 Subject: [Fedora-livecd-list] /etc/statetab and persistence In-Reply-To: <74e6f65d0708251419k42e64784o2c06d63b41f95e29@mail.gmail.com> References: <74e6f65d0708251419k42e64784o2c06d63b41f95e29@mail.gmail.com> Message-ID: <46D0BDB0.8050909@filteredperception.org> Jon Steer wrote: > I just noticed that there is apparently a /etc/statetab which allows > you to specify directory paths to load from other sources upon bootup. > > So, on a liveCD,mounting /etc or mounting /var on another partition, > especially on USB keys would work pretty handily. > > What am I missing? Well, the statetab presumably must live on a version of /etc that gets mounted over then. And in the livecd case, you wouldn't want the initial statetab to point somewhere else for /etc. And given that, it is kind of hard to modify after the fact. But it wouldn't be hard at all to have some sort of kernel argument like "statetab="/etc:/dev/sdb2,/var:/dev/sdb3" or maybe with a little more work, statetab="/etc:LABEL="myipodstate":/path/to/etc" which would cause it to mount -t auto the filesystem labeled 'myipodstate' and then bindmount /path/to/etc from there to /etc. The main downside I see over what I've been trying to do with dm-snapshot, is that a) you would have to store the entire /etc on the persistent storage. b) /usr would then not be persistent, thus making 'yum -y install emacs' not work like you want it to. But for a subset of the problem, it definitely works. And as mentioned before, another dirt simple solution would be to just have tarballs stored on a usbstick, and then have the boot process extract them into the ram overlay automatically if it finds them. That also would be a quick and dirty way to accomplish a lot of things. -dmc From kanarip at kanarip.com Sun Aug 26 10:54:05 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 26 Aug 2007 12:54:05 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D04C8A.5010209@kanarip.com> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> Message-ID: <46D15BCD.3000905@kanarip.com> Jeroen van Meeuwen wrote: > Lars Bj?rndal wrote: >> On l?r, aug 25, 2007 at 03:01:36 +0200, Jeroen van Meeuwen wrote: >>> Lars Bj?rndal wrote: >>>> Hi! >>>> >>>> With yesterday's GIT version of Revisor, I got the following error message: >>>> >>>> Downloading Packages: >>>> Filesystem label=livecd-20070825 >>>> OS type: Linux >>>> Block size=4096 (log=2) >>>> Fragment size=4096 (log=2) >>>> 325120 inodes, 649728 blocks >>>> 6497 blocks (1.00%) reserved for the super user >>>> First data block=0 >>>> Maximum filesystem blocks=666894336 >>>> 20 block groups >>>> 32768 blocks per group, 32768 fragments per group >>>> 16256 inodes per group >>>> Superblock backups stored on blocks: >>>> 32768, 98304, 163840, 229376, 294912 >>>> >>>> Writing inode tables: >>>> Creating journal (16384 blocks): done >>>> Writing superblocks and filesystem accounting information: done >>>> >>>> This filesystem will be automatically checked every 38 mounts or >>>> 180 days, whichever comes first. Use tune2fs -c or -i to override. >>>> tune2fs 1.40.2 (12-Jul-2007) >>>> Setting maximal mount count to -1 >>>> Setting interval between checks to 0 seconds >>>> Cannot setup installation target. Aborting. >>>> Do you want to continue? [Y/n] y >>>> >>>> What's wrong here, do you think? >>>> >>>> Lars >>>> >>> There was an error in this as I recall, and I was under the impression I >>> got it fixed. I'll test again and come back to this. I didn't get this error running from either GIT or revisor-2.0.4.3-1rc1 (soon to land in the development repo). Can you reproduce from the latest GIT version? Kind regards, Jeroen van Meeuwen -kanarip From lars.bjorndal at broadpark.no Sun Aug 26 13:48:47 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sun, 26 Aug 2007 15:48:47 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D15BCD.3000905@kanarip.com> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> Message-ID: <20070826134847.GD4485@lamasti.net> On s?n, aug 26, 2007 at 12:54:05 +0200, Jeroen van Meeuwen wrote: > I didn't get this error running from either GIT or revisor-2.0.4.3-1rc1 > (soon to land in the development repo). Can you reproduce from the > latest GIT version? Yes, I can. I did a new GIT install today, and I got the same error message. Do you need my config files etc.? I use some files from my own repo, could that be a problem? What does the error message actually indicate? Lars From kanarip at kanarip.com Sun Aug 26 14:57:18 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 26 Aug 2007 16:57:18 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <20070826134847.GD4485@lamasti.net> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> Message-ID: <46D194CE.7020700@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Bj?rndal wrote: > On s?n, aug 26, 2007 at 12:54:05 +0200, Jeroen van Meeuwen wrote: >> I didn't get this error running from either GIT or revisor-2.0.4.3-1rc1 >> (soon to land in the development repo). Can you reproduce from the >> latest GIT version? > > Yes, I can. I did a new GIT install today, and I got the same error > message. Do you need my config files etc.? > > I use some files from my own repo, could that be a problem? What does > the error message actually indicate? > > Lars > Setting up the installation target is merely providing a loopmounted ext3 filesystem. You could check if the loopmount succeeds with commands mount and losetup -a. As I see it the debug verbosity should be raised because we can now not see what exactly goes wrong. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG0ZTOKN6f2pNCvwgRAmtNAJ9CLa11v60mHElUOt6qxFDSuC1WzwCfYeHN gK9Rxj5iWyEY8oaqPzdmfk0= =bmDf -----END PGP SIGNATURE----- From lars.bjorndal at broadpark.no Sun Aug 26 16:39:49 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Sun, 26 Aug 2007 18:39:49 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D194CE.7020700@kanarip.com> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> Message-ID: <20070826163949.GE4485@lamasti.net> On s?n, aug 26, 2007 at 04:57:18 +0200, Jeroen van Meeuwen wrote: > Lars Bj?rndal wrote: > > On s?n, aug 26, 2007 at 12:54:05 +0200, Jeroen van Meeuwen wrote: > >> I didn't get this error running from either GIT or revisor-2.0.4.3-1rc1 > >> (soon to land in the development repo). Can you reproduce from the > >> latest GIT version? > > > > Yes, I can. I did a new GIT install today, and I got the same error > > message. Do you need my config files etc.? > > > > I use some files from my own repo, could that be a problem? What does > > the error message actually indicate? > > > > Lars > > > > Setting up the installation target is merely providing a loopmounted > ext3 filesystem. You could check if the loopmount succeeds with commands > mount and losetup -a. As I see it the debug verbosity should be raised > because we can now not see what exactly goes wrong. Output from mount, after aborting, is: /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) /dev/proc on /proc type proc (rw) /dev/sys on /sys type sysfs (rw) /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) /dev/shm on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /dev/loop0 on / type ext3 (rw) - losetup -a /dev/loop0: [fd00]:97928 (/var/tmp/revisor-livecd/data/os.img) Lars From chitlesh at fedoraproject.org Sun Aug 26 21:23:07 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 26 Aug 2007 23:23:07 +0200 Subject: [Fedora-livecd-list] kickstart file for FEL Message-ID: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> Hello there, Here is some work about the Fedora Electronic Lab live image. http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks I would like to have some feedbacks about it and how to improve it. Will it be possible to spin a live image for FEL when F8T2 will be release? PS: I would like to give you a complete list of rpms installed on the livecd image. But however from today's rawhide, my spins are all broken with the following errors during the : file_contexts: invalid context system_u:object_r:games_exec_t:s0 file_contexts: invalid context system_u:object_r:games_exec_t:s0 Installing: filesystem #################### [ 3/723]file_contexts: invalid context system_u:object_r:games_data_t:s0 file_contexts: invalid context system_u:object_r:games_data_t:s0 Installing: ConsoleKit ################# [ 73/723]file_contexts: invalid context system_u:object_r:consolekit_exec_t:s0 Installing: GConf2 # [133/723]file_contexts: invalid context system_u:object_r:gconfd_exec_t:s0 Installing: pam [173/723]file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 Installing: usermode [183/723]file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 Installing: usermode # [183/723]file_contexts: invalid context system_u:object_r:userhelper_exec_t:s0 [..] Chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Sun Aug 26 21:44:38 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 26 Aug 2007 23:44:38 +0200 Subject: [Fedora-livecd-list] Re: kickstart file for FEL In-Reply-To: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> References: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> Message-ID: <13dbfe4f0708261444me11a691p209e8ad539d8cb79@mail.gmail.com> On 8/26/07, Chitlesh GOORAH wrote: > PS: I would like to give you a complete list of rpms installed on the > livecd image. But however from today's rawhide, my spins are all > broken with the following errors during the : > file_contexts: invalid context system_u:object_r:games_exec_t:s0 > > file_contexts: invalid context system_u:object_r:games_exec_t:s0 > Installing: filesystem #################### [ > 3/723]file_contexts: invalid context > system_u:object_r:games_data_t:s0 > file_contexts: invalid context system_u:object_r:games_data_t:s0 > Installing: ConsoleKit ################# [ > 73/723]file_contexts: invalid context > system_u:object_r:consolekit_exec_t:s0 > Installing: GConf2 # > [133/723]file_contexts: invalid context > system_u:object_r:gconfd_exec_t:s0 > Installing: pam > [173/723]file_contexts: invalid context > system_u:object_r:userhelper_conf_t:s0 > Installing: usermode > [183/723]file_contexts: invalid context > system_u:object_r:userhelper_conf_t:s0 > file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 > file_contexts: invalid context system_u:object_r:userhelper_conf_t:s0 > Installing: usermode # > [183/723]file_contexts: invalid context > system_u:object_r:userhelper_exec_t:s0 > [..] > > Chitlesh > -- > http://clunixchit.blogspot.com > Follow up of the errors I'm getting: Installing: synaptics ##################### [722/723] Installing: linuxwacom ##################### [723/723] Traceback (most recent call last): File "/usr/sbin/lokkit", line 53, in old_config = parseSELinuxArgs(selinux_args, options=old_config) File "/usr/share/system-config-firewall/fw_parser.py", line 167, in parseSELinuxArgs return _parse_args(parser, args, options) File "/usr/share/system-config-firewall/fw_parser.py", line 148, in _parse_args (_options, _args) = parser.parse_args(args, options) File "/usr/lib/python2.5/optparse.py", line 1378, in parse_args stop = self._process_args(largs, rargs, values) File "/usr/lib/python2.5/optparse.py", line 1418, in _process_args self._process_long_opt(rargs, values) File "/usr/lib/python2.5/optparse.py", line 1493, in _process_long_opt option.process(opt, value, values, self) File "/usr/lib/python2.5/optparse.py", line 782, in process self.action, self.dest, opt, value, values, parser) File "/usr/lib/python2.5/optparse.py", line 786, in take_action setattr(values, dest, value) AttributeError: 'list' object has no attribute 'selinux' Removing password for user root. passwd: Success -- http://clunixchit.blogspot.com From tve at voneicken.com Mon Aug 27 04:26:13 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Sun, 26 Aug 2007 21:26:13 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board Message-ID: <46D25265.9080904@voneicken.com> I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz fan-less VIA C3 Eden processor). With the distributed live-cd (Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts (i.e right after the initrd is unpacked). I built a custom i386 kernel with the VIA drivers and DMA turned off, which got the kernel to boot. The problem I then have is that when init should be executed, the system simply hangs and nothing happens. The last line printed is "Freeing unused kernel memory". I then built an entire livecd-fedora-minimal system from scratch and still no joy (same problem where init doesn't run). I then replaced init by a "hello world" program. If I statically link the hello world program it happily prints "hello world", but if I dynamically link it it doesn't. So it looks like /bin/bash (dynamically linked) doesn't run. At this point I'm at the end of my fedora wisdom. I have previously successfully booted a custom gentoo 2.6 kernel on this box, and the ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and would appreciate any suggestions either about what to try, or how to get debug information about what fails when running a dyn linked executable. Thanks! Thorsten NB: I was unsuccessful building the livecd-fedora-minimal system using the provided kickstart. I had to add the following packages so that livecd-creator could operate properly in the chrooted environment: nash, cpio, gzip, findutils, and squashfs-tools. From dmc.fedora at filteredperception.org Mon Aug 27 09:44:29 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Mon, 27 Aug 2007 04:44:29 -0500 Subject: [Fedora-livecd-list] livecd-tools question - "GTK+ installer!"? Message-ID: <46D29CFD.8060204@filteredperception.org> Can someone tell me what the final line in the livecd-tools TODO means. Under "Installer" - GTK+ installer! Does this mean de-integrating liveinst with anaconda? -dmc From gospo at redhat.com Mon Aug 27 14:08:51 2007 From: gospo at redhat.com (Andy Gospodarek) Date: Mon, 27 Aug 2007 10:08:51 -0400 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46D25265.9080904@voneicken.com> References: <46D25265.9080904@voneicken.com> Message-ID: <20070827140849.GY29579@gospo.rdu.redhat.com> On Sun, Aug 26, 2007 at 09:26:13PM -0700, Thorsten von Eicken wrote: > I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz > fan-less VIA C3 Eden processor). With the distributed live-cd > (Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts > (i.e right after the initrd is unpacked). > > I built a custom i386 kernel with the VIA drivers and DMA turned off, > which got the kernel to boot. The problem I then have is that when init > should be executed, the system simply hangs and nothing happens. The > last line printed is "Freeing unused kernel memory". > > I then built an entire livecd-fedora-minimal system from scratch and > still no joy (same problem where init doesn't run). I then replaced init > by a "hello world" program. If I statically link the hello world program > it happily prints "hello world", but if I dynamically link it it > doesn't. So it looks like /bin/bash (dynamically linked) doesn't run. > > At this point I'm at the end of my fedora wisdom. I have previously > successfully booted a custom gentoo 2.6 kernel on this box, and the > ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and > would appreciate any suggestions either about what to try, or how to get > debug information about what fails when running a dyn linked executable. > Was the other distros you tried specific i386 builds? I'm pretty sure the C3 doesn't support the full set of i686 extensions (I think it's basically an i586), so you would certainly have problems with the i686 kernel and were right to build an i386 one. I'm a little surprised you are having glibc problems however.... From katzj at redhat.com Mon Aug 27 14:49:04 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 10:49:04 -0400 Subject: [Fedora-livecd-list] /etc/statetab and persistence In-Reply-To: <46D0BDB0.8050909@filteredperception.org> References: <74e6f65d0708251419k42e64784o2c06d63b41f95e29@mail.gmail.com> <46D0BDB0.8050909@filteredperception.org> Message-ID: <1188226144.2365.33.camel@localhost.localdomain> On Sat, 2007-08-25 at 18:39 -0500, Douglas McClendon wrote: > Jon Steer wrote: > > I just noticed that there is apparently a /etc/statetab which allows > > you to specify directory paths to load from other sources upon bootup. > > > > So, on a liveCD,mounting /etc or mounting /var on another partition, > > especially on USB keys would work pretty handily. > > > > What am I missing? > > Well, the statetab presumably must live on a version of /etc that gets > mounted over then. And in the livecd case, you wouldn't want the > initial statetab to point somewhere else for /etc. And given that, it > is kind of hard to modify after the fact. > > But it wouldn't be hard at all to have some sort of kernel argument like > "statetab="/etc:/dev/sdb2,/var:/dev/sdb3" or maybe with a little more work, > > statetab="/etc:LABEL="myipodstate":/path/to/etc" > > which would cause it to mount -t auto the filesystem labeled > 'myipodstate' and then bindmount /path/to/etc from there to /etc. > > The main downside I see over what I've been trying to do with > dm-snapshot, is that > > a) you would have to store the entire /etc on the persistent storage. > b) /usr would then not be persistent, thus making 'yum -y install emacs' > not work like you want it to. > > But for a subset of the problem, it definitely works. Yeah, I'm not sure how well it really works for /etc or /var with the live image given those caveats. For /home it could work nicely, but really, at that point, you're almost better off just mounting something as /home. Which, I guess, points to a super-simple /home persistence that we could do... just add to the livecd initscript something like (excuse my terrible pseudo-shell here) if [ -e /dev/disk/by-label/$(ROOTLABEL)-home -a ! `strstr nohomepersist /proc/cmdline` ]; then mount /dev/disk/by-label/$(ROOTLABEL)-home /home fi It could even handle it being an encrypted device pretty easily since the support for referencing a luks device by label or UUID is in now iirc > And as mentioned before, another dirt simple solution would be to just > have tarballs stored on a usbstick, and then have the boot process > extract them into the ram overlay automatically if it finds them. That > also would be a quick and dirty way to accomplish a lot of things. Yeah, things like this definitely can work. They just (unfortunately) don't lend themselves to being very easily "discoverable" by more ordinary end-users Jeremy From katzj at redhat.com Mon Aug 27 14:58:45 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 10:58:45 -0400 Subject: [Fedora-livecd-list] kickstart file for FEL In-Reply-To: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> References: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> Message-ID: <1188226725.2365.41.camel@localhost.localdomain> On Sun, 2007-08-26 at 23:23 +0200, Chitlesh GOORAH wrote: > Here is some work about the Fedora Electronic Lab live image. > http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks > I would like to have some feedbacks about it and how to improve it. My first suggestion would be to try to have it %include livecd-fedora-base-desktop.ks; that way, it will have to duplicate a little bit less, making looking at the actual changes a little easier. But trying to extract out a diff, a few questions * You're not including the dial-up group -- that's needed for a lot of people to be able to get online, so it's probably worth including * admin-tools isn't required, but it is a nice to have. At the same time, I suspect the most important ones are pulled in via deps. The KDE specific changes I leave to someone who knows more than I do about KDE to talk about. svahl or rdieter? :) > Will it be possible to spin a live image for FEL when F8T2 will be release? Yeah, I can take on adding it to my list of ones to do I guess. x86 only? Hopefully for test3, we will be able to be doing the spins on a machine in the colo at which point, we can make it so that you can actually do the spin. But if not, one more doesn't break the bank so to speak for F8. > PS: I would like to give you a complete list of rpms installed on the > livecd image. But however from today's rawhide, my spins are all > broken with the following errors during the : Pointing at the bleeding edge repos on Friday late afternoon was giving me some ... interesting results. Once my workstation finishes upgrading, I'll be doing some test spins. Jeremy From katzj at redhat.com Mon Aug 27 15:01:56 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 11:01:56 -0400 Subject: [Fedora-livecd-list] livecd-tools question - "GTK+ installer!"? In-Reply-To: <46D29CFD.8060204@filteredperception.org> References: <46D29CFD.8060204@filteredperception.org> Message-ID: <1188226916.2365.45.camel@localhost.localdomain> On Mon, 2007-08-27 at 04:44 -0500, Douglas McClendon wrote: > Can someone tell me what the final line in the livecd-tools TODO means. > > Under "Installer" > > - GTK+ installer! > > Does this mean de-integrating liveinst with anaconda? No, this was about the installer stuff that davidz had started to write before I got anaconda to do the install. Given that nothing in that file is current, I've just gone ahead and removed it. Sorry for the confusion Jeremy From katzj at redhat.com Mon Aug 27 15:11:40 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 11:11:40 -0400 Subject: [Fedora-livecd-list] [PATCH] Re: local caching In-Reply-To: References: Message-ID: <1188227500.2365.52.camel@localhost.localdomain> On Fri, 2007-08-24 at 18:09 -0400, Colin Walters wrote: > Ok just to repost - here's the current delta to livecd-creator that I > can't live without. > > The first part is answering "Why is my network pegged?" (though does > anyone know if there's a nice way to use something like Wireshark to > get this info?) Don't know of a good way. But like I said with the first time you posted this, I'd much rather just one line per download rather than multiple. It's more inline with what yum, etc do and it also means less logs to slog through. > The second is defaulting to a persistent cache for downloads. This is > not protected against concurrent execution - should we go ahead and > add a --nocache option for those people who have a local fedora > mirror? Given the fact that concurrent operations will cause problems here and there's no real clean-up policy, I still think that a shared cache by default isn't the best idea. I'd be up for a cachedir that can then be pointed to a shared location if you as the person running know that you want to; but for the general case, I think it's a little too risky as it stands[1] Jeremy [1] Or, if everyone really wants shared cache, then the right thing to do is to probably use under /var/cache/yum and take the yum lock. Which means no software installation, updating, etc while running livecd-creator, but at least not another place to have to look for "where did my disk space go" From tve at voneicken.com Mon Aug 27 16:02:25 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 27 Aug 2007 09:02:25 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <20070827140849.GY29579@gospo.rdu.redhat.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> Message-ID: <46D2F591.8030203@voneicken.com> Andy Gospodarek wrote: > On Sun, Aug 26, 2007 at 09:26:13PM -0700, Thorsten von Eicken wrote: >> I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz >> fan-less VIA C3 Eden processor). With the distributed live-cd >> (Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts >> (i.e right after the initrd is unpacked). >> >> I built a custom i386 kernel with the VIA drivers and DMA turned off, >> which got the kernel to boot. The problem I then have is that when init >> should be executed, the system simply hangs and nothing happens. The >> last line printed is "Freeing unused kernel memory". >> >> I then built an entire livecd-fedora-minimal system from scratch and >> still no joy (same problem where init doesn't run). I then replaced init >> by a "hello world" program. If I statically link the hello world program >> it happily prints "hello world", but if I dynamically link it it >> doesn't. So it looks like /bin/bash (dynamically linked) doesn't run. >> >> At this point I'm at the end of my fedora wisdom. I have previously >> successfully booted a custom gentoo 2.6 kernel on this box, and the >> ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and >> would appreciate any suggestions either about what to try, or how to get >> debug information about what fails when running a dyn linked executable. >> > > Was the other distros you tried specific i386 builds? I'm pretty sure > the C3 doesn't support the full set of i686 extensions (I think it's > basically an i586), so you would certainly have problems with the i686 > kernel and were right to build an i386 one. I'm a little surprised you > are having glibc problems however.... Yes, the other distros were i386 builds, and yes, the C3 doesn't support the full i686 set. Do you have suggestions about how to figure out what's wrong with glibc? Or anything I could try to get all this to work? Thanks! Thorsten From gospo at redhat.com Mon Aug 27 17:15:16 2007 From: gospo at redhat.com (Andy Gospodarek) Date: Mon, 27 Aug 2007 13:15:16 -0400 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46D2F591.8030203@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> Message-ID: <20070827171515.GE29579@gospo.rdu.redhat.com> On Mon, Aug 27, 2007 at 09:02:25AM -0700, Thorsten von Eicken wrote: > Andy Gospodarek wrote: > >On Sun, Aug 26, 2007 at 09:26:13PM -0700, Thorsten von Eicken wrote: > >>I've been trying to boot the F7 live-cd on a VIA Epia M-6000 (600Mhz > >>fan-less VIA C3 Eden processor). With the distributed live-cd > >>(Fedora-7-Live-i686.iso) the machine resets as soon as the kernel starts > >>(i.e right after the initrd is unpacked). > >> > >>I built a custom i386 kernel with the VIA drivers and DMA turned off, > >>which got the kernel to boot. The problem I then have is that when init > >>should be executed, the system simply hangs and nothing happens. The > >>last line printed is "Freeing unused kernel memory". > >> > >>I then built an entire livecd-fedora-minimal system from scratch and > >>still no joy (same problem where init doesn't run). I then replaced init > >>by a "hello world" program. If I statically link the hello world program > >>it happily prints "hello world", but if I dynamically link it it > >>doesn't. So it looks like /bin/bash (dynamically linked) doesn't run. > >> > >>At this point I'm at the end of my fedora wisdom. I have previously > >>successfully booted a custom gentoo 2.6 kernel on this box, and the > >>ubuntu 6.06.1 system boots as well. I'd rather use fedora, though, and > >>would appreciate any suggestions either about what to try, or how to get > >>debug information about what fails when running a dyn linked executable. > >> > > > >Was the other distros you tried specific i386 builds? I'm pretty sure > >the C3 doesn't support the full set of i686 extensions (I think it's > >basically an i586), so you would certainly have problems with the i686 > >kernel and were right to build an i386 one. I'm a little surprised you > >are having glibc problems however.... > > Yes, the other distros were i386 builds, and yes, the C3 doesn't support > the full i686 set. Do you have suggestions about how to figure out > what's wrong with glibc? Or anything I could try to get all this to work? > Nothing is ringing a bell yet. I've been racking my brain trying to figure out why this has happened in the past. (I've seen this on other ARCHs, but I can't remember what I did to fix it.) Can you send out your .config from your kernel? I'm curious what the whole thing looks like, but in particular I wonder about this section: # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=m These are the defaults when doing a `make ARCH=i386 oldconfig` and are probably what you have, so this probably isn't the problem. Go ahead and sent the whole .config anyway and I'll take a look. From chitlesh at fedoraproject.org Mon Aug 27 23:07:42 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Aug 2007 01:07:42 +0200 Subject: [Fedora-livecd-list] livecd-fedora-base-desktop Message-ID: <13dbfe4f0708271607r1e13928jdbff73ca2d98db9f@mail.gmail.com> Hello there, #001: from livecd-fedora-base-desktop.ks repo --name=development --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch [..] # make sure debuginfo doesn't end up on the live image -*debuginfo In accordance to /etc/yum.repos.d/fedora-development.repo [development-debuginfo] name=Fedora - Development - Debug #baseurl=http://download.fedora.redhat.com/pub/fedora/linux/development/$basearch/debug/ mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide-debug&arch=$basearch enabled=0 gpgcheck=0 eventually -*debuginfo could be omitted. #002: is it @games required on the livecd-fedora-base-desktop ? shouldn't it rather be in the livecd-fedora-kde-desktop.ks or livecd-fedora-desktop.ks ? Chitlesh -- http://clunixchit.blogspot.com From katzj at redhat.com Tue Aug 28 01:15:03 2007 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Aug 2007 21:15:03 -0400 Subject: [Fedora-livecd-list] livecd-fedora-base-desktop In-Reply-To: <13dbfe4f0708271607r1e13928jdbff73ca2d98db9f@mail.gmail.com> References: <13dbfe4f0708271607r1e13928jdbff73ca2d98db9f@mail.gmail.com> Message-ID: <1188263703.22996.3.camel@localhost.localdomain> On Tue, 2007-08-28 at 01:07 +0200, Chitlesh GOORAH wrote: > #001: > from livecd-fedora-base-desktop.ks > > repo --name=development > --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch > [..] > # make sure debuginfo doesn't end up on the live image > -*debuginfo > eventually -*debuginfo could be omitted. The main reason it's there is if someone puts in the koji static repos repo or a few other cases, then you can end up with the -debuginfo getting pulled in. Sure, it's not likely, but I've been bit by it more than once now :-) > #002: > is it @games required on the livecd-fedora-base-desktop ? > shouldn't it rather be in the livecd-fedora-kde-desktop.ks or > livecd-fedora-desktop.ks ? Sure, could easily be moved if that makes things easier. And realistically, it probably makes sense to anyway since the kde config is already doing -gnome-games, which might as well mean that it's not selected there either. Jeremy From tve at voneicken.com Tue Aug 28 05:15:27 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Mon, 27 Aug 2007 22:15:27 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <20070827171515.GE29579@gospo.rdu.redhat.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> Message-ID: <46D3AF6F.4060107@voneicken.com> Andy Gospodarek wrote: > Nothing is ringing a bell yet. I've been racking my brain trying to > figure out why this has happened in the past. (I've seen this on other > ARCHs, but I can't remember what I did to fix it.) > > Can you send out your .config from your kernel? I'm curious what the > whole thing looks like, but in particular I wonder about this section: > > # > # Executable file formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > CONFIG_BINFMT_MISC=m > > These are the defaults when doing a `make ARCH=i386 oldconfig` and are > probably what you have, so this probably isn't the problem. Go ahead > and sent the whole .config anyway and I'll take a look. Looks just like you say: # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y Ok, so here's my kickstart file followed by the .config. Thanks for taking a look. Is there any debugging output I could turn on in the kernel? I'm happy to do some troubleshooting, I'm just a little lost right now about what could cause this. Thorsten ------------------------------------------------------------------- lang en_US.UTF-8 keyboard us timezone US/Pacific auth --useshadow --enablemd5 selinux --enforcing firewall --disabled # TODO: apparently calling it fedora-dev instead of a-dev makes things # not work. Perhaps it has something to do with the default repos in # /etc/yum.repos.d not getting properly disabled? repo --name=a-local --baseurl=file:///root/rpmbuild/RPMS/i386 repo --name=a-dev --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/r eleases/7/Everything/i386/os/ #repo --name=a-extras-dev --baseurl=http://download.fedora.redhat.com/pub/fedora /linux/extras/development/i386 %packages bash kernel-2.6.22.4epia syslinux passwd policycoreutils chkconfig authconfig rootfiles nash cpio gzip findutils squashfs-tools genisoimage ------------------------------------------------------------------- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22.4 # Sun Aug 26 13:39:57 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-epia" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_IPC_NS=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_UTS_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_MODULE_VERIFY_ELF=y # CONFIG_MODULE_SIG is not set CONFIG_MODULE_VERIFY=y CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set CONFIG_BLK_DEV_IO_TRACE=y # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Process debugging support # CONFIG_PTRACE=y CONFIG_UTRACE=y # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set CONFIG_MCYRIXIII=y # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_X86_UP_APIC is not set # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_NR_QUICK=1 # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set # CONFIG_SECCOMP is not set CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x400000 # CONFIG_COMPAT_VDSO is not set # # Power management options (ACPI, APM) # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_SLEEP_PROC_SLEEP=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=1999 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set # CONFIG_ACPI_SBS is not set CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set # CONFIG_APM_CPU_IDLE is not set # CONFIG_APM_DISPLAY_BLANK is not set # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_DEBUG=y # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m # # CPUFreq processor drivers # # CONFIG_X86_ACPI_CPUFREQ is not set # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set CONFIG_X86_LONGHAUL=y # CONFIG_X86_E_POWERSAVER is not set # # shared options # # CONFIG_X86_SPEEDSTEP_LIB is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_PCIEPORTBUS is not set # CONFIG_ARCH_SUPPORTS_MSI is not set CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=y CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=y # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set CONFIG_INET_TUNNEL=m # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=y CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m # CONFIG_TCP_CONG_HSTCP is not set # CONFIG_TCP_CONG_HYBLA is not set # CONFIG_TCP_CONG_VEGAS is not set # CONFIG_TCP_CONG_SCALABLE is not set # CONFIG_TCP_CONG_LP is not set # CONFIG_TCP_CONG_VENO is not set # CONFIG_TCP_CONG_YEAH is not set # CONFIG_TCP_CONG_ILLINOIS is not set # CONFIG_DEFAULT_BIC is not set CONFIG_DEFAULT_CUBIC=y # CONFIG_DEFAULT_HTCP is not set # CONFIG_DEFAULT_VEGAS is not set # CONFIG_DEFAULT_WESTWOOD is not set # CONFIG_DEFAULT_RENO is not set CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set CONFIG_LLC=m # CONFIG_LLC2 is not set # CONFIG_IPX is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=m # CONFIG_LTPC is not set # CONFIG_COPS is not set CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=y # CONFIG_AX25_DAMA_SLAVE is not set # CONFIG_NETROM is not set # CONFIG_ROSE is not set # # AX.25 network device drivers # CONFIG_MKISS=m # CONFIG_6PACK is not set # CONFIG_BPQETHER is not set # CONFIG_DMASCC is not set # CONFIG_SCC is not set # CONFIG_BAYCOM_SER_FDX is not set # CONFIG_BAYCOM_SER_HDX is not set # CONFIG_BAYCOM_PAR is not set # CONFIG_BAYCOM_EPP is not set # CONFIG_YAM is not set CONFIG_IRDA=y # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m # CONFIG_MA600_DONGLE is not set # CONFIG_GIRBIL_DONGLE is not set # CONFIG_MCP2120_DONGLE is not set # CONFIG_OLD_BELKIN_DONGLE is not set # CONFIG_ACT200L_DONGLE is not set # CONFIG_KINGSUN_DONGLE is not set # # Old SIR device drivers # # CONFIG_IRPORT_SIR is not set # # Old Serial dongle support # # # FIR device drivers # CONFIG_USB_IRDA=m # CONFIG_SIGMATEL_FIR is not set CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m # CONFIG_SMC_IRCC_FIR is not set # CONFIG_ALI_FIR is not set # CONFIG_VLSI_FIR is not set CONFIG_VIA_FIR=m # CONFIG_MCS_FIR is not set CONFIG_BT=y CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m # CONFIG_AF_RXRPC is not set # # Wireless # # CONFIG_CFG80211 is not set CONFIG_WIRELESS_EXT=y # CONFIG_MAC80211 is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m # CONFIG_IEEE80211_SOFTMAC is not set # CONFIG_RFKILL is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y # CONFIG_SYS_HYPERVISOR is not set # # Connector - unified userspace <-> kernelspace linker # CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_SERIAL=y # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_PC_PCMCIA is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set CONFIG_PNPACPI=y # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096 CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set # # Misc devices # # CONFIG_IBM_ASM is not set # CONFIG_PHANTOM is not set # CONFIG_EEPROM_93CX6 is not set # CONFIG_SGI_IOC4 is not set # CONFIG_TIFM_CORE is not set # CONFIG_ASUS_LAPTOP is not set # CONFIG_MSI_LAPTOP is not set # CONFIG_SONY_LAPTOP is not set # CONFIG_THINKPAD_ACPI is not set CONFIG_IDE=y CONFIG_BLK_DEV_IDE=m # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=m # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDECS is not set # CONFIG_BLK_DEV_DELKIN is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set CONFIG_BLK_DEV_IDEACPI=y # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set # CONFIG_IDEPCI_PCIBUS_ORDER is not set # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=m # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set # CONFIG_BLK_DEV_IDEDMA_PCI is not set # CONFIG_IDE_ARM is not set # CONFIG_IDE_CHIPSETS is not set # CONFIG_BLK_DEV_IDEDMA is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=m # CONFIG_SCSI_TGT is not set CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set # # SCSI low-level drivers # # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_3W_9XXX is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 CONFIG_AIC7XXX_DEBUG_ENABLE=y CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_STEX is not set CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_1280 is not set CONFIG_SCSI_QLA_FC=m # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set # # PCMCIA SCSI adapter support # # CONFIG_PCMCIA_AHA152X is not set # CONFIG_PCMCIA_FDOMAIN is not set # CONFIG_PCMCIA_NINJA_SCSI is not set # CONFIG_PCMCIA_QLOGIC is not set # CONFIG_PCMCIA_SYM53C500 is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_AHCI=m CONFIG_SATA_SVW=m CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SX4=m CONFIG_SATA_SIL=m CONFIG_SATA_SIL24=m CONFIG_SATA_SIS=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m CONFIG_SATA_INIC162X=m CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_CMD640_PCI=m CONFIG_PATA_CMD64X=m CONFIG_PATA_CS5520=m CONFIG_PATA_CS5530=m CONFIG_PATA_CS5535=m CONFIG_PATA_CYPRESS=m CONFIG_PATA_EFAR=m CONFIG_ATA_GENERIC=m CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m CONFIG_PATA_ISAPNP=m CONFIG_PATA_IT821X=m CONFIG_PATA_IT8213=m CONFIG_PATA_JMICRON=m CONFIG_PATA_LEGACY=m CONFIG_PATA_TRIFLEX=m CONFIG_PATA_MARVELL=m CONFIG_PATA_MPIIX=m CONFIG_PATA_OLDPIIX=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NS87410=m CONFIG_PATA_OPTI=m CONFIG_PATA_OPTIDMA=m CONFIG_PATA_PCMCIA=m CONFIG_PATA_PDC_OLD=m CONFIG_PATA_QDI=m CONFIG_PATA_RADISYS=m CONFIG_PATA_RZ1000=m CONFIG_PATA_SC1200=m CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_VIA=m CONFIG_PATA_WINBOND=m CONFIG_PATA_WINBOND_VLB=m # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set # CONFIG_DM_CRYPT is not set CONFIG_DM_SNAPSHOT=m # CONFIG_DM_MIRROR is not set # CONFIG_DM_ZERO is not set # CONFIG_DM_MULTIPATH is not set # CONFIG_DM_DELAY is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=y # # Subsystem Options # # CONFIG_IEEE1394_VERBOSEDEBUG is not set # # Controllers # # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=y # # Protocols # CONFIG_IEEE1394_VIDEO1394=y # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=y # # I2O device support # CONFIG_I2O=y # CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_CONFIG=y CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # CONFIG_MACINTOSH_DRIVERS is not set # # Network device support # CONFIG_NETDEVICES=y CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set CONFIG_PHYLIB=m # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m CONFIG_FIXED_PHY=m CONFIG_FIXED_MII_10_FDX=y CONFIG_FIXED_MII_100_FDX=y # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set # CONFIG_CASSINI is not set # CONFIG_NET_VENDOR_3COM is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set # CONFIG_CS89x0 is not set # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set # CONFIG_E100 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=y CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y # CONFIG_SC92031 is not set # CONFIG_NET_POCKET is not set # CONFIG_NETDEV_1000 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_B43_ADVICE_HACK is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET_MII is not set # CONFIG_USB_USBNET is not set # CONFIG_NET_PCMCIA is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set CONFIG_MOUSE_VSXXXAA=m # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_WISTRON_BTNS=m CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE=m CONFIG_INPUT_ATI_REMOTE2=m # CONFIG_INPUT_KEYSPAN_REMOTE is not set CONFIG_INPUT_POWERMATE=m # CONFIG_INPUT_YEALINK is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set CONFIG_SERIO_PCIPS2=y CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=y CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_CRASH=m # CONFIG_PRINTER is not set CONFIG_PPDEV=m # CONFIG_TIPAR is not set # # IPMI # # CONFIG_IPMI_HANDLER is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set CONFIG_IBMASR=m # CONFIG_WAFER_WDT is not set CONFIG_I6300ESB_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set CONFIG_W83627HF_WDT=m CONFIG_W83697HF_WDT=m CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # ISA-based Watchdog Cards # # CONFIG_PCWATCHDOG is not set # CONFIG_MIXCOMWD is not set # CONFIG_WDT is not set # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_INTEL is not set # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_GEODE is not set CONFIG_HW_RANDOM_VIA=y CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set # CONFIG_AGP_INTEL is not set # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set CONFIG_DRM_VIA=m # CONFIG_DRM_SAVAGE is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y # CONFIG_HPET_RTC_IRQ is not set # CONFIG_HPET_MMAP is not set CONFIG_HANGCHECK_TIMER=y # # TPM devices # # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=y # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y # CONFIG_I2C_ALGOPCF is not set CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set # CONFIG_I2C_ELEKTOR is not set # CONFIG_I2C_I801 is not set # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set CONFIG_I2C_ISA=y # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_STUB is not set # CONFIG_I2C_TINY_USB is not set # CONFIG_I2C_VIA is not set CONFIG_I2C_VIAPRO=y # CONFIG_I2C_VOODOO3 is not set # CONFIG_I2C_PCA_ISA is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set # CONFIG_SENSORS_EEPROM is not set # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_I2C_DEBUG_CHIP=y # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # # Dallas's 1-wire bus # CONFIG_W1=y CONFIG_W1_CON=y # # 1-wire Bus Masters # # CONFIG_W1_MASTER_MATROX is not set CONFIG_W1_MASTER_DS2490=y # CONFIG_W1_MASTER_DS2482 is not set # # 1-wire Slaves # # CONFIG_W1_SLAVE_THERM is not set # CONFIG_W1_SLAVE_SMEM is not set # CONFIG_W1_SLAVE_DS2433 is not set CONFIG_HWMON=y # CONFIG_HWMON_VID is not set # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set # CONFIG_SENSORS_PC87427 is not set # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set CONFIG_SENSORS_VIA686A=y # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set # CONFIG_SENSORS_W83793 is not set # CONFIG_SENSORS_W83L785TS is not set # CONFIG_SENSORS_W83627HF is not set # CONFIG_SENSORS_W83627EHF is not set # CONFIG_SENSORS_HDAPS is not set # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Sonics Silicon Backplane # # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_VIDEO_V4L2=y CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_HELPER_CHIPS_AUTO is not set # # Encoders/decoders and other helper chips # # # Audio decoders # CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_TDA9840=m CONFIG_VIDEO_TDA9875=m CONFIG_VIDEO_TEA6415C=m CONFIG_VIDEO_TEA6420=m CONFIG_VIDEO_MSP3400=m # CONFIG_VIDEO_CS53L32A is not set # CONFIG_VIDEO_TLV320AIC23B is not set # CONFIG_VIDEO_WM8775 is not set # CONFIG_VIDEO_WM8739 is not set # # Video decoders # CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m CONFIG_VIDEO_BT866=m CONFIG_VIDEO_KS0127=m CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA7111=m CONFIG_VIDEO_SAA7114=m # CONFIG_VIDEO_SAA711X is not set CONFIG_VIDEO_SAA7191=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_VPX3220=m # # Video and audio decoders # # CONFIG_VIDEO_CX25840 is not set # # MPEG video encoders # CONFIG_VIDEO_CX2341X=m # # Video encoders # # CONFIG_VIDEO_SAA7127 is not set CONFIG_VIDEO_SAA7185=m CONFIG_VIDEO_ADV7170=m CONFIG_VIDEO_ADV7175=m # # Video improvement chips # # CONFIG_VIDEO_UPD64031A is not set # CONFIG_VIDEO_UPD64083 is not set # CONFIG_VIDEO_VIVI is not set CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA6588=m # CONFIG_VIDEO_PMS is not set CONFIG_VIDEO_BWQCAM=m # CONFIG_VIDEO_CQCAM is not set CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_CPIA2=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_TUNER_3036=m # CONFIG_VIDEO_STRADIS is not set CONFIG_VIDEO_ZORAN_ZR36060=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m # CONFIG_VIDEO_ZORAN_AVS6EYES is not set CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m # CONFIG_VIDEO_CX88_ALSA is not set CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_VP3054=m # CONFIG_VIDEO_IVTV is not set CONFIG_VIDEO_CAFE_CCIC=m CONFIG_V4L_USB_DRIVERS=y # CONFIG_VIDEO_PVRUSB2 is not set CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_USBVISION=m CONFIG_VIDEO_USBVIDEO=m # CONFIG_USB_VICAM is not set CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_QUICKCAM_MESSENGER=m CONFIG_USB_ET61X251=m CONFIG_VIDEO_OVCAMCHIP=m CONFIG_USB_W9968CF=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_SN9C102=m CONFIG_USB_STV680=m CONFIG_USB_ZC0301=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_ZR364XX=m CONFIG_RADIO_ADAPTERS=y # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # CONFIG_USB_DSBR is not set CONFIG_DVB_CORE=m CONFIG_DVB_CORE_ATTACH=y CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_CINERGYT2=m CONFIG_DVB_CINERGYT2_TUNING=y CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32 CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512 CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250 CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100 # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported Pluto2 Adapters # CONFIG_DVB_PLUTO2=m # # Supported DVB Frontends # # # Customise DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # DVB-S (satellite) frontends # CONFIG_DVB_STV0299=m CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_TDA8083=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1X93=m CONFIG_DVB_S5H1420=m CONFIG_DVB_TDA10086=m # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m # # Tuners/PLL support # CONFIG_DVB_PLL=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TDA827X=m CONFIG_DVB_TUNER_QT1010=m CONFIG_DVB_TUNER_MT2060=m # # Miscellaneous devices # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6421=m CONFIG_DVB_TUA6100=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m CONFIG_VIDEO_TVEEPROM=m CONFIG_DAB=y CONFIG_USB_DABUSB=m # # Graphics support # CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set CONFIG_VGASTATE=y CONFIG_FB=y # CONFIG_FIRMWARE_EDID is not set # CONFIG_FB_DDC is not set CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m CONFIG_FB_SYS_FOPS=m CONFIG_FB_DEFERRED_IO=y CONFIG_FB_SVGALIB=y # CONFIG_FB_MACMODES is not set # CONFIG_FB_BACKLIGHT is not set CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set # CONFIG_FB_ARC is not set # CONFIG_FB_ASILIANT is not set # CONFIG_FB_IMSTT is not set # CONFIG_FB_VGA16 is not set CONFIG_FB_VESA=y # CONFIG_FB_HECUBA is not set # CONFIG_FB_HGA is not set # CONFIG_FB_S1D13XXX is not set # CONFIG_FB_NVIDIA is not set # CONFIG_FB_RIVA is not set # CONFIG_FB_I810 is not set # CONFIG_FB_LE80578 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_MATROX is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set # CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_KYRO is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set CONFIG_FB_VT8623=y # CONFIG_FB_CYBLA is not set # CONFIG_FB_TRIDENT is not set # CONFIG_FB_ARK is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_GEODE is not set # CONFIG_FB_VIRTUAL is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_RTCTIMER is not set CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m # CONFIG_SND_MTPAV is not set # CONFIG_SND_MTS64 is not set # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m # # ISA devices # # CONFIG_SND_ADLIB is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set # CONFIG_SND_CS4236 is not set # CONFIG_SND_DT019X is not set # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set # CONFIG_SND_ES18XX is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPL3SA2 is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_MIRO is not set # CONFIG_SND_SB8 is not set CONFIG_SND_SB16=m CONFIG_SND_SBAWE=m # CONFIG_SND_SB16_CSP is not set # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # CONFIG_SND_WAVEFRONT is not set # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AZT3328 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set # CONFIG_SND_HDA_INTEL is not set # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # CONFIG_SND_AC97_POWER_SAVE is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_AC97_BUS=m # # HID Devices # CONFIG_HID=y # CONFIG_HID_DEBUG is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set CONFIG_USB_HIDDEV=y # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # # USB support # CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_SPLIT_ISO is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_EHCI_TT_NEWSCHED is not set # CONFIG_USB_EHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_ISP116X_HCD=m CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m CONFIG_USB_SL811_HCD=m CONFIG_USB_SL811_CS=m # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set CONFIG_USB_STORAGE_FREECOM=y # CONFIG_USB_STORAGE_ISD200 is not set CONFIG_USB_STORAGE_DPCM=y # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set CONFIG_USB_MON=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y # CONFIG_USB_SERIAL_AIRCABLE is not set CONFIG_USB_SERIAL_AIRPRIME=m # CONFIG_USB_SERIAL_ARK3116 is not set CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set CONFIG_USB_SERIAL_EMPEG=m # CONFIG_USB_SERIAL_FTDI_SIO is not set CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m # CONFIG_USB_SERIAL_IR is not set CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m # CONFIG_USB_SERIAL_IPW is not set CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y # CONFIG_USB_SERIAL_KLSI is not set CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_HP4X=m # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m # CONFIG_USB_SERIAL_CYBERJACK is not set CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m # CONFIG_USB_SERIAL_OMNINET is not set CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set # # LED devices # CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m # CONFIG_LEDS_TRIGGER_IDE_DISK is not set CONFIG_LEDS_TRIGGER_HEARTBEAT=m # # InfiniBand support # # CONFIG_INFINIBAND is not set # # EDAC - error detection and reporting (RAS) (EXPERIMENTAL) # # CONFIG_EDAC is not set # # Real Time Clock # # CONFIG_RTC_CLASS is not set # # DMA Engine support # CONFIG_DMA_ENGINE=y # # DMA Clients # CONFIG_NET_DMA=y # # DMA Devices # CONFIG_INTEL_IOATDMA=m # # Auxiliary Display support # CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=m CONFIG_CFAG12864B_RATE=20 # # Virtualization # # CONFIG_KVM is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y # CONFIG_EXT2_FS_POSIX_ACL is not set # CONFIG_EXT2_FS_SECURITY is not set CONFIG_EXT2_FS_XIP=y CONFIG_FS_XIP=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y # CONFIG_EXT3_FS_POSIX_ACL is not set # CONFIG_EXT3_FS_SECURITY is not set # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=m # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y # CONFIG_XFS_FS is not set # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=y CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set CONFIG_CRAMFS=y CONFIG_SQUASHFS=m # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 # CONFIG_SQUASHFS_VMALLOC is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y # CONFIG_NFSD is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y # CONFIG_SUNRPC_BIND34 is not set # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set CONFIG_SMB_FS=y # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=y # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_WEAK_PW_HASH is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # CONFIG_9P_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set CONFIG_EFI_PARTITION=y # CONFIG_SYSV68_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Distributed Lock Manager # # CONFIG_DLM is not set # # Instrumentation Support # # CONFIG_PROFILING is not set # CONFIG_KPROBES is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_DEBUG_IGNORE_QUIET=y CONFIG_PRINTK_TIME=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set CONFIG_DEBUG_FS=y CONFIG_HEADERS_CHECK=y # CONFIG_DEBUG_KERNEL is not set CONFIG_DEBUG_NMI_TIMEOUT=5 CONFIG_DEBUG_BUGVERBOSE=y CONFIG_EARLY_PRINTK=y CONFIG_DOUBLEFAULT=y # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y # CONFIG_CRYPTO_XCBC is not set CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_TGR192=m # CONFIG_CRYPTO_GF128MUL is not set CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_PCBC=m # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_CAMELLIA=m # CONFIG_CRYPTO_TEST is not set CONFIG_CRYPTO_MPILIB=y CONFIG_CRYPTO_SIGNATURE=y CONFIG_CRYPTO_SIGNATURE_DSA=y # # Hardware crypto devices # CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_CRYPTO_DEV_GEODE=m # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y CONFIG_CRC16=y CONFIG_CRC_ITU_T=y CONFIG_CRC32=y CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_X86_BIOS_REBOOT=y CONFIG_KTIME_SCALAR=y From ml at deadbabylon.de Tue Aug 28 07:23:06 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 28 Aug 2007 09:23:06 +0200 Subject: [Fedora-livecd-list] livecd-fedora-base-desktop In-Reply-To: <1188263703.22996.3.camel@localhost.localdomain> References: <13dbfe4f0708271607r1e13928jdbff73ca2d98db9f@mail.gmail.com> <1188263703.22996.3.camel@localhost.localdomain> Message-ID: <20070828092306.0e270773@localhost.localdomain> Am Mon, 27 Aug 2007 21:15:03 -0400 schrieb Jeremy Katz : > On Tue, 2007-08-28 at 01:07 +0200, Chitlesh GOORAH wrote: > > > #002: > > is it @games required on the livecd-fedora-base-desktop ? > > shouldn't it rather be in the livecd-fedora-kde-desktop.ks or > > livecd-fedora-desktop.ks ? > > Sure, could easily be moved if that makes things easier. And > realistically, it probably makes sense to anyway since the kde config > is already doing -gnome-games, which might as well mean that it's not > selected there either. Yeah. gnome-games is default in @games (kdegames is just "optional") but we don't need this package on the kde cd. :) +1 to move it to livecd-fedora-desktop.ks Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Tue Aug 28 09:18:12 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Aug 2007 11:18:12 +0200 Subject: [Fedora-livecd-list] livecd-fedora-base-desktop In-Reply-To: <1188263703.22996.3.camel@localhost.localdomain> References: <13dbfe4f0708271607r1e13928jdbff73ca2d98db9f@mail.gmail.com> <1188263703.22996.3.camel@localhost.localdomain> Message-ID: <13dbfe4f0708280218i4b2c9b69ud1b3e422084e59f3@mail.gmail.com> On 8/28/07, Jeremy Katz wrote: > The main reason it's there is if someone puts in the koji static repos > repo or a few other cases, then you can end up with the -debuginfo > getting pulled in. True. Then leave it like it is. Also it doesn't hurt anyone or anything. Chitlesh -- http://clunixchit.blogspot.com From ml at deadbabylon.de Tue Aug 28 12:25:54 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 28 Aug 2007 14:25:54 +0200 Subject: [Fedora-livecd-list] Traceback with newest yum Message-ID: <20070828142554.28bca622@htpc> Hi. With newest yum and yum-metadata-parser I got the following traceback when starting livecd-creator: > /usr/lib/python2.5/site-packages/pykickstart/parser.py:600: > DeprecationWarning: Script does not end with %end. This syntax has > been deprecated. It may be removed from future releases, which will > result in a fatal error from kickstart. Please modify your kickstart > file to use this updated syntax. warnings.warn(_("%s does not end > with %%end. This syntax has been deprecated. It may be removed from > future releases, which will result in a fatal error from kickstart. > Please modify your kickstart file to use this updated syntax.") % > _("Script"), DeprecationWarning) mke2fs 1.40.2 (12-Jul-2007) > Filesystem label=F8-KDE-17 OS type: Linux Block size=4096 (log=2) > Fragment size=4096 (log=2) 524288 inodes, 1048576 blocks 10485 blocks > (1.00%) reserved for the super user First data block=0 Maximum > filesystem blocks=1073741824 32 block groups 32768 blocks per group, > 32768 fragments per group 16384 inodes per group > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376, 294912, 819200, 884736 > > Writing inode tables: done > Creating journal (32768 blocks): done > Writing superblocks and filesystem accounting information: done > > This filesystem will be automatically checked every 28 mounts or > 180 days, whichever comes first. Use tune2fs -c or -i to override. > tune2fs 1.40.2 (12-Jul-2007) > Setting maximal mount count to -1 > Setting interval between checks to 0 seconds > No Repositories Available to Set Up > No Repositories Available to Set Up > No such package *debuginfo to remove > Traceback (most recent call last): > File "/usr/bin/livecd-creator", line 1383, in > sys.exit(main()) > File "/usr/bin/livecd-creator", line 1361, in main > target.install() > File "/usr/bin/livecd-creator", line 858, in install > self.installPackages() > File "/usr/bin/livecd-creator", line 550, in installPackages > self.ayum.runInstall() > File "/usr/bin/livecd-creator", line 295, in runInstall > (res, resmsg) = self.buildTransaction() > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 557, > in buildTransaction (rescode, restring) = self.resolveDeps() > File "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 701, > in resolveDeps CheckDeps, checkremoves, checkinstalls, missing = > self._resolveRequires(errors) File > "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 781, in > _resolveRequires (checkdep, missing, errormsgs) = > self._processReq(po, dep) File > "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 250, in > _processReq CheckDeps, missingdep = > self._requiringFromTransaction(po, requirement, errormsgs) File > "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 496, in > _requiringFromTransaction reqpkg = self.rpmdb.searchNevra(name=name, > ver=version, rel=release)[0] IndexError: list index out of range The latest rawhide version I got here locally is yum-3.2.2-3.fc8 and yum-metadata-parser-1.1.0-2.fc7. With them all is working fine. Is this a problem with livecd-tools? If so I will file a bug against it. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Aug 28 12:32:12 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 28 Aug 2007 14:32:12 +0200 Subject: [Fedora-livecd-list] Some problems: rootpassword and liveinst Message-ID: <20070828143212.104a8a8f@htpc> Hi. My actual spin of the kde livecd from today has some problems: 1. It seems that the root password wasn't erased. If I boot the iso in vmware I got the error in the attached screenshot. If I boot the iso with enforcing=0 all is working. Is this a problem on my local machine (if relabeld the whole filesystem before I tested this)? 2. Because of 1. I've bootet with enforcing=0. If I then want to start liveinst I get this traceback: > [root at localhost ~]# liveinst > FATAL: Module md not found. > Traceback (most recent call last): > File "/usr/sbin/anaconda", line 550, in > import signal, traceback, string, isys, iutil, time > File "/usr/lib/anaconda/isys.py", line 33, in > import block > File "/usr/lib/python2.5/site-packages/block/__init__.py", line 20, > in import dm > ImportError: /usr/lib/python2.5/site-packages/block/dmmodule.so: > undefined symbol: dm_task_get_uuid Any suggestions or more info needed? Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: livecd-root-password.png Type: image/png Size: 12695 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From chitlesh at fedoraproject.org Tue Aug 28 13:16:51 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 28 Aug 2007 15:16:51 +0200 Subject: [Fedora-livecd-list] Some problems: rootpassword and liveinst In-Reply-To: <20070828143212.104a8a8f@htpc> References: <20070828143212.104a8a8f@htpc> Message-ID: <13dbfe4f0708280616x3b821868j98fb8fcf6e77ef04@mail.gmail.com> On 8/28/07, Sebastian Vahl wrote: > Hi. > > My actual spin of the kde livecd from today has some problems: > > 1. It seems that the root password wasn't erased. If I boot the iso in > vmware I got the error in the attached screenshot. If I boot the iso > with enforcing=0 all is working. Is this a problem on my local machine > (if relabeld the whole filesystem before I tested this)? > > 2. Because of 1. I've bootet with enforcing=0. If I then want to start > liveinst I get this traceback: I'm experiencing the same issue as mentioned above. Chitlesh -- http://clunixchit.blogspot.com From lars.bjorndal at broadpark.no Tue Aug 28 13:17:40 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Tue, 28 Aug 2007 15:17:40 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <20070826163949.GE4485@lamasti.net> (Lars =?iso-8859-1?Q?Bj?= =?iso-8859-1?Q?=F8rndal's?= message of "Sun, 26 Aug 2007 18:39:49 +0200") References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> Message-ID: Lars Bj?rndal writes: > On s?n, aug 26, 2007 at 04:57:18 +0200, Jeroen van Meeuwen wrote: >> Lars Bj?rndal wrote: >> > On s?n, aug 26, 2007 at 12:54:05 +0200, Jeroen van Meeuwen wrote: >> >> I didn't get this error running from either GIT or revisor-2.0.4.3-1rc1 >> >> (soon to land in the development repo). Can you reproduce from the >> >> latest GIT version? >> > >> > Yes, I can. I did a new GIT install today, and I got the same error >> > message. Do you need my config files etc.? >> > >> > I use some files from my own repo, could that be a problem? What does >> > the error message actually indicate? >> > >> > Lars >> > >> >> Setting up the installation target is merely providing a loopmounted >> ext3 filesystem. You could check if the loopmount succeeds with commands >> mount and losetup -a. As I see it the debug verbosity should be raised >> because we can now not see what exactly goes wrong. > > Output from mount, after aborting, is: > > /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) > /dev/proc on /proc type proc (rw) > /dev/sys on /sys type sysfs (rw) > /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) > /dev/sda1 on /boot type ext3 (rw) > /dev/shm on /dev/shm type tmpfs (rw) > none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) > /dev/loop0 on / type ext3 (rw) > > - losetup -a > /dev/loop0: [fd00]:97928 (/var/tmp/revisor-livecd/data/os.img) Hello! What could I do to go on solving this problem, do you think? Lars From katzj at redhat.com Tue Aug 28 14:01:00 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 28 Aug 2007 10:01:00 -0400 Subject: [Fedora-livecd-list] Traceback with newest yum In-Reply-To: <20070828142554.28bca622@htpc> References: <20070828142554.28bca622@htpc> Message-ID: <1188309660.17567.5.camel@localhost.localdomain> On Tue, 2007-08-28 at 14:25 +0200, Sebastian Vahl wrote: > With newest yum and yum-metadata-parser I got the following traceback > when starting livecd-creator: > > > /usr/lib/python2.5/site-packages/pykickstart/parser.py:600: > > DeprecationWarning: Script does not end with %end. This is just a warning, but I will be updating the configs in .git later for this. With this change in pykickstart, you can now %include fedora-base-desktop.ks and then still be able to change things in the base kickstart commands section. Which gives us pretty complete config inheritance support. > > Traceback (most recent call last): > > File > > "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 496, in > > _requiringFromTransaction reqpkg = self.rpmdb.searchNevra(name=name, > > ver=version, rel=release)[0] IndexError: list index out of range This is a yum bug I fixed upstream on Friday, but Seth and I then miscoordinated a little. I've just built yum-3.2.3-3.fc8 into koji[1] Jeremy [1] http://koji.fedoraproject.org/packages/yum/3.2.3/3.fc8/noarch/yum-3.2.3-3.fc8.noarch.rpm if you want to just grab and install it before it hits rawhide tomorrow. From katzj at redhat.com Tue Aug 28 14:02:15 2007 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 28 Aug 2007 10:02:15 -0400 Subject: [Fedora-livecd-list] Some problems: rootpassword and liveinst In-Reply-To: <20070828143212.104a8a8f@htpc> References: <20070828143212.104a8a8f@htpc> Message-ID: <1188309735.17567.8.camel@localhost.localdomain> On Tue, 2007-08-28 at 14:32 +0200, Sebastian Vahl wrote: > My actual spin of the kde livecd from today has some problems: This is yesterday's rawhide, correct? > 1. It seems that the root password wasn't erased. If I boot the iso in > vmware I got the error in the attached screenshot. If I boot the iso > with enforcing=0 all is working. Is this a problem on my local machine > (if relabeld the whole filesystem before I tested this)? Assuming the above is correct, this is from a buggy SELinux policy package that was in rawhide yesterday. dwalsh fixed it late in the day and it should be in today's rawhide (I'm doing a test spin right now) > 2. Because of 1. I've bootet with enforcing=0. If I then want to start > liveinst I get this traceback: [snip] > > ImportError: /usr/lib/python2.5/site-packages/block/dmmodule.so: > > undefined symbol: dm_task_get_uuid python-pyblock-0.30-1 has the fix for this Jeremy From kanarip at kanarip.com Tue Aug 28 14:23:04 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Tue, 28 Aug 2007 16:23:04 +0200 Subject: [Fedora-livecd-list] Some problems: rootpassword and liveinst In-Reply-To: <13dbfe4f0708280616x3b821868j98fb8fcf6e77ef04@mail.gmail.com> References: <20070828143212.104a8a8f@htpc> <13dbfe4f0708280616x3b821868j98fb8fcf6e77ef04@mail.gmail.com> Message-ID: <46D42FC8.9050703@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chitlesh GOORAH wrote: > On 8/28/07, Sebastian Vahl wrote: >> Hi. >> >> My actual spin of the kde livecd from today has some problems: >> >> 1. It seems that the root password wasn't erased. If I boot the iso in >> vmware I got the error in the attached screenshot. If I boot the iso >> with enforcing=0 all is working. Is this a problem on my local machine >> (if relabeld the whole filesystem before I tested this)? >> >> 2. Because of 1. I've bootet with enforcing=0. If I then want to start >> liveinst I get this traceback: > > I'm experiencing the same issue as mentioned above. > > > Chitlesh The root password with the rootpw command, that is supposed to be mandatory. The livecd-tools code shows that if the handler's attribute rootpw.password == "", the password is emptied. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1C/IKN6f2pNCvwgRAprMAJ45YmFOL65OhkhAtwklBTCcFvt/qwCffwdO wJO71ZsPdo+hdXIVUXCoPmo= =LA0x -----END PGP SIGNATURE----- From ml at deadbabylon.de Tue Aug 28 14:46:08 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 28 Aug 2007 16:46:08 +0200 Subject: [Fedora-livecd-list] Traceback with newest yum In-Reply-To: <1188309660.17567.5.camel@localhost.localdomain> References: <20070828142554.28bca622@htpc> <1188309660.17567.5.camel@localhost.localdomain> Message-ID: <20070828164608.336186b5@htpc> Am Tue, 28 Aug 2007 10:01:00 -0400 schrieb Jeremy Katz : > On Tue, 2007-08-28 at 14:25 +0200, Sebastian Vahl wrote: > > With newest yum and yum-metadata-parser I got the following > > traceback when starting livecd-creator: > > > > > /usr/lib/python2.5/site-packages/pykickstart/parser.py:600: > > > DeprecationWarning: Script does not end with %end. > > This is just a warning, but I will be updating the configs in .git > later for this. With this change in pykickstart, you can now %include > fedora-base-desktop.ks and then still be able to change things in the > base kickstart commands section. Which gives us pretty complete > config inheritance support. Great news! (I've thought about to question this as a feature request :) ) > > > > Traceback (most recent call last): > > > File > > > "/usr/lib/python2.5/site-packages/yum/depsolve.py", line 496, in > > > _requiringFromTransaction reqpkg = > > > self.rpmdb.searchNevra(name=name, ver=version, rel=release)[0] > > > IndexError: list index out of range > > This is a yum bug I fixed upstream on Friday, but Seth and I then > miscoordinated a little. I've just built yum-3.2.3-3.fc8 into koji[1] With this one all is working as expected. Thanks! Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ml at deadbabylon.de Tue Aug 28 15:51:41 2007 From: ml at deadbabylon.de (Sebastian Vahl) Date: Tue, 28 Aug 2007 17:51:41 +0200 Subject: [Fedora-livecd-list] Some problems: rootpassword and liveinst In-Reply-To: <1188309735.17567.8.camel@localhost.localdomain> References: <20070828143212.104a8a8f@htpc> <1188309735.17567.8.camel@localhost.localdomain> Message-ID: <20070828175141.7eb03bfc@htpc> Am Tue, 28 Aug 2007 10:02:15 -0400 schrieb Jeremy Katz : > On Tue, 2007-08-28 at 14:32 +0200, Sebastian Vahl wrote: > > My actual spin of the kde livecd from today has some problems: > > This is yesterday's rawhide, correct? Yeah. Timezones. I've done my work this morning local time (GMT+2). A few hours later there were incoming updates which fixes all the problems. > > > 1. It seems that the root password wasn't erased. If I boot the iso > > in vmware I got the error in the attached screenshot. If I boot the > > iso with enforcing=0 all is working. Is this a problem on my local > > machine (if relabeld the whole filesystem before I tested this)? > > Assuming the above is correct, this is from a buggy SELinux policy > package that was in rawhide yesterday. dwalsh fixed it late in the > day and it should be in today's rawhide (I'm doing a test spin right > now) Working again. Thanks. > > > 2. Because of 1. I've bootet with enforcing=0. If I then want to > > start liveinst I get this traceback: > [snip] > > > ImportError: /usr/lib/python2.5/site-packages/block/dmmodule.so: > > > undefined symbol: dm_task_get_uuid > > python-pyblock-0.30-1 has the fix for this Working again. Thanks. Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From gospo at redhat.com Wed Aug 29 15:26:12 2007 From: gospo at redhat.com (Andy Gospodarek) Date: Wed, 29 Aug 2007 11:26:12 -0400 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46D3AF6F.4060107@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> Message-ID: <20070829152612.GA32421@gospo.rdu.redhat.com> On Mon, Aug 27, 2007 at 10:15:27PM -0700, Thorsten von Eicken wrote: > Andy Gospodarek wrote: > >Nothing is ringing a bell yet. I've been racking my brain trying to > >figure out why this has happened in the past. (I've seen this on other > >ARCHs, but I can't remember what I did to fix it.) > > > >Can you send out your .config from your kernel? I'm curious what the > >whole thing looks like, but in particular I wonder about this section: > > > ># > ># Executable file formats > ># > >CONFIG_BINFMT_ELF=y > ># CONFIG_BINFMT_AOUT is not set > >CONFIG_BINFMT_MISC=m > > > >These are the defaults when doing a `make ARCH=i386 oldconfig` and are > >probably what you have, so this probably isn't the problem. Go ahead > >and sent the whole .config anyway and I'll take a look. > > Looks just like you say: > > # > # Executable file formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > CONFIG_BINFMT_MISC=y > > Ok, so here's my kickstart file followed by the .config. Thanks for > taking a look. Is there any debugging output I could turn on in the > kernel? I'm happy to do some troubleshooting, I'm just a little lost > right now about what could cause this. > > Thorsten > Thorsten, Thanks for sending that. I'll take a look at this config and see if I see anything. For reference I've attached the i586 config from f7, so it might be worth doing a rebuild of the rpm with a similar config. It's also worth noting that the liveCD doesn't claim to support i586 platforms: http://docs.fedoraproject.org/release-notes/f7/en_US/sn-Live.html so I'll see if I can poke around and figure out why. I also wondered if anything that was built needing kernel-devel or kernel-headers might need to be rebuilt for i586, but there are only a few i586 specific packages available in f7 (one of which is kernel-devel), so I'm not sure how important that is. -andy -------------- next part -------------- # i386 # # Automatically generated make config: don't edit # CONFIG_MMU=y CONFIG_SMP=y CONFIG_HOTPLUG_CPU=y CONFIG_LOCALVERSION="" CONFIG_CRASH_DUMP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y # # General setup # # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_CFQ=y CONFIG_IPC_NS=y CONFIG_POSIX_MQUEUE=y # CONFIG_PREEMPT_NONE is not set CONFIG_PREEMPT_VOLUNTARY=y # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_FORCE is not set CONFIG_MODULE_VERIFY_ELF=y # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_PCI_MSI=y # CONFIG_PCI_MULTITHREAD_PROBE is not set CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y # CONFIG_HOTPLUG_PCI_PCIE is not set CONFIG_HOTPLUG_PCI_FAKE=m # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set CONFIG_HOTPLUG=y # CONFIG_DEBUG_KOBJECT is not set # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_PCMCIA_LOAD_CIS=y # CONFIG_PCMCIA_DEBUG is not set CONFIG_YENTA=y CONFIG_CARDBUS=y CONFIG_I82092=m CONFIG_PD6729=m CONFIG_PCMCIA_IOCTL=y CONFIG_PCCARD=y CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set CONFIG_MMC_BLOCK=m CONFIG_MMC_WBSD=m CONFIG_MMC_SDHCI=m CONFIG_MMC_TIFM_SD=m # CONFIG_INFINIBAND is not set CONFIG_INFINIBAND_MTHCA=m # CONFIG_INFINIBAND_MTHCA_DEBUG is not set CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y # CONFIG_INFINIBAND_IPOIB_CM is not set CONFIG_INFINIBAND_SRP=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_IPATH=m CONFIG_INFINIBAND_ISER=m CONFIG_INFINIBAND_AMSO1100=m # CONFIG_INFINIBAND_AMSO1100_DEBUG is not set CONFIG_INFINIBAND_CXGB3=m # CONFIG_INFINIBAND_CXGB3_DEBUG is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_MISC=y # # Device Drivers # # # Generic Driver Options # CONFIG_FW_LOADER=y # CONFIG_SPI is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CONCAT=m CONFIG_MTD_CMDLINE_PARTS=y # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_MTD_BLOCK=m CONFIG_MTD_BLOCK_RO=m CONFIG_MTD_BLOCK2MTD=m CONFIG_FTL=m CONFIG_NFTL=m CONFIG_NFTL_RW=y CONFIG_INFTL=m CONFIG_RFD_FTL=m CONFIG_SSFDC=m # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m # CONFIG_MTD_CFI_ADV_OPTIONS is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_RAM=m CONFIG_MTD_ROM=m CONFIG_MTD_ABSENT=m # CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m # CONFIG_MTD_SBC_GXX is not set # CONFIG_MTD_SCx200_DOCFLASH is not set # CONFIG_MTD_AMD76XROM is not set CONFIG_MTD_SCB2_FLASH=m # CONFIG_MTD_NETtel is not set # CONFIG_MTD_DILNETPC is not set # CONFIG_MTD_L440GX is not set CONFIG_MTD_PCI=m CONFIG_MTD_TS5500=m # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=m # CONFIG_MTD_PMC551_BUGFIX is not set # CONFIG_MTD_PMC551_DEBUG is not set # CONFIG_MTD_SLRAM is not set CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 # # Disk-On-Chip Device Drivers # # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOC2001PLUS is not set # CONFIG_MTD_DOCPROBE is not set # CONFIG_MTD_DOCPROBE_ADVANCED is not set # CONFIG_MTD_DOCPROBE_ADDRESS is not set # # NAND Flash Device Drivers # CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_CAFE=m CONFIG_MTD_NAND_IDS=m CONFIG_MTD_NAND_NANDSIM=m # CONFIG_MTD_ONENAND is not set CONFIG_MTD_NAND_ECC_SMC=y CONFIG_MTD_NAND_CS553X=m CONFIG_MTD_REDBOOT_PARTS=m # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 # CONFIG_MTD_XIP is not set # CONFIG_MTD_ICHXROM is not set # CONFIG_MTD_PHRAM is not set CONFIG_MTD_NAND_DISKONCHIP=m # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 # CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE is not set # CONFIG_MTD_PLATRAM is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set CONFIG_PARPORT_PC_PCMCIA=m CONFIG_PARPORT_1284=y # CONFIG_PARPORT_AX88796 is not set # # Plug and Play support # CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_HOTPLUG_PCI_ACPI_IBM=m # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set CONFIG_PARIDE=m CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m CONFIG_PARIDE_ATEN=m CONFIG_PARIDE_BPCK=m CONFIG_PARIDE_BPCK6=m CONFIG_PARIDE_COMM=m CONFIG_PARIDE_DSTR=m CONFIG_PARIDE_FIT2=m CONFIG_PARIDE_FIT3=m CONFIG_PARIDE_EPAT=m CONFIG_PARIDE_EPATC8=y CONFIG_PARIDE_EPIA=m CONFIG_PARIDE_FRIQ=m CONFIG_PARIDE_FRPW=m CONFIG_PARIDE_KBIC=m CONFIG_PARIDE_KTTI=m CONFIG_PARIDE_ON20=m CONFIG_PARIDE_ON26=m CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_RAM_BLOCKSIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_BLK_DEV_ATIIXP=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y CONFIG_BLK_DEV_DELKIN=m # CONFIG_BLK_DEV_IT8213 is not set # CONFIG_BLK_DEV_TC86C001 is not set # # ATA/ATAPI/MFM/RLL support # # CONFIG_IDE is not set CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_IDE_TASK_IOCTL=y # CONFIG_BLK_DEV_IDE_SATA is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y CONFIG_BLK_DEV_CMD640_ENHANCED=y CONFIG_BLK_DEV_IDEPNP=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_AEC62XX=y CONFIG_BLK_DEV_ALI15X3=y # CONFIG_WDC_ALI15X3 is not set CONFIG_BLK_DEV_AMD74XX=y CONFIG_BLK_DEV_CMD64X=y CONFIG_BLK_DEV_TRIFLEX=y # CONFIG_BLK_DEV_CY82C693 is not set CONFIG_BLK_DEV_CS5520=y CONFIG_BLK_DEV_CS5530=y CONFIG_BLK_DEV_CS5535=y CONFIG_BLK_DEV_HPT34X=y CONFIG_BLK_DEV_HPT366=y CONFIG_BLK_DEV_IT821X=y CONFIG_BLK_DEV_JMICRON=y # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_BLK_DEV_SVWKS=y CONFIG_BLK_DEV_SIIMAGE=y CONFIG_BLK_DEV_SIS5513=y # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=m CONFIG_SCSI_PROC_FS=y CONFIG_SCSI_TGT=m CONFIG_SCSI_SCAN_ASYNC=y CONFIG_SCSI_SRP=m # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set CONFIG_RAID_ATTRS=m CONFIG_ISCSI_TCP=m # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_3W_9XXX=m # CONFIG_SCSI_7000FASST is not set CONFIG_SCSI_ACARD=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_SCSI_AIC94XX=m # CONFIG_AIC94XX_DEBUG is not set CONFIG_AIC7XXX_CMDS_PER_DEVICE=4 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 # CONFIG_AIC7XXX_REG_PRETTY_PRINT is not set CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=4 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_BUILD_FIRMWARE is not set # CONFIG_AIC79XX_ENABLE_RD_STRM is not set # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 # CONFIG_AIC79XX_REG_PRETTY_PRINT is not set CONFIG_SCSI_ADVANSYS=m CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_ATA=m CONFIG_ATA_PIIX=m CONFIG_BLK_DEV_SX8=m CONFIG_PDC_ADMA=m CONFIG_SATA_AHCI=m CONFIG_SATA_INIC162X=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_SATA_PROMISE=m CONFIG_SATA_QSTOR=m CONFIG_SATA_SIL=m CONFIG_SATA_SIL24=m CONFIG_SATA_SIS=m CONFIG_SATA_SVW=m CONFIG_SATA_SX4=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_CMD64X=m CONFIG_PATA_CS5520=m CONFIG_PATA_CS5530=m CONFIG_PATA_CS5535=m CONFIG_PATA_CYPRESS=m CONFIG_PATA_EFAR=m CONFIG_ATA_GENERIC=m CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m CONFIG_PATA_ISAPNP=m CONFIG_PATA_IT821X=m CONFIG_PATA_IT8213=m CONFIG_PATA_JMICRON=m # CONFIG_PATA_LEGACY is not set CONFIG_PATA_TRIFLEX=m CONFIG_PATA_MARVELL=m # CONFIG_PATA_WINBOND_VLB is not set CONFIG_PATA_MPIIX=m CONFIG_PATA_OLDPIIX=m CONFIG_PATA_NETCELL=m CONFIG_PATA_NS87410=m CONFIG_PATA_OPTI=m CONFIG_PATA_OPTIDMA=m CONFIG_PATA_PCMCIA=m CONFIG_PATA_PDC_OLD=m CONFIG_PATA_QDI=m # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_VIA=m CONFIG_PATA_WINBOND=m CONFIG_SCSI_BUSLOGIC=m CONFIG_SCSI_INITIO=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_PIO is not set CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_IPS=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_DC395x=m # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set CONFIG_SCSI_DC390T=m CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_ISCSI=m # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_DPT_I2O is not set CONFIG_SCSI_LPFC=m # CONFIG_SCSI_SEAGATE is not set # # PCMCIA SCSI adapter support # CONFIG_PCMCIA_AHA152X=m CONFIG_PCMCIA_FDOMAIN=m CONFIG_PCMCIA_NINJA_SCSI=m CONFIG_PCMCIA_QLOGIC=m CONFIG_PCMCIA_SYM53C500=m # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m CONFIG_DM_DEBUG=y CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_CRYPT=m CONFIG_DM_MULTIPATH=m CONFIG_DM_MULTIPATH_EMC=m # # Fusion MPT device support # CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_MAX_SGE=40 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m CONFIG_FUSION_SAS=m # # IEEE 1394 (FireWire) support (JUJU alternative stack) # CONFIG_FIREWIRE=m CONFIG_FIREWIRE_OHCI=m CONFIG_FIREWIRE_SBP2=m # # IEEE 1394 (FireWire) support # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m # CONFIG_I2O_LCT_NOTIFY_ON_CHANGES is not set # # Networking support # CONFIG_NET=y # CONFIG_NETDEBUG is not set CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=y CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_MD5SIG=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_INET_TUNNEL=m CONFIG_INET_DIAG=m CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set CONFIG_IP_ROUTE_MULTIPATH_RR=m CONFIG_IP_ROUTE_MULTIPATH_RANDOM=m CONFIG_IP_ROUTE_MULTIPATH_WRANDOM=m CONFIG_IP_ROUTE_MULTIPATH_DRR=m # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_NETCONSOLE=m # CONFIG_NETPOLL_RX is not set CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m CONFIG_IP_VS_FTP=m CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=y CONFIG_IPV6_SIT=m CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_SUBTREES=y CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_DECNET=m CONFIG_DECNET_ROUTER=y # CONFIG_DECNET_NF_GRABULATOR is not set CONFIG_BRIDGE=m CONFIG_NETFILTER=y CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_CONNTRACK_MARK=y CONFIG_IP_NF_CONNTRACK_EVENTS=y CONFIG_IP_NF_CONNTRACK_NETLINK=m CONFIG_IP_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_ENABLED=m CONFIG_NF_CONNTRACK_SUPPORT=y CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CONNTRACK_IPV4=m CONFIG_NF_CONNTRACK_IPV6=m CONFIG_NF_NAT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_CT_PROTO_SCTP=m CONFIG_NF_CT_NETLINK=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_IPRANGE=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_TOS=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_SAME=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_NAT_AMANDA=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m CONFIG_IP_NF_CT_ACCT=y CONFIG_IP_NF_CT_PROTO_SCTP=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m CONFIG_IP_NF_TFTP=m CONFIG_IP_NF_AMANDA=m CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_NETBIOS_NS=m CONFIG_IP_NF_PPTP=m CONFIG_IP_NF_H323=m CONFIG_IP_NF_SIP=m # # IPv6: Netfilter Configuration # CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_RAW=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_TARGET_HL=m # # Bridge: Netfilter Configuration # CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_XFRM_SUB_POLICY=y CONFIG_XFRM_MIGRATE=y CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_INET6_XFRM_MODE_BEET=m # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y CONFIG_ATM=m CONFIG_VLAN_8021Q=m CONFIG_LLC=m # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m CONFIG_IP_DCCP=m CONFIG_IP_DCCP_CCID2=m # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=m # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_CCID3_RTO=100 # CONFIG_IP_DCCP_DEBUG is not set CONFIG_NET_DCCPPROBE=m # # TIPC Configuration (EXPERIMENTAL) # CONFIG_TIPC=m # CONFIG_TIPC_ADVANCED is not set # CONFIG_TIPC_DEBUG is not set CONFIG_NETLABEL=y # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y CONFIG_NET_ACT_POLICE=m CONFIG_CLS_U32_PERF=y CONFIG_NET_CLS_IND=y CONFIG_NET_CLS_ACT=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_NET_TCPPROBE is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_NET_SB1000=m # # ATM # # CONFIG_ATM_DUMMY is not set CONFIG_ATM_CLIP=m CONFIG_ATM_LANE=m CONFIG_ATM_BR2684=m CONFIG_NET_SCH_ATM=m CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m CONFIG_ATM_FIRESTREAM=m # CONFIG_ATM_ZATM is not set CONFIG_ATM_IDT77252=m CONFIG_ATM_AMBASSADOR=m CONFIG_ATM_HORIZON=m CONFIG_ATM_FORE200E_MAYBE=m CONFIG_ATM_HE=m CONFIG_PPPOATM=m CONFIG_ATM_NICSTAR=m # CONFIG_ATM_IA is not set # CONFIG_ATM_CLIP_NO_ICMP is not set # CONFIG_ATM_MPOA is not set # CONFIG_ATM_BR2684_IPFILTER is not set # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set # CONFIG_ATM_ZATM_DEBUG is not set # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set # CONFIG_ATM_AMBASSADOR_DEBUG is not set # CONFIG_ATM_HORIZON_DEBUG is not set # CONFIG_ATM_FORE200E_PCA is not set # CONFIG_ATM_HE_USE_SUNI is not set # CONFIG_ATM_NICSTAR_USE_SUNI is not set # CONFIG_ATM_NICSTAR_USE_IDT77105 is not set # CONFIG_ATM_IA_DEBUG is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_PHYLIB=m CONFIG_BROADCOM_PHY=m CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_SMSC_PHY=m CONFIG_FIXED_PHY=m CONFIG_FIXED_MII_10_FDX=y CONFIG_FIXED_MII_100_FDX=y CONFIG_VITESSE_PHY=m CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m CONFIG_TYPHOON=m # # Tulip family network device support # CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_NAPI is not set # CONFIG_TULIP_MWI is not set CONFIG_TULIP_MMIO=y # CONFIG_NI5010 is not set # CONFIG_PCMCIA_XIRTULIP is not set CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_PCMCIA_XIRCOM=m CONFIG_ULI526X=m # CONFIG_HP100 is not set CONFIG_LNE390=m CONFIG_NE3210=m CONFIG_ES3210=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_PCNET32_NAPI=y CONFIG_AMD8111_ETH=m CONFIG_AMD8111E_NAPI=y CONFIG_ADAPTEC_STARFIRE=m CONFIG_ADAPTEC_STARFIRE_NAPI=y CONFIG_B44=m CONFIG_BNX2=m CONFIG_QLA3XXX=m CONFIG_ATL1=m # CONFIG_DGRS is not set # CONFIG_EEPRO100 is not set CONFIG_E100=m CONFIG_FEALNX=m CONFIG_FORCEDETH=m CONFIG_FORCEDETH_NAPI=y CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_SIS900=m CONFIG_SIS190=m CONFIG_EPIC100=m CONFIG_SC92031=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_TLAN=m CONFIG_VIA_RHINE=m CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y CONFIG_VIA_VELOCITY=m CONFIG_NET_POCKET=y CONFIG_ATP=m CONFIG_DE600=m CONFIG_DE620=m CONFIG_CASSINI=m # CONFIG_FEC_8XX is not set # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=m CONFIG_E1000_NAPI=y # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_R8169_NAPI=y CONFIG_R8169_VLAN=y # CONFIG_SK98LIN is not set CONFIG_SKGE=m CONFIG_TIGON3=m CONFIG_SKY2=m # # Ethernet (10000 Mbit) # CONFIG_IXGB=m CONFIG_IXGB_NAPI=y CONFIG_S2IO=m CONFIG_S2IO_NAPI=y CONFIG_MYRI10GE=m CONFIG_NETXEN_NIC=m CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T1_NAPI=y CONFIG_CHELSIO_T3=m CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=m # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_IPPP_FILTER=y # CONFIG_PPP_BSDCOMP is not set CONFIG_PPPOE=m CONFIG_PPP_MPPE=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y # CONFIG_SLIP_MODE_SLIP6 is not set # # Wireless LAN # CONFIG_WLAN_PRE80211=y # CONFIG_STRIP is not set # CONFIG_ARLAN is not set CONFIG_PCMCIA_WAVELAN=m CONFIG_PCMCIA_NETWAVE=m CONFIG_WLAN_80211=y # CONFIG_PCMCIA_RAYCS is not set CONFIG_MAC80211=m CONFIG_MAC80211_LEDS=y # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_IEEE80211_SOFTMAC=m CONFIG_IEEE80211_SOFTMAC_DEBUG=y CONFIG_CFG80211=m # CONFIG_NL80211 is not set CONFIG_IPW2100=m CONFIG_IPW2200=m # CONFIG_IPW2100_DEBUG is not set # CONFIG_IPW2200_DEBUG is not set CONFIG_USB_ZD1201=m # CONFIG_ZD1211RW is not set CONFIG_BCM43XX_MAC80211=m CONFIG_BCM43XX_MAC80211_PCI=y CONFIG_BCM43XX_MAC80211_PCMCIA=y CONFIG_BCM43XX_MAC80211_DEBUG=y CONFIG_BCM43XX_MAC80211_DMA=y CONFIG_BCM43XX_MAC80211_PIO=y CONFIG_BCM43XX_MAC80211_DMA_AND_PIO_MODE=y # CONFIG_BCM43XX_MAC80211_DMA_MODE is not set # CONFIG_BCM43XX_MAC80211_PIO_MODE is not set CONFIG_RT2X00=y CONFIG_RT2400PCI=m CONFIG_RT2500PCI=m CONFIG_RT61PCI=m CONFIG_RT2500USB=m CONFIG_RT73USB=m # CONFIG_RT2X00_DEBUG is not set CONFIG_ADM8211=m CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_ZD1211RW_MAC80211=m # CONFIG_ZD1211RW_MAC80211_DEBUG is not set CONFIG_RTL818X=y CONFIG_RTL8187=m CONFIG_IWLWIFI=y CONFIG_IWLWIFI_DEBUG=y # CONFIG_IWL4965 is not set CONFIG_IWL3945=m CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCI_HERMES=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_PRISM54=m CONFIG_BCM43XX=m CONFIG_BCM43XX_DEBUG=y CONFIG_PCMCIA_HERMES=m CONFIG_PCMCIA_SPECTRUM=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_ATMEL=m CONFIG_PCMCIA_WL3501=m CONFIG_HOSTAP=m CONFIG_HOSTAP_PCI=m CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_CS=m # # Token Ring devices # CONFIG_TR=y CONFIG_IBMOL=m CONFIG_3C359=m # Broken with gcc4.1 # CONFIG_TMS380TR is not set CONFIG_TMSPCI=m CONFIG_ABYSS=m CONFIG_IBMLS=m CONFIG_PCMCIA_IBMTR=m CONFIG_NET_FC=y # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # CONFIG_IRDA=m # CONFIG_IRDA_DEBUG is not set CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m # CONFIG_IRDA_ULTRA is not set CONFIG_IRDA_CACHE_LAST_LSAP=y CONFIG_IRDA_FAST_RR=y CONFIG_IRTTY_SIR=m CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_IRPORT_SIR=m # CONFIG_DONGLE_OLD is not set CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_ALI_FIR=m CONFIG_MCS_FIR=m CONFIG_NSC_FIR=m CONFIG_SIGMATEL_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_USB_IRDA=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_WINBOND_FIR=m # # Bluetooth support # CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_CMTP=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIBPA10X=m # # ISDN subsystem # CONFIG_ISDN=m CONFIG_ISDN_I4L=m CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m CONFIG_ISDN_DRV_AVMB1_T1PCI=m CONFIG_ISDN_DRV_AVMB1_C4=m CONFIG_ISDN_PPP=y CONFIG_ISDN_PPP_VJ=y CONFIG_ISDN_MPP=y # CONFIG_ISDN_PPP_BSDCOMP is not set CONFIG_ISDN_TTY_FAX=y CONFIG_DE_AOC=y CONFIG_ISDN_AUDIO=y CONFIG_ISDN_DRV_HISAX=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_AVM_CS=m CONFIG_ISDN_CAPI_CAPIDRV=m CONFIG_ISDN_DIVERSION=m CONFIG_HISAX_EURO=y CONFIG_HISAX_1TR6=y CONFIG_HISAX_NI1=y CONFIG_HISAX_MAX_CARDS=8 CONFIG_HISAX_16_3=y CONFIG_HISAX_TELESPCI=y CONFIG_HISAX_S0BOX=y CONFIG_HISAX_FRITZPCI=y CONFIG_HISAX_AVM_A1_PCMCIA=y CONFIG_HISAX_ELSA=y CONFIG_HISAX_DIEHLDIVA=y CONFIG_HISAX_SEDLBAUER=y CONFIG_HISAX_NETJET=y CONFIG_HISAX_NETJET_U=y CONFIG_HISAX_NICCY=y CONFIG_HISAX_BKM_A4T=y CONFIG_HISAX_SCT_QUADRO=y CONFIG_HISAX_GAZEL=y CONFIG_HISAX_HFC_PCI=y CONFIG_HISAX_W6692=y CONFIG_HISAX_HFC_SX=y CONFIG_HISAX_ENTERNOW_PCI=y # CONFIG_HISAX_DEBUG is not set CONFIG_HISAX_AVM_A1_CS=m CONFIG_HISAX_ST5481=m # CONFIG_HISAX_HFCUSB is not set CONFIG_HISAX_FRITZ_PCIPNP=m CONFIG_HISAX_NO_SENDCOMPLETE=y CONFIG_HISAX_NO_LLC=y CONFIG_HISAX_NO_KEYPAD=y CONFIG_HISAX_SEDLBAUER_CS=m CONFIG_HISAX_ELSA_CS=m CONFIG_HISAX_TELES_CS=m CONFIG_HISAX_HFC4S8S=m CONFIG_ISDN_DRV_LOOP=m CONFIG_HYSDN=m CONFIG_HYSDN_CAPI=y # # CAPI subsystem # CONFIG_ISDN_CAPI=m # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=m # # CAPI hardware drivers # # # Active AVM cards # CONFIG_CAPI_AVM=y # # Active Eicon DIVA Server cards # CONFIG_CAPI_EICON=y CONFIG_ISDN_DIVAS=m CONFIG_ISDN_DIVAS_BRIPCI=y CONFIG_ISDN_DIVAS_PRIPCI=y CONFIG_ISDN_DIVAS_DIVACAPI=m CONFIG_ISDN_DIVAS_USERIDI=m CONFIG_ISDN_DIVAS_MAINT=m CONFIG_ISDN_DRV_GIGASET=m CONFIG_GIGASET_BASE=m CONFIG_GIGASET_M101=m CONFIG_GIGASET_M105=m # CONFIG_GIGASET_DEBUG is not set # CONFIG_GIGASET_UNDOCREQ is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_FM801=m CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y CONFIG_SERIO_RAW=m # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set # CONFIG_SERIO_PCIPS2 is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_KEYBOARD_LKKBD is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_VSXXXAA=m CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_JOYSTICK_JOYDUMP=m CONFIG_JOYSTICK_TWIDJOY=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_MTOUCH=m CONFIG_TOUCHSCREEN_MK712=m CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_UCB1400=m CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m CONFIG_INPUT_UINPUT=m CONFIG_INPUT_WISTRON_BTNS=m CONFIG_INPUT_ATLAS_BTNS=m CONFIG_MAC_EMUMOUSEBTN=y # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_ROCKETPORT=m CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_N_HDLC=m # CONFIG_STALDRV is not set # CONFIG_IBM_ASM is not set CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m # CONFIG_TELCLOCK is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y CONFIG_SERIAL_8250_DETECT_IRQ=y CONFIG_SERIAL_8250_RSA=y # CONFIG_COMPUTONE is not set CONFIG_CYCLADES=m # CONFIG_CYZ_INTR is not set # CONFIG_DIGIEPCA is not set # CONFIG_ESPSERIAL is not set # CONFIG_MOXA_INTELLIO is not set # CONFIG_MOXA_SMARTIO is not set # CONFIG_MOXA_SMARTIO_NEW is not set # CONFIG_ISI is not set # CONFIG_RISCOM8 is not set # CONFIG_SPECIALIX is not set # CONFIG_SX is not set # CONFIG_RIO is not set # CONFIG_STALLION is not set # CONFIG_ISTALLION is not set CONFIG_SERIAL_JSM=m # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m # # I2C support # CONFIG_I2C=m CONFIG_I2C_CHARDEV=m # # I2C Algorithms # # CONFIG_I2C_DEBUG_ALGO is not set CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCF=m # # I2C Hardware Bus support # CONFIG_I2C_NFORCE2=m CONFIG_I2C_PASEMI=m CONFIG_I2C_PROSAVAGE=m CONFIG_I2C_SAVAGE4=m CONFIG_I2C_VOODOO3=m CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m CONFIG_I2C_I810=m CONFIG_I2C_PIIX4=m # CONFIG_SCx200_ACB is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # CONFIG_I2C_ELEKTOR is not set CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set CONFIG_I2C_ALGOPCA=m CONFIG_I2C_PCA_ISA=m CONFIG_I2C_STUB=m # CONFIG_I2C_OCORES is not set # # I2C Hardware Sensors Chip support # CONFIG_SENSORS_ABITUGURU=m CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_DS1621=m CONFIG_SENSORS_DS1337=m CONFIG_SENSORS_DS1374=m CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_FSCPOS=m CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m # CONFIG_SENSORS_HDAPS is not set CONFIG_SENSORS_IT87=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX6875=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_PCA9539=m CONFIG_SENSORS_PCF8574=m CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_SIS5595=m CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m # This is busted. # If we enable it, it steals Matrox cards, and the # framebuffer drivers stop working. # CONFIG_W1 is not set CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2482=m CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y CONFIG_W1_CON=y CONFIG_W1_MASTER_DS2490=m # # Mice # # # IPMI # # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_SI=m CONFIG_IPMI_POWEROFF=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set CONFIG_SOFT_WATCHDOG=m # CONFIG_WDT_501 is not set CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_I8XX_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set CONFIG_W83877F_WDT=m CONFIG_W83627HF_WDT=m CONFIG_MACHZ_WDT=m # CONFIG_SC520_WDT is not set CONFIG_ALIM7101_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_CPU5_WDT is not set CONFIG_I6300ESB_WDT=m # CONFIG_SBC8360_WDT is not set CONFIG_W83977F_WDT=m CONFIG_PCIPCWATCHDOG=m CONFIG_USBPCWATCHDOG=m # CONFIG_SBC_EPX_C3_WATCHDOG is not set CONFIG_HW_RANDOM=y CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_RTC_DEBUG is not set CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_INTF_SYSFS=m CONFIG_RTC_INTF_PROC=m CONFIG_RTC_INTF_DEV=m # FIXME: Disable _RTC for F7+ and enable DRV_CMOS # CONFIG_RTC_DRV_CMOS is not set CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_DS1742=m # CONFIG_RTC_DRV_EP93XX is not set CONFIG_RTC_DRV_ISL1208=m # CONFIG_RTC_DRV_M48T86 is not set CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_RS5C372=m # CONFIG_RTC_DRV_SA1100 is not set # CONFIG_RTC_DRV_TEST is not set CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_V3020=m # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set CONFIG_SONYPI=m # # Ftape, the floppy tape device driver # CONFIG_AGP=y CONFIG_AGP_ALI=y # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=y # CONFIG_AGP_NVIDIA is not set CONFIG_AGP_SIS=y # CONFIG_AGP_SWORKS is not set CONFIG_AGP_VIA=y CONFIG_AGP_EFFICEON=y CONFIG_DRM=m CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_SAVAGE=m CONFIG_DRM_I915=m CONFIG_DRM_VIA=m CONFIG_DRM_NOUVEAU=m # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_MWAVE=m # CONFIG_RAW_DRIVER is not set CONFIG_MAX_RAW_DEVS=8192 CONFIG_HANGCHECK_TIMER=m # # Multimedia devices # CONFIG_VIDEO_DEV=m # CONFIG_VIDEO_ADV_DEBUG is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y # CONFIG_VIDEO_VIVI is not set # # Video For Linux # # # Video Adapters # CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CAFE_CCIC=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_CPIA2=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_DPC=m CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_MEYE=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_OVCAMCHIP=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_TLV320AIC23B=m CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m CONFIG_VIDEO_USBVISION=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_TUNER_3036=m # # Radio Adapters # CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m # # Digital Video Broadcasting Devices # CONFIG_DVB=y CONFIG_DVB_CORE=m CONFIG_DVB_CORE_ATTACH=y # CONFIG_DVB_FE_CUSTOMISE is not set # # Supported Frontend Modules # CONFIG_DVB_STV0299=m # CONFIG_DVB_SP887X is not set CONFIG_DVB_CX24110=m CONFIG_DVB_MT312=m CONFIG_DVB_VES1820=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TTUSB_DEC=m CONFIG_DVB_BT8XX=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m # # Supported SAA7146 based PCI Adapters # CONFIG_DVB_AV7110=m CONFIG_DVB_AV7110_OSD=y # CONFIG_DVB_AV7110_FIRMWARE is not set CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_TTUSB_BUDGET=m # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_CINERGYT2=m CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_CINERGYT2_TUNING=y CONFIG_DVB_CINERGYT2_STREAM_URB_COUNT=32 CONFIG_DVB_CINERGYT2_STREAM_BUF_SIZE=512 CONFIG_DVB_CINERGYT2_QUERY_INTERVAL=250 CONFIG_DVB_CINERGYT2_ENABLE_RC_INPUT_DEVICE=y CONFIG_DVB_CINERGYT2_RC_QUERY_INTERVAL=100 CONFIG_DVB_OR51132=m CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_CXUSB=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_UMT_010=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_TUNER_QT1010=m CONFIG_DVB_PLUTO2=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_S5H1420=m CONFIG_DVB_SP8870=m CONFIG_DVB_L64781=m CONFIG_DVB_TDA10021=m CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_BUF=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_24XXX=y CONFIG_VIDEO_PVRUSB2_29XXX=y CONFIG_VIDEO_PVRUSB2_SYSFS=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set # # Graphics support # CONFIG_FB=y CONFIG_VIDEO_SELECT=y CONFIG_FB_3DFX=m CONFIG_FB_3DFX_ACCEL=y # CONFIG_FB_ARC is not set CONFIG_FB_ATY128=m CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_GENERIC_LCD=y # CONFIG_FB_ASILIANT is not set CONFIG_FB_CIRRUS=m # CONFIG_FB_CYBER2000 is not set CONFIG_FB_CYBLA=m # CONFIG_FB_GEODE is not set # CONFIG_FB_HGA is not set CONFIG_FB_I810=m CONFIG_FB_I810_GTF=y CONFIG_FB_I810_I2C=y # CONFIG_FB_IMSTT is not set # CONFIG_FB_IMAC is not set CONFIG_FB_INTEL=m # CONFIG_FB_INTEL_DEBUG is not set CONFIG_FB_INTEL_I2C=y CONFIG_FB_KYRO=m CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y CONFIG_FB_MATROX_I2C=m CONFIG_FB_MATROX_MAVEN=m CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_NEOMAGIC=m CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_PM2 is not set # CONFIG_FB_PM2_FIFO_DISCONNECT is not set CONFIG_FB_RADEON=m # CONFIG_FB_RADEON_DEBUG is not set CONFIG_FB_RADEON_I2C=y CONFIG_FB_RIVA=m # CONFIG_FB_RIVA_DEBUG is not set # CONFIG_FB_RIVA_I2C is not set # CONFIG_FB_S1D13XXX is not set CONFIG_FB_S3=m CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y # CONFIG_FB_SIS is not set CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y CONFIG_FB_SM501=m CONFIG_FB_TILEBLITTING=y CONFIG_FB_TRIDENT=m CONFIG_FB_TRIDENT_ACCEL=y CONFIG_FB_VESA=y CONFIG_FB_VGA16=m # CONFIG_FB_VIRTUAL is not set CONFIG_FB_VOODOO1=m # CONFIG_FIRMWARE_EDID is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set # # Logo configuration # CONFIG_LOGO=y # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_RTCTIMER=m # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_DYNAMIC_MINORS=y # CONFIG_SND_SUPPORT_OLD_API is not set # # Generic devices # CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_MTS64=m # CONFIG_SND_SERIAL_U16550 is not set CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y # # ISA devices # CONFIG_SND_AD1889=m # CONFIG_SND_WAVEFRONT is not set # # PCI devices # CONFIG_SND_ALI5451=m CONFIG_SND_AZT3328=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y CONFIG_SND_CS4281=m CONFIG_SND_CS5535AUDIO=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_CA0106=m CONFIG_SND_KORG1212=m CONFIG_SND_NM256=m CONFIG_SND_RME32=m CONFIG_SND_PCXHR=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_HDSP=m CONFIG_SND_TRIDENT=m CONFIG_SND_YMFPCI=m CONFIG_SND_ALS4000=m CONFIG_SND_CMIPCI=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_MAESTRO3=m CONFIG_SND_FM801=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_SONICVIBES=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VX222=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_MIXART=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_INTEL8X0M=m CONFIG_SND_HDA_INTEL=m CONFIG_SND_HDSPM=m CONFIG_SND_ADLIB=m CONFIG_SND_MIRO=m CONFIG_SND_ALS300=m CONFIG_SND_RIPTIDE=m # # ALSA USB devices # CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # # Open Sound System # # CONFIG_SOUND_PRIME is not set # CONFIG_SOUND_BT878 is not set # # USB support # CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DYNAMIC_MINORS is not set CONFIG_USB_SUSPEND=y # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_HCD_SSB is not set CONFIG_USB_UHCI_HCD=m CONFIG_USB_SL811_CS=m # # USB Device Class drivers # # # USB Bluetooth TTY can only be used with disabled Bluetooth subsystem # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m # CONFIG_BLK_DEV_UB is not set CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_ONETOUCH=y CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_KARMA=y CONFIG_USB_LIBUSUAL=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set CONFIG_HID_FF=y CONFIG_HID_PID=y CONFIG_LOGITECH_FF=y CONFIG_PANTHERLORD_FF=y CONFIG_THRUSTMASTER_FF=y CONFIG_ZEROPLUS_FF=y CONFIG_USB_HIDDEV=y CONFIG_USB_IDMOUSE=m # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m CONFIG_USB_KBTAB=m CONFIG_USB_POWERMATE=m CONFIG_USB_XPAD=m # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m CONFIG_USB_VICAM=m CONFIG_USB_DSBR=m CONFIG_USB_ET61X251=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_STV680=m CONFIG_USB_SN9C102=m # # USB Network adaptors # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_SPEEDTOUCH=m # Has dumb detection, which gets loaded for every hid device. # CONFIG_USB_YEALINK is not set CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_DM9601=m CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_NET_ZAURUS=m # # USB Host-to-Host Cables # CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_AIRPRIME=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_OPTION=y CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=y CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_DEBUG=m CONFIG_USB_EZUSB=y CONFIG_USB_EMI62=m CONFIG_USB_LED=m # CONFIG_USB_CYPRESS_CY7C63 is not set CONFIG_USB_G_SERIAL=m # # USB Miscellaneous drivers # CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m CONFIG_USB_LCD=m CONFIG_USB_BERRY_CHARGE=m # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_GADGET is not set # CONFIG_USB_GADGET_PXA2XX is not set # CONFIG_USB_GADGET_GOKU is not set CONFIG_USB_ZERO=m CONFIG_USB_ETH=m # CONFIG_USB_GADGETFS is not set CONFIG_USB_W9968CF=m CONFIG_USB_ZC0301=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_LEGOTOWER=m CONFIG_USB_FILE_STORAGE=m # CONFIG_USB_FILE_STORAGE_TEST is not set CONFIG_USB_ATI_REMOTE=m CONFIG_USB_ATI_REMOTE2=m CONFIG_USB_ALI_M5632=y # CONFIG_USB_CYTHERM is not set CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_PHIDGET=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETMOTORCONTROL=m CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m CONFIG_USB_MON=y CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_ISP116X_HCD=m CONFIG_USB_ACECAD=m CONFIG_USB_ATM=m CONFIG_USB_CXACRU=m CONFIG_USB_XUSBATM=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_KEYSPAN_REMOTE=m CONFIG_USB_LD=m CONFIG_USB_APPLETOUCH=m CONFIG_USB_GTCO=m CONFIG_USB_TRANCEVIBRATOR=m CONFIG_USB_TOUCHSCREEN=m CONFIG_USB_QUICKCAM_MESSENGER=m CONFIG_USB_HIDINPUT_POWERBOOK=y # # Sonics Silicon Backplane # CONFIG_SSB=m CONFIG_SSB_PCIHOST=y CONFIG_SSB_PCMCIAHOST=y # CONFIG_SSB_SILENT is not set # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE=y # Multifunction USB devices CONFIG_MFD_SM501=m # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y CONFIG_EXT2_FS_XIP=y CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set # CONFIG_EXT4DEV_FS is not set CONFIG_EXT4DEV_FS_XATTR=y CONFIG_EXT4DEV_FS_POSIX_ACL=y CONFIG_EXT4DEV_FS_SECURITY=y CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y CONFIG_XFS_FS=m # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_SECURITY=y CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="ascii" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_RAMFS=y CONFIG_DEBUG_FS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not seta CONFIG_AFFS_FS=m CONFIG_ECRYPT_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 # CONFIG_JFFS2_COMPRESSION_OPTIONS is not set CONFIG_JFFS2_FS_WRITEBUFFER=y CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y CONFIG_CRAMFS=m CONFIG_SQUASHFS=m # CONFIG_SQUASHFS_EMBEDDED is not set CONFIG_VXFS_FS=m # CONFIG_HPFS_FS is not set CONFIG_QNX4FS_FS=m # CONFIG_QNX4FS_RW is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # CONFIG_UFS_DEBUG is not set CONFIG_9P_FS=m CONFIG_FUSE_FS=m # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m # CONFIG_SMB_FS is not set # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_EXPERIMENTAL is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y CONFIG_CIFS_WEAK_PW_HASH=y # CONFIG_CIFS_DEBUG2 is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set # CONFIG_AFS_FS is not set # CONFIG_RXRPC is not set CONFIG_OCFS2_FS=m # CONFIG_OCFS2_DEBUG_MASKLOG is not set CONFIG_CONFIGFS_FS=m CONFIG_DLM=m CONFIG_DLM_DEBUG=y CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_NOLOCK=m CONFIG_GFS2_FS_LOCKING_DLM=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_NLS_ASCII=y # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_INFO=y # CONFIG_FRAME_POINTER is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y # CONFIG_DEBUG_DRIVER is not set CONFIG_HEADERS_CHECK=y # CONFIG_RCU_TORTURE_TEST is not set # CONFIG_LKDTM is not set # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_LOCKDEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # These debug options are deliberatly left on. # They aren't that much of a performance impact, and the value # from getting out-of-tree modules fixed is worth the trade-off. CONFIG_DEBUG_HIGHMEM=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_BOOT_DELAY=y CONFIG_DEBUG_SLAB_LEAK=y CONFIG_DEBUG_LIST=y CONFIG_DEBUG_SHIRQ=y CONFIG_DEBUG_DEVRES=y # # Security options # CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y CONFIG_SECURITY_NETWORK_XFRM=y CONFIG_SECURITY_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_SECURITY_SELINUX_DEVELOP=y CONFIG_SECURITY_SELINUX_AVC_STATS=y CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1 CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1 # CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT is not set CONFIG_UTS_NS=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # # Cryptographic options # CONFIG_CRYPTO=y CONFIG_CRYPTO_MANAGER=m CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CRC32C=m CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_MICHAEL_MIC=m CONFIG_CRYPTO_MPILIB=y CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_SIGNATURE_DSA=y CONFIG_CRYPTO_TEA=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_TWOFISH=m CONFIG_CRYPTO_WP512=m CONFIG_CRYPTO_XCBC=m # CONFIG_CRYPTO_TEST is not set CONFIG_LIBCRC32C=m # # Library routines # CONFIG_CRC16=m CONFIG_CRC32=m CONFIG_CRC_CCITT=m CONFIG_CRC_ITU_T=m CONFIG_EEPROM_93CX6=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_INITRAMFS_SOURCE="" CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set # CONFIG_ATA_OVER_ETH is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_BACKLIGHT_PROGEAR=m CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_RADEON_BACKLIGHT=y CONFIG_FB_ATY128_BACKLIGHT=y CONFIG_FB_ATY_BACKLIGHT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_SCHEDSTATS=y CONFIG_TUX=m CONFIG_TUX_EXTCGI=y CONFIG_TUX_EXTENDED_LOG=y # CONFIG_TUX_DEBUG is not set CONFIG_CPUSETS=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_MUST_CHECK=y CONFIG_DETECT_SOFTLOCKUP=y CONFIG_KEXEC=y CONFIG_HWMON=m # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_IBMASR=m CONFIG_PM_LEGACY=y # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_PM_DEBUG=y CONFIG_PM_TRACE=y # CONFIG_DISABLE_CONSOLE_SUSPEND is not set CONFIG_CRASH=m ## BEGIN ISA Junk. # CONFIG_I82365 is not set # CONFIG_TCIC is not set # CONFIG_PCMCIA_PROBE is not set # CONFIG_LTPC is not set # CONFIG_COPS is not set CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m # CONFIG_SCSI_IN2000 is not set CONFIG_SCSI_ARCMSR=m # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_CD_NO_IDESCSI is not set # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set CONFIG_EL3=m # CONFIG_3C515 is not set # CONFIG_LANCE is not set CONFIG_NET_VENDOR_SMC=y # CONFIG_WD80x3 is not set CONFIG_ULTRA=m # CONFIG_SMC9194 is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_NI52 is not set # CONFIG_NI65 is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set CONFIG_NET_ISA=y CONFIG_NE2000=m # CONFIG_E2100 is not set CONFIG_EWRK3=m # CONFIG_EEXPRESS is not set # CONFIG_EEXPRESS_PRO is not set # CONFIG_HPLAN_PLUS is not set # CONFIG_HPLAN is not set # CONFIG_LP486E is not set # CONFIG_ETH16I is not set # CONFIG_ZNET is not set # CONFIG_SEEQ8005 is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_IBMTR is not set # CONFIG_SKISA is not set # CONFIG_PROTEON is not set # CONFIG_SMCTR is not set # CONFIG_WAVELAN is not set # CONFIG_HISAX_16_0 is not set # CONFIG_HISAX_AVM_A1 is not set # CONFIG_HISAX_IX1MICROR2 is not set # CONFIG_HISAX_ASUSCOM is not set # CONFIG_HISAX_TELEINT is not set # CONFIG_HISAX_HFCS is not set # CONFIG_HISAX_SPORTSTER is not set # CONFIG_HISAX_MIC is not set # CONFIG_HISAX_ISURF is not set # CONFIG_HISAX_HSTSAPHIR is not set # CONFIG_ISDN_DRV_ICN is not set # CONFIG_ISDN_DRV_PCBIT is not set # CONFIG_ISDN_DRV_SC is not set # CONFIG_ISDN_DRV_ACT2000 is not set # CONFIG_ISDN_DRV_AVMB1_B1ISA is not set # CONFIG_ISDN_DRV_AVMB1_T1ISA is not set # CONFIG_MOUSE_INPORT is not set # CONFIG_MOUSE_ATIXL is not set # CONFIG_MOUSE_LOGIBM is not set # CONFIG_MOUSE_PC110PAD is not set # CONFIG_SERIAL_8250_FOURPORT is not set # CONFIG_SERIAL_8250_ACCENT is not set # CONFIG_SERIAL_8250_BOCA is not set # CONFIG_SERIAL_8250_HUB6 is not set # CONFIG_SERIAL_8250_EXAR_ST16C554 is not set # CONFIG_PCWATCHDOG is not set # CONFIG_WDT is not set # CONFIG_VIDEO_PMS is not set # CONFIG_RADIO_CADET is not set # CONFIG_RADIO_RTRACK is not set # CONFIG_RADIO_RTRACK2 is not set # CONFIG_RADIO_AZTECH is not set # CONFIG_RADIO_GEMTEK is not set # CONFIG_RADIO_SF16FMI is not set # CONFIG_RADIO_SF16FMR2 is not set # CONFIG_RADIO_TERRATEC is not set # CONFIG_RADIO_TRUST is not set # CONFIG_RADIO_TYPHOON is not set # CONFIG_RADIO_ZOLTRIX is not set # CONFIG_SND_OPL4_LIB is not set # CONFIG_SND_AD1848_LIB is not set # CONFIG_SND_AD1816A is not set # CONFIG_SND_AD1848 is not set # CONFIG_SND_CS4231 is not set # CONFIG_SND_CS4232 is not set CONFIG_SND_CS4231_LIB=m CONFIG_SND_CS4236=m # CONFIG_SND_ES968 is not set # CONFIG_SND_ES1688 is not set CONFIG_SND_ES18XX=m # CONFIG_SND_GUS_SYNTH is not set # CONFIG_SND_GUSCLASSIC is not set # CONFIG_SND_GUSEXTREME is not set # CONFIG_SND_GUSMAX is not set # CONFIG_SND_INTERWAVE is not set # CONFIG_SND_INTERWAVE_STB is not set # CONFIG_SND_OPTI92X_AD1848 is not set # CONFIG_SND_OPTI92X_CS4231 is not set # CONFIG_SND_OPTI93X is not set # CONFIG_SND_SB8 is not set CONFIG_SND_SB16=m CONFIG_SND_SBAWE=m # CONFIG_SND_SB16_CSP is not set # CONFIG_SND_ALS100 is not set # CONFIG_SND_AZT2320 is not set # CONFIG_SND_CMI8330 is not set # CONFIG_SND_DT019X is not set CONFIG_SND_OPL3SA2=m # CONFIG_SND_SGALAXY is not set # CONFIG_SND_SSCAPE is not set # CONFIG_SND_PDAUDIOCF is not set CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m # CONFIG_SND_SOC is not set ## END of ISA options. # CONFIG_FORCED_INLINING is not set CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # CONFIG_LEDS_CORGI is not set # CONFIG_LEDS_LOCOMO is not set # CONFIG_LEDS_SPITZ is not set # CONFIG_LEDS_IXP4XX is not set # CONFIG_LEDS_TOSA is not set # CONFIG_LEDS_S3C24XX is not set # CONFIG_LEDS_AMS_DELTA is not set # CONFIG_LEDS_NET48XX is not set CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_IDE_DISK=y CONFIG_LEDS_TRIGGER_HEARTBEAT=m CONFIG_DMA_ENGINE=y CONFIG_NET_DMA=y CONFIG_INTEL_IOATDMA=m # CONFIG_UNUSED_SYMBOLS is not set CONFIG_UTRACE=y CONFIG_PTRACE=y CONFIG_KPROBES=y # CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set CONFIG_HZ_1000=y CONFIG_TIMER_STATS=y # Auxillary displays CONFIG_KS0108=m CONFIG_KS0108_PORT=0x378 CONFIG_KS0108_DELAY=2 CONFIG_CFAG12864B=y CONFIG_CFAG12864B_RATE=20 # CONFIG_DEBUG_IGNORE_QUIET is not set # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_SLEEP_IN_IRQ is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_FAULT_INJECTION is not set # CONFIG_FAILSLAB is not set # CONFIG_FAIL_PAGE_ALLOC is not set # CONFIG_FAIL_MAKE_REQUEST is not set # CONFIG_FAULT_INJECTION_DEBUG_FS is not set # CONFIG_FAULT_INJECTION_STACKTRACE_FILTER is not set CONFIG_UID16=y # CONFIG_X86_PC is not set CONFIG_X86_GENERICARCH=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_ES7000 is not set # CONFIG_M386 is not set # CONFIG_M486 is not set CONFIG_M586=y # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_NR_CPUS=32 CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_HPET=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_HPET_RTC_IRQ is not set # CONFIG_HPET_MMAP is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m # CONFIG_NUMA is not set CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_X86_PM_TIMER=y CONFIG_EFI=y CONFIG_EFI_VARS=y CONFIG_EFI_PCDP=y CONFIG_EFI_RTC=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set # CONFIG_PCI_GOMMCONFIG is not set CONFIG_PCI_GOANY=y # CONFIG_SECCOMP is not set CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m CONFIG_I2O_CONFIG=y CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_EXT_ADAPTEC_DMA64=y CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=m CONFIG_APM=y # CONFIG_APM_IGNORE_USER_SUSPEND is not set # CONFIG_APM_DO_ENABLE is not set CONFIG_APM_CPU_IDLE=y # CONFIG_APM_DISPLAY_BLANK is not set CONFIG_APM_RTC_IS_GMT=y # CONFIG_APM_ALLOW_INTS is not set # CONFIG_APM_REAL_MODE_POWER_OFF is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_ACPI=y CONFIG_ACPI_AC=m # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BAY=m CONFIG_ACPI_IBM_BAY=y CONFIG_ACPI_BLACKLIST_YEAR=1999 CONFIG_ACPI_BUTTON=m CONFIG_ACPI_CONTAINER=m # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_DOCK=m CONFIG_ACPI_EC=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_IBM_DOCK is not set CONFIG_ACPI_NUMA=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_SBS=m CONFIG_ACPI_SLEEP=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_SYSTEM=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_VIDEO=m CONFIG_PNPACPI=y CONFIG_ASUS_LAPTOP=m CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEBUG=y # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_CPU_FREQ_TABLE=y CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set CONFIG_X86_POWERNOW_K6=m # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set CONFIG_X86_SPEEDSTEP_LIB=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set # CONFIG_X86_P4_CLOCKMOD is not set CONFIG_X86_LONGRUN=y # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set CONFIG_X86_E_POWERSAVER=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_TWOFISH_586=m # CONFIG_CRYPTO_DEV_PADLOCK is not set # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set # CONFIG_CRYPTO_DEV_PADLOCK_SHA is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_SCHED_SMT=y # CONFIG_IRQBALANCE is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y CONFIG_4KSTACKS=y CONFIG_DEBUG_NMI_TIMEOUT=5 # CONFIG_DEBUG_PAGEALLOC is not set CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_BIOS=y # CONFIG_HOTPLUG_PCI is not set CONFIG_HOTPLUG_PCI_COMPAQ=m # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_HOTPLUG_PCI_IBM=m # CONFIG_HOTPLUG_PCI_CPCI is not set # CONFIG_HOTPLUG_PCI_SHPC is not set CONFIG_PM=y CONFIG_IPW2100_MONITOR=y CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y CONFIG_I2C_ISA=m # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_PC8736x_GPIO=m # CONFIG_NSC_GPIO is not set CONFIG_CS5535_GPIO=m CONFIG_EDAC=y # CONFIG_EDAC_DEBUG is not set CONFIG_EDAC_MM_EDAC=m CONFIG_EDAC_AMD76X=m CONFIG_EDAC_E7XXX=m CONFIG_EDAC_E752X=m CONFIG_EDAC_I82875P=m CONFIG_EDAC_I82860=m CONFIG_EDAC_R82600=m CONFIG_EDAC_K8=m CONFIG_SCHED_MC=y CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_GEODE=m CONFIG_HW_RANDOM_VIA=m # CONFIG_COMPAT_VDSO is not set # CONFIG_SGI_IOC4 is not set CONFIG_MSI_LAPTOP=m # CONFIG_SMSC37B787_WDT is not set CONFIG_W83697HF_WDT=m # CONFIG_PARAVIRT is not set CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x400000 CONFIG_PHYSICAL_START=0x1000000 CONFIG_PROC_VMCORE=y CONFIG_CRYPTO_DEV_GEODE=m CONFIG_KVM=m CONFIG_KVM_INTEL=m CONFIG_KVM_AMD=m CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m CONFIG_SONY_LAPTOP=m CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set From tve at voneicken.com Wed Aug 29 15:48:56 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Wed, 29 Aug 2007 08:48:56 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <20070829152612.GA32421@gospo.rdu.redhat.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> Message-ID: <46D59568.4050908@voneicken.com> Andy Gospodarek wrote: > Thanks for sending that. I'll take a look at this config and see if I > see anything. For reference I've attached the i586 config from f7, so > it might be worth doing a rebuild of the rpm with a similar config. Thanks. I'll definitely try that. Any reason I shouldn't start with the i386 kernel config from f7 instead? > It's also worth noting that the liveCD doesn't claim to support i586 > platforms: I would assume that's because only an i686 kernel is included. > I also wondered if anything that was built needing kernel-devel or > kernel-headers might need to be rebuilt for i586, but there are only a > few i586 specific packages available in f7 (one of which is > kernel-devel), so I'm not sure how important that is. Good point. But as far as I can tell, since I'm using the following in the kickstart: repo --name=a-dev --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/i386/os/ I should be getting i386 versions of everything into my live-cd. Is there anything that comes from i686-land that I'm overlooking? I guess I could try to recompile kernel-devel and glibc from source. Mhh, not sure how to set that up. Thanks again for the follow-up! We'll get there... Thorsten From gospo at redhat.com Wed Aug 29 21:00:02 2007 From: gospo at redhat.com (Andy Gospodarek) Date: Wed, 29 Aug 2007 17:00:02 -0400 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <46D59568.4050908@voneicken.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> <46D59568.4050908@voneicken.com> Message-ID: <20070829210001.GF32421@gospo.rdu.redhat.com> On Wed, Aug 29, 2007 at 08:48:56AM -0700, Thorsten von Eicken wrote: > Andy Gospodarek wrote: > >Thanks for sending that. I'll take a look at this config and see if I > >see anything. For reference I've attached the i586 config from f7, so > >it might be worth doing a rebuild of the rpm with a similar config. > Thanks. I'll definitely try that. Any reason I shouldn't start with the > i386 kernel config from f7 instead? > > >It's also worth noting that the liveCD doesn't claim to support i586 > >platforms: > I would assume that's because only an i686 kernel is included. > > >I also wondered if anything that was built needing kernel-devel or > >kernel-headers might need to be rebuilt for i586, but there are only a > >few i586 specific packages available in f7 (one of which is > >kernel-devel), so I'm not sure how important that is. > Good point. But as far as I can tell, since I'm using the following in > the kickstart: > repo --name=a-dev > --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/i386/os/ > I should be getting i386 versions of everything into my live-cd. Is > there anything that comes from i686-land that I'm overlooking? The kernel definitely has only i586 and i686 support: kernel-2.6.21-1.3194.fc7.i586.rpm kernel-2.6.21-1.3194.fc7.i686.rpm kernel-PAE-2.6.21-1.3194.fc7.i686.rpm kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm kernel-PAE-debug-devel-2.6.21-1.3194.fc7.i686.rpm kernel-PAE-devel-2.6.21-1.3194.fc7.i686.rpm kernel-debug-2.6.21-1.3194.fc7.i686.rpm kernel-debug-devel-2.6.21-1.3194.fc7.i686.rpm kernel-devel-2.6.21-1.3194.fc7.i586.rpm kernel-devel-2.6.21-1.3194.fc7.i686.rpm kernel-doc-2.6.21-1.3194.fc7.noarch.rpm kernel-headers-2.6.21-1.3194.fc7.i386.rpm kernel-xen-2.6-doc-2.6.20-2925.9.fc7.noarch.rpm kernel-xen-2.6.20-2925.9.fc7.i686.rpm kernel-xen-devel-2.6.20-2925.9.fc7.i686.rpm so you might want to specifically include the i586 flavors so you don't get the i686 ones. You also might want to try and specifically pick up the correct version of glibc: glibc-2.6-3.i386.rpm glibc-2.6-3.i686.rpm glibc-common-2.6-3.i386.rpm glibc-devel-2.6-3.i386.rpm glibc-headers-2.6-3.i386.rpm > I guess I could try to recompile kernel-devel and glibc from source. > Mhh, not sure how to set that up. > > Thanks again for the follow-up! We'll get there... > Thorsten > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From tve at voneicken.com Thu Aug 30 04:15:02 2007 From: tve at voneicken.com (Thorsten von Eicken) Date: Wed, 29 Aug 2007 21:15:02 -0700 Subject: [Fedora-livecd-list] boot failure on VIA Epia M-6000 board In-Reply-To: <20070829210001.GF32421@gospo.rdu.redhat.com> References: <46D25265.9080904@voneicken.com> <20070827140849.GY29579@gospo.rdu.redhat.com> <46D2F591.8030203@voneicken.com> <20070827171515.GE29579@gospo.rdu.redhat.com> <46D3AF6F.4060107@voneicken.com> <20070829152612.GA32421@gospo.rdu.redhat.com> <46D59568.4050908@voneicken.com> <20070829210001.GF32421@gospo.rdu.redhat.com> Message-ID: <46D64446.7080003@voneicken.com> Andy Gospodarek wrote: > On Wed, Aug 29, 2007 at 08:48:56AM -0700, Thorsten von Eicken wrote: >> Good point. But as far as I can tell, since I'm using the following in >> the kickstart: >> repo --name=a-dev >> --baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/7/Everything/i386/os/ >> I should be getting i386 versions of everything into my live-cd. Is >> there anything that comes from i686-land that I'm overlooking? > > The kernel definitely has only i586 and i686 support: > > kernel-2.6.21-1.3194.fc7.i586.rpm > kernel-2.6.21-1.3194.fc7.i686.rpm > kernel-PAE-2.6.21-1.3194.fc7.i686.rpm > kernel-PAE-debug-2.6.21-1.3194.fc7.i686.rpm > kernel-PAE-debug-devel-2.6.21-1.3194.fc7.i686.rpm > kernel-PAE-devel-2.6.21-1.3194.fc7.i686.rpm > kernel-debug-2.6.21-1.3194.fc7.i686.rpm > kernel-debug-devel-2.6.21-1.3194.fc7.i686.rpm > kernel-devel-2.6.21-1.3194.fc7.i586.rpm > kernel-devel-2.6.21-1.3194.fc7.i686.rpm > kernel-doc-2.6.21-1.3194.fc7.noarch.rpm > kernel-headers-2.6.21-1.3194.fc7.i386.rpm > kernel-xen-2.6-doc-2.6.20-2925.9.fc7.noarch.rpm > kernel-xen-2.6.20-2925.9.fc7.i686.rpm > kernel-xen-devel-2.6.20-2925.9.fc7.i686.rpm > > so you might want to specifically include the i586 flavors so you don't > get the i686 ones. Ouch, everything in that repo is i386 except for the kernel stuff. Nasty! Why bother having i386 versions of the rest??? Go figure... I'll produce a i586 kernel and see what happens. Thanks for spotting this. Thorsten From chitlesh at fedoraproject.org Thu Aug 30 12:41:58 2007 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 30 Aug 2007 14:41:58 +0200 Subject: [Fedora-livecd-list] kickstart file for FEL In-Reply-To: <1188226725.2365.41.camel@localhost.localdomain> References: <13dbfe4f0708261423q4fc2b1c4u592cbc7f50af3b9e@mail.gmail.com> <1188226725.2365.41.camel@localhost.localdomain> Message-ID: <13dbfe4f0708300541q15b7e525g6f2208602377b93c@mail.gmail.com> On 8/27/07, Jeremy Katz wrote: > On Sun, 2007-08-26 at 23:23 +0200, Chitlesh GOORAH wrote: > My first suggestion would be to try to have it %include > livecd-fedora-base-desktop.ks; that way, it will have to duplicate a > little bit less, making looking at the actual changes a little easier. > But trying to extract out a diff, a few questions Ok, now it's tuned to include livecd-fedora-base-desktop.ks http://chitlesh.fedorapeople.org/FEL/livecd-fedora-electronic-lab.ks The list of rpm installed: http://chitlesh.fedorapeople.org/FEL/rpmlist Total size of ISO: 658.5 MB from today's rawhide. (Jesse says the latter is 2 days old) The same kickstart file was used 2 days ago, and the size was 691 MB As from zenity's requirement of firefox: [root at localhost ~]# rpm -e firefox error: Failed dependencies: libgtkembedmoz.so is needed by (installed) yelp-2.19.90-2.fc8.i386 libxpcom.so is needed by (installed) yelp-2.19.90-2.fc8.i386 libxpcom_core.so is needed by (installed) yelp-2.19.90-2.fc8.i386 gecko-libs = 1.8.1.6 is needed by (installed) yelp-2.19.90-2.fc8.i386 [root at localhost ~]# rpm -e firefox yelp error: Failed dependencies: yelp is needed by (installed) zenity-2.19.2-2.fc8.i386 [root at localhost ~]# rpm -e firefox yelp zenity error: Failed dependencies: zenity is needed by (installed) anaconda-11.3.0.22-1.i386 [root at localhost ~]# regards, Chitlesh -- http://clunixchit.blogspot.com From lars.bjorndal at broadpark.no Thu Aug 30 13:54:30 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Thu, 30 Aug 2007 15:54:30 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: (Lars =?iso-8859-1?Q?Bj=F8rn?= =?iso-8859-1?Q?dal's?= message of "Tue, 28 Aug 2007 15:17:40 +0200") References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> Message-ID: Hello! I still cannot manage to create a --live-optical CD with revisor. Yesterday, I downloaded and installed both revisor and livecd-tools from GIT. I ran the command: revisor --model=lrs --live-optical --debug The model lrs is a modified f7, with yum.conf set as config file. Some of the output was: {'modrebrand': False, 'modjigdo': False, 'modcobbler': False, 'moddelta': False, 'modvirt': False} Setting default options Setting options from configuration file Reading configuration file /etc/revisor/revisor.conf Setting repos_enabledevelopment to 0 (from configuration file) Setting repos_enabletesting to 0 (from configuration file) Setting media_installation_cd to 0 (from configuration file) Setting media_installation_dvd to 0 (from configuration file) Setting mode_respin to 0 (from configuration file) Setting repos_enablesource to 0 (from configuration file) Setting media_live_optical to 0 (from configuration file) Setting dependency_resolve_allow_conflicts to 0 (from configuration file) Setting repos_enabledebuginfo to 0 (from configuration file) Setting media_live_thumb to 0 (from configuration file) Using model lrs, as specified by --model Setting architecture to 'i386' (from configuration file model lrs) Setting iso_basename to 'F' (from configuration file model lrs) Setting getsource to 0 (from configuration file model lrs) Setting version to '7' (from configuration file model lrs) Setting product_path to 'Fedora' (from configuration file model lrs) Setting product_name to 'Fedora' (from configuration file model lrs) Setting comps to '/usr/share/revisor/comps/comps-f7.xml' (from configuration file model lrs) Setting options from command-line Running Revisor in CLI mode... Running main routine... Running in CLI mode... Setting architecture to 'i386' (from configuration file model lrs) Setting iso_basename to 'F' (from configuration file model lrs) Setting getsource to 0 (from configuration file model lrs) Setting version to '7' (from configuration file model lrs) Setting product_path to 'Fedora' (from configuration file model lrs) Setting product_name to 'Fedora' (from configuration file model lrs) Setting comps to '/usr/share/revisor/comps/comps-f7.xml' (from configuration file model lrs) Checking working directories The directories Revisor uses in /var/tmp/ already exist. This could possibly hold data from a previous run. Please remove or move them to a safe location, then confirm to continue. If you do not move or remove the files, Revisor will simply delete them. Do you want to continue? [Y/n] y ... Downloading Packages: Initting progress bar for Setting up Ext3 Filesystem Setting up Ext3 Filesystem: Setting up Ext3 Filesystem: 0.0% mke2fs 1.40.2 (12-Jul-2007) Filesystem label=livecd-20070830 OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 219072 inodes, 437504 blocks 4375 blocks (1.00%) reserved for the super user First data block=0 Maximum filesystem blocks=448790528 14 block groups 32768 blocks per group, 32768 fragments per group 15648 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Writing inode tables: 0/14 Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 32 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. tune2fs 1.40.2 (12-Jul-2007) Setting maximal mount count to -1 Setting interval between checks to 0 seconds Cannot setup installation target. Aborting. Do you want to continue? [Y/n] y [root at cd ~]# mount /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) /dev/proc on /proc type proc (rw) /dev/sys on /sys type sysfs (rw) /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) /dev/shm on /dev/shm type tmpfs (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /dev/loop0 on / type ext3 (rw) [root at cd ~]# losetup -a /dev/loop0: [fd00]:130579 (/var/tmp/revisor-livecd/data/os.img) [root at cd ~]# ls -al /var/tmp/revisor-livecd/data/os.img -rwxr-xr-x 1 root root 1792016385 2007-08-30 15:33 /var/tmp/revisor-livecd/data/os.img What can I do, I wonder? Lars From dmc.fedora at filteredperception.org Thu Aug 30 20:49:16 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Thu, 30 Aug 2007 15:49:16 -0500 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> Message-ID: <46D72D4C.1040500@filteredperception.org> Lars Bj?rndal wrote: > Hello! > > I still cannot manage to create a --live-optical CD with revisor. > Yesterday, I downloaded and installed both revisor and livecd-tools > from GIT. I have next to no experience with revisor, but this is the second time I've seen something like this on this list- > [root at cd ~]# mount > /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) ... > /dev/loop0 on / type ext3 (rw) > > [root at cd ~]# losetup -a > /dev/loop0: [fd00]:130579 (/var/tmp/revisor-livecd/data/os.img) What is up with that? ('/dev/loop0' mounted(???) on '/') That would make me a bit anxious if I saw it on my system... Or is it just some weird chroot/mtab/fstab artifact causing the output of mount to not actually reflect reality? Mainly this goes to my fear of running something like livecd-creator as root... (even if the only other way involves virtualization and 10X slowdown in performance) -dmc From kanarip at kanarip.com Thu Aug 30 21:33:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 30 Aug 2007 23:33:17 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D72D4C.1040500@filteredperception.org> References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> <46D72D4C.1040500@filteredperception.org> Message-ID: <46D7379D.8070702@kanarip.com> Douglas McClendon wrote: > Lars Bj?rndal wrote: >> Hello! >> >> I still cannot manage to create a --live-optical CD with revisor. >> Yesterday, I downloaded and installed both revisor and livecd-tools >> from GIT. > > I have next to no experience with revisor, but this is the second time > I've seen something like this on this list- > One has got to know that GIT is unstable; It eats babies. For breakfast. If you happen to clone anything I'm just pushing from my -devel to my -test machine, and it destroys your machine, you're busted. Use the tags; we use them to mark a point at which we think there's no regression in what was in the feature set of a previous /release/. Bugs get fixed, GIT is updated multiple times a day; check what is in the commit logs before you make your move; we often message "Oops" and "Let's try this or that". >> [root at cd ~]# mount >> /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) > ... >> /dev/loop0 on / type ext3 (rw) >> >> [root at cd ~]# losetup -a >> /dev/loop0: [fd00]:130579 (/var/tmp/revisor-livecd/data/os.img) > What commit does this exactly? Kind regards, Jeroen van Meeuwen -kanarip From lars.bjorndal at broadpark.no Fri Aug 31 07:31:42 2007 From: lars.bjorndal at broadpark.no (Lars =?iso-8859-1?Q?Bj=F8rndal?=) Date: Fri, 31 Aug 2007 09:31:42 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: <46D7379D.8070702@kanarip.com> (Jeroen van Meeuwen's message of "Thu, 30 Aug 2007 23:33:17 +0200") References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> <46D72D4C.1040500@filteredperception.org> <46D7379D.8070702@kanarip.com> Message-ID: Jeroen van Meeuwen writes: > Douglas McClendon wrote: >> Lars Bj?rndal wrote: >>> [root at cd ~]# mount >>> /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) >> ... >>> /dev/loop0 on / type ext3 (rw) >>> >>> [root at cd ~]# losetup -a >>> /dev/loop0: [fd00]:130579 (/var/tmp/revisor-livecd/data/os.img) >> > > What commit does this exactly? 0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac Maybe the problem is related to that I'm using the /etc/yum.conf file. The cache dir is then set to /var/cache/yum, and not to a directory under /var/tmp/revisor. Maybe the files are not found then? I'll have a look in that direction. Lars From kanarip at kanarip.com Fri Aug 31 07:57:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 09:57:17 +0200 Subject: [Fedora-livecd-list] Revisor: Cannot setup installation target. Aborting. In-Reply-To: References: <46D02830.90305@kanarip.com> <20070825152310.GB4485@lamasti.net> <46D04C8A.5010209@kanarip.com> <46D15BCD.3000905@kanarip.com> <20070826134847.GD4485@lamasti.net> <46D194CE.7020700@kanarip.com> <20070826163949.GE4485@lamasti.net> <46D72D4C.1040500@filteredperception.org> <46D7379D.8070702@kanarip.com> Message-ID: <46D7C9DD.1020108@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lars Bj?rndal wrote: > Jeroen van Meeuwen writes: > >> Douglas McClendon wrote: >>> Lars Bj?rndal wrote: >>>> [root at cd ~]# mount >>>> /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw) >>> ... >>>> /dev/loop0 on / type ext3 (rw) >>>> >>>> [root at cd ~]# losetup -a >>>> /dev/loop0: [fd00]:130579 (/var/tmp/revisor-livecd/data/os.img) >> What commit does this exactly? > > 0ad6a3da49ff75fbfcd5802c5b03de51d9d014ac > > Maybe the problem is related to that I'm using the /etc/yum.conf file. Please, do not use the /etc/yum.conf. Any variables used in /etc/yum.conf and the repository configuration do not get expanded. The installroot of /etc/yum.conf is "/". That also explains how os.img gets mounted there. Use the revisor yum configuration files in /etc/revisor/conf.d/, create your own or modify these. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG18ndKN6f2pNCvwgRAk4tAKDQBK9NDwtUASYFA2qYj0RS1f/cvgCglxYG e5bDJ5bwtwxeDJQwP7r2pBY= =m0xv -----END PGP SIGNATURE----- From kanarip at kanarip.com Fri Aug 31 08:24:35 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 10:24:35 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's Message-ID: <46D7D043.6030003@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's a thought: 1304 random packages will install 724 MB of data in /usr/share/doc I'm sure there is /something/ to gain here. If every package on average installs ~0.5 MB of docs... Would it worth figuring out what docs should be on the LiveCD in the first place? I guess removing everything RPM calls docs is too much, as this will include man-pages as well. Any thoughts? - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG19BDKN6f2pNCvwgRAhhaAJ9UCH9WetRBu6foxAgztqMvg3h6OwCeLZU5 LxWzG5TBxdQOAE3VGFp400w= =YiuK -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Fri Aug 31 08:51:37 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 03:51:37 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D043.6030003@kanarip.com> References: <46D7D043.6030003@kanarip.com> Message-ID: <46D7D699.2090809@filteredperception.org> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's a thought: > > 1304 random packages will install 724 MB of data in /usr/share/doc > > I'm sure there is /something/ to gain here. If every package on average > installs ~0.5 MB of docs... Would it worth figuring out what docs should > be on the LiveCD in the first place? I guess removing everything RPM > calls docs is too much, as this will include man-pages as well. > > Any thoughts? Setting asside the redundant fedora-devel changelog thread aspects of the discussion... Back when I was squeezing mandrake-7.2 into a 130MB zisofs-d livecd, blindly nuking /usr/share/doc was one of the first things I did (in addition to nuking /var/lib/rpm) But of course there are reasons to want at least parts of both of those things. IMO, the idealistic unrealistic solution (the kind I love talking about the most), is to add a couple 'tunables' to the way rpm deals with stuff. One tunable would be language support. At the low end, just give me the default system language and any other languages I've told the system to support. On the high end, give me all languages available. In between, give me a sliding scale based on language popularity. The next tunable, would be a generic size one. On the low end, would be the minimal files needed for the minimal functionality of the package. On the high end would be every optional extra the package could possibly use. In between again, a sliding scale based on popularity of optional component. Then, you have a yum/rpm command, so that in one fell swoop, you can tweak these tunables for all packages in the system. This would come in very handy if you ran into a situation where all of a sudden you needed to free up some disk space, or if all of a sudden you increased from a 40G disk to a 400G disk. (or if of course you are tuning a livecd install for minimal size) Likewise, during installation, the installer could choose a reasonable setting based on the size of the destination volume. $0.02... -dmc From tla at rasmil.dk Fri Aug 31 08:47:49 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 31 Aug 2007 10:47:49 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D043.6030003@kanarip.com> References: <46D7D043.6030003@kanarip.com> Message-ID: <46D7D5B5.60500@rasmil.dk> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's a thought: > > 1304 random packages will install 724 MB of data in /usr/share/doc > > I'm sure there is /something/ to gain here. If every package on average > installs ~0.5 MB of docs... Would it worth figuring out what docs should > be on the LiveCD in the first place? I guess removing everything RPM > calls docs is too much, as this will include man-pages as well. > > Any thoughts? > > I think it is a bad idea, because many people uses the Live CD's to install to their systems, and then they end up with a system without doc files, with no easy way to get the docs back on the systems. Tim From kanarip at kanarip.com Fri Aug 31 08:56:52 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 10:56:52 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D5B5.60500@rasmil.dk> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> Message-ID: <46D7D7D4.8060002@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Lauridsen wrote: > Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? >> >> > I think it is a bad idea, because many people uses the Live CD's to > install to their systems, and then they end up with a system > without doc files, with no easy way to get the docs back on the systems. > That's not true as anaconda needs the RPMs to install to a system, right? Last time I checked a LiveCD could not be installed "offline" because of this. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG19fTKN6f2pNCvwgRAs7bAJ9UrHYNddpRhOq2Ezmo2mSV7hnzugCfe45p 1XKG7iFgRoWYmRK4URgZ510= =whWy -----END PGP SIGNATURE----- From kanarip at kanarip.com Fri Aug 31 09:01:09 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 11:01:09 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D699.2090809@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <46D7D699.2090809@filteredperception.org> Message-ID: <46D7D8D5.7030904@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? > > [....] > > $0.02... > This however does not concern whether we may or may not have unneeded files on the LiveCD as of *right now*, and if we could possibly delete those files (manually yet automated) to save space. We're not talking yum/rpm extensions, we're talking subprocess.call(["rm","-rf","/usr/share/doc/some/dir"], preexecfn=self.run_in_root) - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG19jVKN6f2pNCvwgRArlMAJ903NlHx3YOJ4xcAK1nVxXPNsgAvwCffb63 +ldSmTb7t6LlGO+fSBsAkW0= =jfrc -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Fri Aug 31 09:03:31 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 04:03:31 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D5B5.60500@rasmil.dk> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> Message-ID: <46D7D963.1040606@filteredperception.org> Tim Lauridsen wrote: > Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? >> >> > I think it is a bad idea, because many people uses the Live CD's to > install to their systems, and then they end up with a system > without doc files, with no easy way to get the docs back on the systems. That's really not such a hard thing to fix - the easy way to get things back after installation. It also relates to a feature I proposed a long time ago "yum spininstall" Which would be an easy way to take a livecd installed system, and presuming online access to good yum repos, trivially upgrade with one command to the type of default system that you would have gotten if you had installed from DVD instead of CD. I.e. I was really peeved that the man-pages rpm did not get installed (amonst many other subtle choices made in the name of space fitting). But I didn't want to waste time finding out the specific things I really wanted, when really I just wanted a "normal system" as defined by the choices made for the defaults selected on the non-space-constrained DVD spin. My theory was that you could take the package selections of the spins, wrap them in groups, such that with a single yum command, after installing from livecd, you could get all the packages that would have been installed from the traditional DVD spin. Likewise, if you got an itch to do ASIC design, and you had just installed the normal fedora desktop livecd spin, then you could do something like "yum spininstall FedoraElectronicLab". (spininstall is just a random illustration, it could easily enough be wrapped into the existing groupinstall command). -dmc From dmc.fedora at filteredperception.org Fri Aug 31 09:05:19 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 04:05:19 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D8D5.7030904@kanarip.com> References: <46D7D043.6030003@kanarip.com> <46D7D699.2090809@filteredperception.org> <46D7D8D5.7030904@kanarip.com> Message-ID: <46D7D9CF.2040302@filteredperception.org> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Douglas McClendon wrote: >> Jeroen van Meeuwen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's a thought: >>> >>> 1304 random packages will install 724 MB of data in /usr/share/doc >>> >>> I'm sure there is /something/ to gain here. If every package on average >>> installs ~0.5 MB of docs... Would it worth figuring out what docs should >>> be on the LiveCD in the first place? I guess removing everything RPM >>> calls docs is too much, as this will include man-pages as well. >>> >>> Any thoughts? >> [....] >> >> $0.02... >> > > This however does not concern whether we may or may not have unneeded > files on the LiveCD as of *right now*, and if we could possibly delete > those files (manually yet automated) to save space. > > We're not talking yum/rpm extensions, we're talking > subprocess.call(["rm","-rf","/usr/share/doc/some/dir"], > preexecfn=self.run_in_root) > What part of " IMO, the idealistic unrealistic solution (the kind I love talking about the most) " went over your head ;) -dmc > - -- > Kind regards, > > Jeroen van Meeuwen > - -kanarip > > - -- > http://www.kanarip.com/ > RHCE, LPIC-2, MCP, CCNA > C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > > iD8DBQFG19jVKN6f2pNCvwgRArlMAJ903NlHx3YOJ4xcAK1nVxXPNsgAvwCffb63 > +ldSmTb7t6LlGO+fSBsAkW0= > =jfrc > -----END PGP SIGNATURE----- > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list From dmc.fedora at filteredperception.org Fri Aug 31 09:08:09 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 04:08:09 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D7D4.8060002@kanarip.com> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> Message-ID: <46D7DA79.8050506@filteredperception.org> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Lauridsen wrote: >> Jeroen van Meeuwen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's a thought: >>> >>> 1304 random packages will install 724 MB of data in /usr/share/doc >>> >>> I'm sure there is /something/ to gain here. If every package on average >>> installs ~0.5 MB of docs... Would it worth figuring out what docs should >>> be on the LiveCD in the first place? I guess removing everything RPM >>> calls docs is too much, as this will include man-pages as well. >>> >>> Any thoughts? >>> >>> >> I think it is a bad idea, because many people uses the Live CD's to >> install to their systems, and then they end up with a system >> without doc files, with no easy way to get the docs back on the systems. >> > > That's not true as anaconda needs the RPMs to install to a system, > right? Last time I checked a LiveCD could not be installed "offline" > because of this. I think you really need to check again. The current liveinst installer (which uses the LiveCDCopy anaconda backend) does not need the rpms, it just copies the ext3 filesystem image block for block from the livecd to the disk. i.e. all those threads in the past about the livecd installer wiping the root partition, formatting the root partition twice, being able to be sped up by 20+% with my turboLiveInst patch that jeremy is afraid of, etc... -dmc From kanarip at kanarip.com Fri Aug 31 09:13:07 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 11:13:07 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D9CF.2040302@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <46D7D699.2090809@filteredperception.org> <46D7D8D5.7030904@kanarip.com> <46D7D9CF.2040302@filteredperception.org> Message-ID: <46D7DBA3.4080407@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > Jeroen van Meeuwen wrote: > Douglas McClendon wrote: >>>> Jeroen van Meeuwen wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Here's a thought: >>>>> >>>>> 1304 random packages will install 724 MB of data in /usr/share/doc >>>>> >>>>> I'm sure there is /something/ to gain here. If every package on average >>>>> installs ~0.5 MB of docs... Would it worth figuring out what docs >>>>> should >>>>> be on the LiveCD in the first place? I guess removing everything RPM >>>>> calls docs is too much, as this will include man-pages as well. >>>>> >>>>> Any thoughts? >>>> [....] >>>> >>>> $0.02... >>>> > > This however does not concern whether we may or may not have unneeded > files on the LiveCD as of *right now*, and if we could possibly delete > those files (manually yet automated) to save space. > > We're not talking yum/rpm extensions, we're talking > subprocess.call(["rm","-rf","/usr/share/doc/some/dir"], > preexecfn=self.run_in_root) > > >> What part of > >> " >> IMO, the idealistic unrealistic solution (the kind I love talking about >> the most) >> " > >> went over your head ;) > I'm sorry; the OT part. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG19uiKN6f2pNCvwgRAsoDAJ0UweOc6w7RUY7bNA1VZ6ZteyTMegCeJnJ5 NqBbgxb55z11EGuEE9WBI30= =QFDT -----END PGP SIGNATURE----- From kanarip at kanarip.com Fri Aug 31 09:18:17 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 11:18:17 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7DA79.8050506@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> <46D7DA79.8050506@filteredperception.org> Message-ID: <46D7DCD9.80405@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tim Lauridsen wrote: >>> Jeroen van Meeuwen wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Here's a thought: >>>> >>>> 1304 random packages will install 724 MB of data in /usr/share/doc >>>> >>>> I'm sure there is /something/ to gain here. If every package on average >>>> installs ~0.5 MB of docs... Would it worth figuring out what docs >>>> should >>>> be on the LiveCD in the first place? I guess removing everything RPM >>>> calls docs is too much, as this will include man-pages as well. >>>> >>>> Any thoughts? >>>> >>>> >>> I think it is a bad idea, because many people uses the Live CD's to >>> install to their systems, and then they end up with a system >>> without doc files, with no easy way to get the docs back on the systems. >>> >> >> That's not true as anaconda needs the RPMs to install to a system, >> right? Last time I checked a LiveCD could not be installed "offline" >> because of this. > > I think you really need to check again. The current liveinst installer > (which uses the LiveCDCopy anaconda backend) does not need the rpms, it > just copies the ext3 filesystem image block for block from the livecd to > the disk. i.e. all those threads in the past about the livecd installer > wiping the root partition, formatting the root partition twice, being > able to be sped up by 20+% with my turboLiveInst patch that jeremy is > afraid of, etc... > Should the way liveinst installer installs to the user's system limit what space we can save on a LiveCD? I don't think so. Just like there's a use-case for installing from a LiveCD, there's a use case for "rm - -rf'ing" as much as one can to save space on the Live Media. Does liveinst still support installing from RPMs as well? - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG19zZKN6f2pNCvwgRAgYJAJwK5MhN2SslOx2VBkwdu9BcqJ4rEgCgr+i5 ujfwwGgYMBYXOpc71jZ6M34= =pUml -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Fri Aug 31 09:41:28 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 04:41:28 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7DCD9.80405@kanarip.com> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> <46D7DA79.8050506@filteredperception.org> <46D7DCD9.80405@kanarip.com> Message-ID: <46D7E248.8010701@filteredperception.org> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Douglas McClendon wrote: >> Jeroen van Meeuwen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Tim Lauridsen wrote: >>>> Jeroen van Meeuwen wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Here's a thought: >>>>> >>>>> 1304 random packages will install 724 MB of data in /usr/share/doc >>>>> >>>>> I'm sure there is /something/ to gain here. If every package on average >>>>> installs ~0.5 MB of docs... Would it worth figuring out what docs >>>>> should >>>>> be on the LiveCD in the first place? I guess removing everything RPM >>>>> calls docs is too much, as this will include man-pages as well. >>>>> >>>>> Any thoughts? >>>>> >>>>> >>>> I think it is a bad idea, because many people uses the Live CD's to >>>> install to their systems, and then they end up with a system >>>> without doc files, with no easy way to get the docs back on the systems. >>>> >>> That's not true as anaconda needs the RPMs to install to a system, >>> right? Last time I checked a LiveCD could not be installed "offline" >>> because of this. >> I think you really need to check again. The current liveinst installer >> (which uses the LiveCDCopy anaconda backend) does not need the rpms, it >> just copies the ext3 filesystem image block for block from the livecd to >> the disk. i.e. all those threads in the past about the livecd installer >> wiping the root partition, formatting the root partition twice, being >> able to be sped up by 20+% with my turboLiveInst patch that jeremy is >> afraid of, etc... >> > > Should the way liveinst installer installs to the user's system limit > what space we can save on a LiveCD? I don't think so. Just like there's > a use-case for installing from a LiveCD, there's a use case for "rm > - -rf'ing" as much as one can to save space on the Live Media. In my other reply, I pointed out that recovering rm-d things easily, is not a hard problem to solve. But certainly something that doesn't currently work, and would require some new mechanism (either explicit on the user's part, or just that yum will implicitly replace the missing stuff the next time it has access to rpms that the missing stuff can be extracted from). Don't misunderstand me- I have in no way suggested that there was anything wrong with your idea of removing things (spec documentation) that the livecd user might be perfectly willing to live without (until such time as they have access to the network to reinstall it, as mentioned above). > > Does liveinst still support installing from RPMs as well? /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes anaconda in a special way so that it uses the livecd filesystem duplication method, instead of rpms. The (perfectly normal) anaconda on the livecd, if invoked without the liveinst wrapper, is capable of installing from a network or local repository of rpms. Though for obvious reasons, no local repository of rpms has been included on the livecds. -dmc From kanarip at kanarip.com Fri Aug 31 09:55:53 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 11:55:53 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7E248.8010701@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> <46D7DA79.8050506@filteredperception.org> <46D7DCD9.80405@kanarip.com> <46D7E248.8010701@filteredperception.org> Message-ID: <46D7E5A9.7000101@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes > anaconda in a special way so that it uses the livecd filesystem > duplication method, instead of rpms. > > The (perfectly normal) anaconda on the livecd, if invoked without the > liveinst wrapper, is capable of installing from a network or local > repository of rpms. Though for obvious reasons, no local repository of > rpms has been included on the livecds. > It seems to me that if a livecd removes shit to save space, and anaconda can still use a CD with RPM's on it, the problem of not being able to install from a LiveCD is solved; Install from a LiveCD with stripped contents using another CD that holds the RPMs. However this may not be applicable to any of the Live Media the Fedora Project releases, I see a use-case for *anyone else* wanting to produce Live Media. Back to the original topic; what could we possibly remove without all "help" functions b0rking. I'm thinking INSTALL, ChangeLog/CHANGES, README, etc files, as well as maybe a number of non-prominent utility documentation sets (from the end-user POV, zlib-x.x.x documentation really isn't relevant). For some packages even, we could maybe remove the man pages as well (--excludedocs in extreme cases?) - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1+WpKN6f2pNCvwgRAkz/AJ4/M11J5iLZdUrNGKmob2mmQQMeJACfWOsq rI7PW9FHfV6fbZ3m7dwCcWw= =keSi -----END PGP SIGNATURE----- From tla at rasmil.dk Fri Aug 31 10:52:57 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 31 Aug 2007 12:52:57 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D7D4.8060002@kanarip.com> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> Message-ID: <46D7F309.1070208@rasmil.dk> Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Tim Lauridsen wrote: > >> Jeroen van Meeuwen wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's a thought: >>> >>> 1304 random packages will install 724 MB of data in /usr/share/doc >>> >>> I'm sure there is /something/ to gain here. If every package on average >>> installs ~0.5 MB of docs... Would it worth figuring out what docs should >>> be on the LiveCD in the first place? I guess removing everything RPM >>> calls docs is too much, as this will include man-pages as well. >>> >>> Any thoughts? >>> >>> >>> >> I think it is a bad idea, because many people uses the Live CD's to >> install to their systems, and then they end up with a system >> without doc files, with no easy way to get the docs back on the systems. >> >> > > That's not true as anaconda needs the RPMs to install to a system, > right? Last time I checked a LiveCD could not be installed "offline" > because of this. > The Live CD installer just copy the whole system on the Live CD to the local hard drive, and make some changes, it don't use any rpms. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From tla at rasmil.dk Fri Aug 31 11:10:31 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 31 Aug 2007 13:10:31 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D963.1040606@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D963.1040606@filteredperception.org> Message-ID: <46D7F727.8040700@rasmil.dk> Douglas McClendon wrote: > Tim Lauridsen wrote: >> Jeroen van Meeuwen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's a thought: >>> >>> 1304 random packages will install 724 MB of data in /usr/share/doc >>> >>> I'm sure there is /something/ to gain here. If every package on average >>> installs ~0.5 MB of docs... Would it worth figuring out what docs >>> should >>> be on the LiveCD in the first place? I guess removing everything RPM >>> calls docs is too much, as this will include man-pages as well. >>> >>> Any thoughts? >>> >>> >> I think it is a bad idea, because many people uses the Live CD's to >> install to their systems, and then they end up with a system >> without doc files, with no easy way to get the docs back on the systems. > > That's really not such a hard thing to fix - the easy way to get > things back after installation. > > It also relates to a feature I proposed a long time ago > > "yum spininstall" > > Which would be an easy way to take a livecd installed system, and > presuming online access to good yum repos, trivially upgrade with one > command to the type of default system that you would have gotten if > you had installed from DVD instead of CD. > > I.e. I was really peeved that the man-pages rpm did not get installed > (amonst many other subtle choices made in the name of space fitting). > But I didn't want to waste time finding out the specific things I > really wanted, when really I just wanted a "normal system" as defined > by the choices made for the defaults selected on the > non-space-constrained DVD spin. > > My theory was that you could take the package selections of the spins, > wrap them in groups, such that with a single yum command, after > installing from livecd, you could get all the packages that would have > been installed from the traditional DVD spin. > > Likewise, if you got an itch to do ASIC design, and you had just > installed the normal fedora desktop livecd spin, then you could do > something like "yum spininstall FedoraElectronicLab". (spininstall is > just a random illustration, it could easily enough be wrapped into the > existing groupinstall command). > > > I don't see how you can read the doc without downloading all the rpms used to make the livecd and reinstall them. The LiveCD installer is one of the power features of Fedora 7, i install all my systems using the LiveCD's and use yum to add extra stuff after the installation. I the doc are removed then all the system is crippled and the feature is no longer very useful and that will be a shame. So if someone creates livecd without docs, they should not be installable. Tim From katzj at redhat.com Fri Aug 31 12:17:09 2007 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 31 Aug 2007 08:17:09 -0400 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D043.6030003@kanarip.com> References: <46D7D043.6030003@kanarip.com> Message-ID: <1188562629.31850.11.camel@localhost.localdomain> On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: > Here's a thought: > > 1304 random packages will install 724 MB of data in /usr/share/doc > > I'm sure there is /something/ to gain here. If every package on average > installs ~0.5 MB of docs... Would it worth figuring out what docs should > be on the LiveCD in the first place? I guess removing everything RPM > calls docs is too much, as this will include man-pages as well. > > Any thoughts? If the live images weren't installable? Sure. Since they are, though, you're trading off a little space in the short-term[1] for hurting every user in the long-term. Because they a) won't have the docs if they want them b) won't be able to use deltarpms[2] c) make the system look hacked by rpm -V not working, ... It's really just not a good idea for the official images. That said, anyone who wants to for their own unofficial live images that they build for whatever reason is more than welcome to have "rm -rf /usr/share/doc/*"[3] in their %post. The _better_ thing to do is to actually look at what's being installed as docs and then figure out some improved packaging policy and see about not shipping some of it. eg, I'm not sure it makes sense to ship the ChangeLogs in general, either for the live CD or a regular system. But I suspect that to be somewhat controversial. Jeremy [1] It was about 10 megs for the end live image the last time I looked. Which in the scheme of things isn't that much [2] Because the packages will no longer be intact, you can't recreate the new package and do a verify. This will really hurt [3] Note that you need to be a little bit more careful as this will remove the default firefox page From kanarip at kanarip.com Fri Aug 31 12:23:21 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 14:23:21 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7F727.8040700@rasmil.dk> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D963.1040606@filteredperception.org> <46D7F727.8040700@rasmil.dk> Message-ID: <46D80839.9070309@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Lauridsen wrote: > I don't see how you can read the doc without downloading all the rpms > used to make the livecd and reinstall them. > The LiveCD installer is one of the power features of Fedora 7, i install > all my systems using the LiveCD's and use yum to add extra stuff after > the installation. You could check Revisor and Cobbler as an alternative provisioning system. I the doc are removed then all the system is crippled > and the feature is no longer very useful and that will be a shame. > So if someone creates livecd without docs, they should not be installable. > Whether they should be installable is up to the distributor. This distributor isn't necessarily the Fedora Project, you know. Whether the distributor wants 1) the docs or 2) his cool 100MB multimedia shit, really is up to him. If he chooses to have that result in a 1) non-installable LiveCD or 2) a crippled system when it is installed from that same LiveCD, really is up to him. If he wants the system to be 1) installed and non-crippled from a second medium or 2) crippled-until the next yum update, so be it. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG2Ag4KN6f2pNCvwgRAkUGAJwKqcXYhKmmr8mXf3DUuM0rF0MoJACgmG8j mVYDQCxySvzWqtKCbRL915I= =Z/Lx -----END PGP SIGNATURE----- From tla at rasmil.dk Fri Aug 31 12:19:11 2007 From: tla at rasmil.dk (Tim Lauridsen) Date: Fri, 31 Aug 2007 14:19:11 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <1188562629.31850.11.camel@localhost.localdomain> References: <46D7D043.6030003@kanarip.com> <1188562629.31850.11.camel@localhost.localdomain> Message-ID: <46D8073F.1000602@rasmil.dk> Jeremy Katz wrote: > On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: > >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? >> > > If the live images weren't installable? Sure. Since they are, though, > you're trading off a little space in the short-term[1] for hurting every > user in the long-term. Because they a) won't have the docs if they want > them b) won't be able to use deltarpms[2] c) make the system look hacked > by rpm -V not working, ... > > It's really just not a good idea for the official images. That said, > anyone who wants to for their own unofficial live images that they build > for whatever reason is more than welcome to have "rm > -rf /usr/share/doc/*"[3] in their %post. > > The _better_ thing to do is to actually look at what's being installed > as docs and then figure out some improved packaging policy and see about > not shipping some of it. eg, I'm not sure it makes sense to ship the > ChangeLogs in general, either for the live CD or a regular system. But > I suspect that to be somewhat controversial. > > Jeremy > > [1] It was about 10 megs for the end live image the last time I looked. > Which in the scheme of things isn't that much > [2] Because the packages will no longer be intact, you can't recreate > the new package and do a verify. This will really hurt > [3] Note that you need to be a little bit more careful as this will > remove the default firefox page > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list > + 1000 Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From asdas at redhat.com Fri Aug 31 12:31:12 2007 From: asdas at redhat.com (ashok shankar das) Date: Fri, 31 Aug 2007 18:01:12 +0530 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D5B5.60500@rasmil.dk> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> Message-ID: <46D80A10.1040608@redhat.com> Tim Lauridsen wrote: > Jeroen van Meeuwen wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? >> >> > > I think it is a bad idea, because many people uses the Live CD's to > install to their systems, and then they end up with a system In my view LiveCD is meant for "on the move OS" It should not be installed to a desktop system. Well there are many ways to put the content of liveCD int ot a desktop system. If a desktop system is needed then a fullblown Fedora should be installed. > without doc files, with no easy way to get the docs back on the systems. > > Tim > > -- > Fedora-livecd-list mailing list > Fedora-livecd-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-livecd-list -- Thanks Ashok Shankar Das RedHat, Pune +91-9373695832 From kanarip at kanarip.com Fri Aug 31 12:39:48 2007 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 31 Aug 2007 14:39:48 +0200 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <1188562629.31850.11.camel@localhost.localdomain> References: <46D7D043.6030003@kanarip.com> <1188562629.31850.11.camel@localhost.localdomain> Message-ID: <46D80C14.7020304@kanarip.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Katz wrote: > On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? > > If the live images weren't installable? Sure. Since they are, though, > you're trading off a little space in the short-term[1] for hurting every > user in the long-term. Because they a) won't have the docs if they want > them b) won't be able to use deltarpms[2] c) make the system look hacked > by rpm -V not working, ... > Ohw, but my thoughts do not necessarily apply only to what the Fedora Project wants/needs. I'm with you that this should not be applied to LiveCDs the Fedora Project distributes and have a default to copy themselves block-by-block. For other LiveCDs however, distributed along with some medium carrying RPMs or using a netinstall tree or simply not being installable removing any irrelevant files is a space-saver, don't you think? > It's really just not a good idea for the official images. That said, > anyone who wants to for their own unofficial live images that they build > for whatever reason is more than welcome to have "rm > -rf /usr/share/doc/*"[3] in their %post. > I was looking for a way to be more considerate with removing files ;-) That's actually what the thread was about in the first place. > The _better_ thing to do is to actually look at what's being installed > as docs and then figure out some improved packaging policy and see about > not shipping some of it. eg, I'm not sure it makes sense to ship the > ChangeLogs in general, either for the live CD or a regular system. But > I suspect that to be somewhat controversial. > You're right this is what I wanted in the first place. If I think of a LiveCD I think of a fully-featured desktop more then a fully-documented command shell because the CD has only 700MB. I'm looking for what can be removed without loosing common help documentation, but getting rid of files that consume space I could maybe use to put an extra feature in. If this disables being rpm -qVa'd, so be it. If it's not installable, so be it. If I need some extra medium carrying the RPMs or need to go online, so be it. A LiveCD IMO is often just a show-case, not an installer nor a system that runs for hours and hours and needs to be rpm - -qV(a)'d from time to time. > Jeremy > > [1] It was about 10 megs for the end live image the last time I looked. > Which in the scheme of things isn't that much Just the ChangeLogs? 10 megs? Wow. - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG2AwUKN6f2pNCvwgRAsqMAJ0Zli9GAn3bIy5b0yDeAH04B/PaWgCgn6oU M7lOC1fqHbB5G69ZnlVlP8M= =uRPJ -----END PGP SIGNATURE----- From dmc.fedora at filteredperception.org Fri Aug 31 12:51:33 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 07:51:33 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <1188562629.31850.11.camel@localhost.localdomain> References: <46D7D043.6030003@kanarip.com> <1188562629.31850.11.camel@localhost.localdomain> Message-ID: <46D80ED5.9040902@filteredperception.org> Jeremy Katz wrote: > On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? > > If the live images weren't installable? Sure. Since they are, though, > you're trading off a little space in the short-term[1] for hurting every > user in the long-term. Because they a) won't have the docs if they want > them b) won't be able to use deltarpms[2] c) make the system look hacked > by rpm -V not working, ... preface: I'm not arguing for doing this sort of thing in F8 or F9 even. But as mentioned, creating a post install tool that with one button/commandline fetches all the missing stuff is trivial. After which deltarpms works. And for (c), rpm -V will work, it will just show missing files. Out of curiosity, can you provide me an example where if I did rpm -V on all the rpms of my system, and all I saw was missing files, that I should be worried about my system being hacked? I just honestly am curious. (I'm guessing that I could come up with an example if I really thought about it, but nothing springs to mind immediately). > > It's really just not a good idea for the official images. That said, > anyone who wants to for their own unofficial live images that they build > for whatever reason is more than welcome to have "rm > -rf /usr/share/doc/*"[3] in their %post. > > The _better_ thing to do is to actually look at what's being installed > as docs and then figure out some improved packaging policy and see about > not shipping some of it. eg, I'm not sure it makes sense to ship the > ChangeLogs in general, either for the live CD or a regular system. But > I suspect that to be somewhat controversial. I think it is only controversial for the precise reason we are debating it. I.e. in any system that isn't constrained to 700MB, you really ought to go ahead and throw the full changelogs in, because the cost/benefit in that situation dictates that choice. Whereas in the livecd case, the cost/benefit dictates the opposite choice. -dmc From mclasen at redhat.com Fri Aug 31 13:31:24 2007 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 31 Aug 2007 09:31:24 -0400 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7D043.6030003@kanarip.com> References: <46D7D043.6030003@kanarip.com> Message-ID: <1188567085.4719.4.camel@localhost.localdomain> On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Here's a thought: > > 1304 random packages will install 724 MB of data in /usr/share/doc > > I'm sure there is /something/ to gain here. If every package on average > installs ~0.5 MB of docs... Would it worth figuring out what docs should > be on the LiveCD in the first place? I guess removing everything RPM > calls docs is too much, as this will include man-pages as well. > > Any thoughts? > As long as you are willing to ignore the rpm verification issue that gets raised every time this is mentioned (or go with Douglas' fixup-script approach), dropping language support is certainly going to give you just as much if not more space savings. I recently added %lang tags to most of the big gnome help documents documents in /usr/share/gnome/help. Also, dropping CJK fonts easily saves some 40M. Matthias From dmc.fedora at filteredperception.org Fri Aug 31 14:33:09 2007 From: dmc.fedora at filteredperception.org (Douglas McClendon) Date: Fri, 31 Aug 2007 09:33:09 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <1188567085.4719.4.camel@localhost.localdomain> References: <46D7D043.6030003@kanarip.com> <1188567085.4719.4.camel@localhost.localdomain> Message-ID: <46D826A5.9070908@filteredperception.org> Matthias Clasen wrote: > On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Here's a thought: >> >> 1304 random packages will install 724 MB of data in /usr/share/doc >> >> I'm sure there is /something/ to gain here. If every package on average >> installs ~0.5 MB of docs... Would it worth figuring out what docs should >> be on the LiveCD in the first place? I guess removing everything RPM >> calls docs is too much, as this will include man-pages as well. >> >> Any thoughts? >> > > As long as you are willing to ignore the rpm verification issue that > gets raised every time this is mentioned (or go with Douglas' > fixup-script approach), Also, it occurred to me that the more complete solution to the rpm verification issue would be to have a (signed?) list of files that are expected to be missing. Then with either a wrapper, or a minor mod to rpm, you could have just as complete verification. Then, the solution to the inefficient fixup problem (downloading whole rpms just to get the small missing files), if one were serious about it, you could obviously for every shipped livecd, create a single signed package of just the missing files. dropping language support is certainly going to > give you just as much if not more space savings. > > I recently added %lang tags to most of the big gnome help documents > documents in /usr/share/gnome/help. Also, dropping CJK fonts easily > saves some 40M. Yup, languages and fonts I can't read gets me emacs, thunderbird, and openoffice :) Then of course there is the good ol SELinux... For those multitude of situations when the cost benefit equation suggests forgoing the ~7% performance and ~7% cdrom space hit. (though I truly welcome any verbose response explaining lots of examples of how SELinux protects me when I'm just web browsing from a desktop with no exposed ports/services) -dmc From Mohammed_Khan at Dell.com Fri Aug 31 15:02:44 2007 From: Mohammed_Khan at Dell.com (Mohammed_Khan at Dell.com) Date: Fri, 31 Aug 2007 10:02:44 -0500 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D7E5A9.7000101@kanarip.com> References: <46D7D043.6030003@kanarip.com> <46D7D5B5.60500@rasmil.dk> <46D7D7D4.8060002@kanarip.com> <46D7DA79.8050506@filteredperception.org> <46D7DCD9.80405@kanarip.com><46D7E248.8010701@filteredperception.org> <46D7E5A9.7000101@kanarip.com> Message-ID: Perhaps a switch will enable --excludedocs on rpms being installed into the live-cd and a tweak to yum would enable someone who liveinsts the livecd to a disk to type run some new cmd like "yum updatedocs" or something that gets the docs back? To take this another level, stuff in rpms can be flagged as necessary / extra and there can be an --excludeextras flag during rpm install and a yum updateextras or yum installextras command to go add these back in? Thanks, MoeK -----Original Message----- From: fedora-livecd-list-bounces at redhat.com [mailto:fedora-livecd-list-bounces at redhat.com] On Behalf Of Jeroen van Meeuwen Sent: Friday, August 31, 2007 4:56 AM To: fedora-livecd-list at redhat.com Subject: Re: [Fedora-livecd-list] Trimming the size of LiveCD's -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Douglas McClendon wrote: > /usr/(s)bin/liveinst is a bash wrapper around anaconda, that invokes > anaconda in a special way so that it uses the livecd filesystem > duplication method, instead of rpms. > > The (perfectly normal) anaconda on the livecd, if invoked without the > liveinst wrapper, is capable of installing from a network or local > repository of rpms. Though for obvious reasons, no local repository of > rpms has been included on the livecds. > It seems to me that if a livecd removes shit to save space, and anaconda can still use a CD with RPM's on it, the problem of not being able to install from a LiveCD is solved; Install from a LiveCD with stripped contents using another CD that holds the RPMs. However this may not be applicable to any of the Live Media the Fedora Project releases, I see a use-case for *anyone else* wanting to produce Live Media. Back to the original topic; what could we possibly remove without all "help" functions b0rking. I'm thinking INSTALL, ChangeLog/CHANGES, README, etc files, as well as maybe a number of non-prominent utility documentation sets (from the end-user POV, zlib-x.x.x documentation really isn't relevant). For some packages even, we could maybe remove the man pages as well (--excludedocs in extreme cases?) - -- Kind regards, Jeroen van Meeuwen - -kanarip - -- http://www.kanarip.com/ RHCE, LPIC-2, MCP, CCNA C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG1+WpKN6f2pNCvwgRAkz/AJ4/M11J5iLZdUrNGKmob2mmQQMeJACfWOsq rI7PW9FHfV6fbZ3m7dwCcWw= =keSi -----END PGP SIGNATURE----- -- Fedora-livecd-list mailing list Fedora-livecd-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list From patrice.guay at nanotechnologies.qc.ca Fri Aug 31 15:27:41 2007 From: patrice.guay at nanotechnologies.qc.ca (Patrice Guay) Date: Fri, 31 Aug 2007 11:27:41 -0400 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D826A5.9070908@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <1188567085.4719.4.camel@localhost.localdomain> <46D826A5.9070908@filteredperception.org> Message-ID: <46D8336D.8020605@nanotechnologies.qc.ca> Douglas McClendon a ?crit : > Matthias Clasen wrote: >> On Fri, 2007-08-31 at 10:24 +0200, Jeroen van Meeuwen wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Here's a thought: >>> >>> 1304 random packages will install 724 MB of data in /usr/share/doc >>> >>> I'm sure there is /something/ to gain here. If every package on average >>> installs ~0.5 MB of docs... Would it worth figuring out what docs >>> should >>> be on the LiveCD in the first place? I guess removing everything RPM >>> calls docs is too much, as this will include man-pages as well. >>> >>> Any thoughts? >>> >> >> As long as you are willing to ignore the rpm verification issue that >> gets raised every time this is mentioned (or go with Douglas' >> fixup-script approach), > > Also, it occurred to me that the more complete solution to the rpm > verification issue would be to have a (signed?) list of files that are > expected to be missing. Then with either a wrapper, or a minor mod to > rpm, you could have just as complete verification. > > Then, the solution to the inefficient fixup problem (downloading whole > rpms just to get the small missing files), if one were serious about > it, you could obviously for every shipped livecd, create a single > signed package of just the missing files. > > If this package is shipped as a RPM, conflict may arise with the original RPM about file ownership. >> dropping language support is certainly going to give you just as much >> if not >> more space savings. I recently added %lang tags to most of the big >> gnome help >> documents in /usr/share/gnome/help. Also, dropping CJK fonts easily >> saves some 40M. On my current live CD release, I strip rarely used documentation files (changelog, news, non-englist html files). This saves 7MB on the resulting Live CD. I also remove language files and it saves 95MB of compressed space. -- Patrice From sundaram at fedoraproject.org Fri Aug 31 18:03:28 2007 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 31 Aug 2007 23:33:28 +0530 Subject: [Fedora-livecd-list] Trimming the size of LiveCD's In-Reply-To: <46D826A5.9070908@filteredperception.org> References: <46D7D043.6030003@kanarip.com> <1188567085.4719.4.camel@localhost.localdomain> <46D826A5.9070908@filteredperception.org> Message-ID: <46D857F0.5020608@fedoraproject.org> Douglas McClendon wrote: > > Then of course there is the good ol SELinux... For those multitude of > situations when the cost benefit equation suggests forgoing the ~7% > performance and ~7% cdrom space hit. (though I truly welcome any > verbose response explaining lots of examples of how SELinux protects me > when I'm just web browsing from a desktop with no exposed ports/services) There is no recent benchmarking done on what the performance cost is and it is likely to vary widely depending on how you use it. Fedora 7 has SELinux profiles for browsers too limiting the amount of damage in any exploit. Rahul