--- Chitlesh GOORAH <chitlesh(a)fedoraproject.org&gt; wrote: ... 1) get a name that draws interest and is intuitive. Unless of course the motivation is to keep users away until the project is sufficiently mature and useful. I vote for system-config-liveiso, or livecdgen, or anything whatsoever would be better than the cutesy 'kadischi'. It sounds like something that real men don't eat. 2) unionfs via initramfs (forget read-only root) 3) x autoconfig 4) run as user, not root (thus build system cannot be corrupted by liveiso generator bugs) 5) boot speed optomization either via the accelerated-knoppix cloop profiler, or the unionfs early boot file seperation method I've outlined in the past. 6) gui (system-config-kickstart seems like an ideal place to start, if you don't want to do the anaconda changes I proposed) 7) selinux, via ext2 image as an option In that order. Oh, and 8) feature flag to remove fedora/rh art/trademarks from target so that output can be redistributed as a new distribution without any special permission from fedora/rh. -jdog (the above outlines my own project. I'll let you all know next week or so when an alpha release is ready ;) Unfortunately tonight I have to do homework for tomorrow morning :( __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--- Jasper O'neal Hartline <jasperhartline(a)adelphia.net&gt; wrote: If thats an option, then yes, I don't see any other benefit from ext2. I think you call it strange because you don't understand what I'm saying, although... to add #9) support multiple distributions, i.e. fedora5, fedora6, centos-4.3, debian, etc... I.e. with modular code for the distribution specific stuff, i.e. installer, initramfs tweaking, well... just about everything. but still, this is on my list, just at the bottom. But to clarify what I meant- which was purely within a fedora-core-5 is the only distribution in the world context- this goes back to this post of mine which no one ever answered- https://www.redhat.com/archives/fedora-livecd-list/2006-March/msg00248.html Maybe you did understand what I meant. If so, then I think the answer is- Is such a feature going to be used by many users of the tool? Would such a feature be needed by a user that wanted to post their ISO for the world to use, without having to ask fedora or redhat for permission first? For example the LWN author, reviewing kadischi, and wanting to post their output without first asking fedora or redhat for permission? I think it makes sense to give the user that power. Though I'll admit, if it's just a matter of the user downloading a post-install script from somewhere else and plugging it in, then it's purely a political issue if fedora wants to be the source of that particular post-install script. Granted. I just envision the tool being used to post dozens if not hundreds of special purpose tools on the net. I mean, there are what 500 linux distributions out there? How many are knoppix derivatives? I want to see even more that are fedora livecd derivatives. I think there is no end to the usefulness of a livecd generating tool. And seeing the post that I linked to above, this redistribution issue remains a very big unanswered question in my book. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On Sun, 2006-04-16 at 23:29 -0500, Jasper O'neal Hartline wrote: Actually, I think this is a good point. The Fedora project still hasn't, in my mind, clearly stated how to legally use its logos and trademarks. The Wiki says to make formal requests to use the logo. I've made two such requests and have not gotten a response back. So the question is not whether or not we want to help people build their own distributions from Kadischi. The question is how can someone legally redistribute "anything" built with Kadischi? If you change the splash screen or rebuild a package from source, is the resulting CD still Fedora? If not, do we legally have to remove references to Fedora? -- Chris Negus

--- Chitlesh GOORAH <chitlesh(a)fedoraproject.org&gt; wrote: I hate to be obtuse here Chitlesh, but seeing as how finally someone (Chris) clearly has _precisely_ the same question as I do, I need to reiterate that your supplied legal link does not answer my question. I think in the archive post I referenced, the situation of #2, is very simple, and I can't seem to get a straight answer from fedora. Can you please specifically answer my question in the above Kadischi Legal Wiki, i.e. Question: If I as fedora/kadischi user, produce a livecd with kadischi (say nothing more than the supplied minimal.ks and a post install script that adds a motd of "jane dogalt is the coolest"), am I legally allowed to post that on my own website for mass distribution under the title "jane_dogalt_is_the_coolest.iso"? I.e. due to the default behavior of kadischi, fedora-logos*.rpm will be installed. Is that a problem? If so would simply removing that rpm in a post install script resolve the distribution problem? I don't think I can specify the question any clearer than that. And I for the life of me don't see an answer to that in the wiki-kadischi-legal you referenced. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--- Jeremy Katz <katzj(a)redhat.com&gt; wrote: Can you enumerate at least a couple of those concerns? I see huge advantages, which have caused several livecd projects to already utilize it. I don't mind kadischi opting not to use unionfs, but I would like to know why. As far as not being in the kernels, it does build just fine as a module outside of the kernel. -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

--- Bill Nottingham <notting(a)redhat.com&gt; wrote: Yeah, I noticed some vaguely similar behaviour on mount failures. Then I reordered some options which seemed like they should be order independent, and things seemed to work just fine. Then I just now read the unionfs docs more closely, and I can see why kadischi will not be using it in the near future. I could probably try to track down this answer on archives of other forums, but if you could save me the hassle- Do rh/fedora's kernel developers foresee a working implementation of unionfs at any point? I.e. Do they acknowlege a desire for an issueless implementation of the same functionality, and do they see it as possible? (obviously fuse based unionfs probably need not apply... or rather, thats a linuxrc/nash that I'm almost afraid to contemplate) How about the other implementation mini_fo? -jdog P.S. - I'll take it upon myself to experiment with how bad unionfs really is in the context of a fedora based livecd. I just can't get over the desire to be able to do a yum install on a livecd. I wonder how messed up things would get doing a unionfs implementation purely with bindmounted files... (that seems likely to be more insane than living with existing unionfs issues) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Le dimanche 16 avril 2006 à 20:35 +0200, Chitlesh GOORAH a écrit : .... As some of you may remember I was working on a live CD specific to VIA Epia M and later boards with a special emphasis on making a PVR/TV/multimedia box. The changes that took place in the transition from FC4 -> FC5 for Kadischi stopped my project in its tracks. So what I would like to see in the roadmap is clear indications of what changes will be made at each FC version change. And if a compatible version for the previous FC version will be maintained. Tony

tony wrote: The changes between Core 4 and Core 5 support in Kadischi are not too many. The largest one being SquashFS, since squashfs-tools are not in FC4 repositories I do not believe, they may be. In any case I wrote a message to the list stating if anyone needs updated Kadischi but for FC4 to send a reply. Changes between Core revisions are maintainable via RPM. Which is where Kadischi is headed, possibly. If you would like, I can build an RPM and keep it on website, it would be an unofficial package and would probably fall under scrutiny since it has the added bootsplash stuff. I never kept building FC4 RPMs since no one on the list responded. Otherwise Kadischi in CVS is a development branch and would stay current with the latest Core. J. Hartline

On Sun, 2006-04-16 at 20:35 +0200, Chitlesh GOORAH wrote: Unfortunately, there are still the very large architectural problems around just reimplementing system components such as initrds, etc that go unsolved. And these are the things that long-term make kadischi very unmaintainable as it's just not possible to try to track every change that happens in that stage of the distro. Also, for better or worse, Darko was new to python. He did an admirable job, but the code just generally needs a fine-tooth comb of going through and actually using parts of python rather than re-implementing them (as it turns out, all of lib/*py isn't needed). I think the big thing that's needed is moving towards using the stock Fedora infrastructures for the various parts of creating the live CD. I started working on this while I was waiting on FC5 trees to test but then unfortunately had vacation, LinuxWorld and a week of meetings -- so it's taken far longer than I wanted to actually get to where this is "reasonable". Also, tying into this will be working with Bill and Mark on what they're doing to get stateless off the ground again -- this will also hopefully let us continue in the "using stock Fedora infrastructure" path. Going this way will let us get to where we can (I hope) actually have an Official Fedora LiveCD to give out in conjunction with the release of Fedora Core 6. And, it'll be a reasonable toolset to let other people create their own On this line of thinking, I've made progress on the following 1) Modifying kadischi.py to be a little bit more python-y. More importantly, it's using all python built-ins rather than reimplementations of things. We can also avoid the need for a config file with command-line options for pretty much everything. 2) Cleaning up invocation of the post scripts and how things are handled here. 3) Implementing a mkrootdev command to be included in a secondary initramfs overriding the stock nash mkrootdev. With this, we can use a completely stock initramfs creation. 4) Generate the isolinux config as anaconda's boot loader generation step. With this, I am now generating a live cd that can boot with init=/bin/bash. Getting beyond that is going to want to piggy-back on what Bill has been doing for readonly root in stateless. But rather than wait for everything to be perfect, I've gone ahead and put up what I currently have at http://people.redhat.com/~katzj/livecd/. Included there are the following: a) livecd.tar.gz -- this is the main pieces. See the README within for the basic usage, essentially the same as with kadischi, but a few tweaks so you can actually run from a working directory. The unfortunate side is that this mostly based on the state of things from a few weeks ago given the other stuff that I've been occupied with. b) booty-0.71-1.livecd.i386.rpm (and src.rpm). This is an updated booty that will work for creating the isolinux.cfg. Note that it's currently hacked to just work for live CDs c) anaconda-11.0.5-1.livecd.i386.rpm (and src.rpm) . This is a patched version of the FC5 anaconda that will properly do the boot loader config and ensure firewall, etc stuff is set up within the live CD image config isn't needed, probably by actually having anaconda know that it's doing a rootpath install for a livecd. Also, getting integrated with the new stateless stuff and ensuring that everything is on the same page would be a good step forward. Then, questions like what goes on an official live CD and how do we get from something which exists to something which is good can start being attacked. And due to having our infrastructure aligned, we'll start just picking up improvements as things occur in the development tree. So, am I insane? Most of this is stuff that I've said before, but I've tried to sit down and put my money where my mouth is so to speak and actually gotten some coding done. Jeremy

Just an Idea/proposition: Have anyone looked at gfxboot ? What do you think about it ? -- http://clunixchit.blogspot.com

--- Jeremy Katz <katzj(a)redhat.com&gt; wrote: It does look like gfxboot is in about the same state as unionfs. I.e. very cool for proof of concept livecds, but with far less than rock-solid tried and true reputation. I.e. definately something to play with, if you are so inclined to suffer the headaches, but probably not yet ready for primetime. The one thing that it does seem to offer over isolinux that I think is valuable is a gui-ish boot entry selection mechanism. Though it also offers animation and sound support which is more than I find necessary, and probably why it's so complex. On that note however, it would seem the 3rd alternative would be the beloved grub. Apparently grub supports cd's, i.e. http://snapplatform.org/snappix/home/?q=node/4 Does anybody have any experience or knowlege of issues with using grub instead of isolinux (i.e. it's definately less tried and true in the cd-boot scenario, but are there any explicity well known gotchas?) -jdog __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

On Thu, 2006-04-20 at 11:24 -0700, Jane Dogalt wrote: I've used grub via morphix. It has worked fine without any hitch in that scenario. I tried to make my own bootable iso's by following grub's info page instructions and ended up with things that didn't work as expected (non-bootable CDs, CDs that would boot to the grub commandline.) Summary: Seems to work but I'm not the one to ask how to script a script that installs it :-). -Toshio

On Wed, 2006-04-19 at 17:27 -0500, Jasper O'neal Hartline wrote: Cool, thanks. And yeah, that's exactly why. If someone wants to beat me to changing it over, I'm not going to complain. On that note, I'm wondering if it makes sense to import this into a repository? Obviously, kadischi is already in CVS and I could import on a branch or a different repo. At the same time, given the fact that there's a lot of interest in experimenting and trying different approaches around live CD stuff, I wonder if it makes sense to actually use the mercurial setup on cvs.fedora so that people can have their own trees for trying stuff. Yeah, forgot that I currently was doing the installs with vnc just because I was doing some testing from home while running everything on my test box at the office :) Jeremy

On Thu, 2006-04-20 at 10:50 -0500, Jasper O'neal Hartline wrote: Even with contributors contributing in a more "traditional" fashion, distributed SCMs have their advantages in allowing people to better keep track of what they're doing themselves Jeremy

Jeremy Katz wrote: To take Murcurial for a quick spin, I've quickly modified what is present to use SquashFS. This is slightly different than what is in Kadischi CVS, as we pass the ctree dir to post_scripts and we use ctree in 06sysconfig.py, rather than remove the tweak_livecd from it. Attached is livecd-squashfs.hg. J. Hartline

On Mon, 2006-04-24 at 11:25 -0400, Jeremy Katz wrote: ... and in writing my footnote, I lost the last part -- that overall, this looks pretty good Jeremy

On Mon, 2006-04-24 at 11:11 -0500, Jasper O'neal Hartline wrote: Yep, probably the sanest thing to do. Doing it internal to our mkrootdev will be the easiest thing. That doesn't handle controller modules, though. I'd just go for the simple at first of having ahci, ata_piix, aic7xxx and mptscsih. That's probably the sort of thing that overriding with a command-line option makes sense for Jeremy