Hi, I just subscribed to the list so sorry I break the threading.
Fabian Franz <[EMAIL PROTECTED]> wrote: > Hi, > > first let me introduce to you. > > My Name is Fabian Franz, I am 20 years old and studying computer > science in the second semester on the university of Karlsruhe. Hi there. long time no read. > I did start to work with Knoppix last year and did make a initial > port to PPC on the last LinuxTag. > > I am still a major contributor to Knoppix and have some sponsored > packages in debian. (netpipes, testdisk (until I had build-problems), > slurm, qtparted) and my own packages for knoppix will follow. > > 1. I propose to have a new section "livecd" for packages that need > to be in debian, so that you can install everything from one > hand. As I am no debian-developer you'll have to make the necessary > negotiations / policy changes that allow that. There will be > packages, that are just necessary on a live-cd. I would like to have a section for that. But not just live-cd. The packages are relevant to R/O /,/usr systems and autoconfig systems (Debian for dummies systems), Debian on a CF card or a USB stick, rescue system. The scope is a bit bigger than just Knoppix CDs but I can't think of a better section name right now. So from me you get: section: yes, name: think about > 2. I think the most important step is to have a official CVS / arch > for knoppix, which will hopefully soon be reality. (LinuxTag team is > working on that) > > It'll make knoppix development more transparent and allow to work on > the packages in the first place. > > Soon after LinuxTag I had almost all packages lintian clean, but I > lost sync again, which would not have happened if I had a CVS at > that time. As you might remember I'm working on debix. We basically have the same goals just that I start of with a plain Debian and adding stuff while you have Knoppix and try to transform it to fit. If you wish I can give you acces to debix.alioth.d.o and we can setup the cvs there. I would love to have the knoppix debs tracked and easily available somewhere. > 3. There are currently 2 build processes for knoppix: > > - Klaus build scripts, which are speed optimized and have the need to boot > into the system, then master from there. > - chroot, make some changes, clean up, master. > > The first scripts have the advantage that they do everything > necessary to have a clean boot-cd. Yes, there are scripts that can > do that and yes they are available from web (a bit outdated (for the > still to be released 3.4), but I'm almost sure Klaus would publish > his new ones in CVS) > > The second solution is what most "Remastering"-scripts / howtos > propose, it has the advantage that there is no need to boot into the > system. The scripts that build debix build it from scratch using cdebootstrap. For (auto)building live-cd images thats the only way I see possible. For manual tweaking it would be real nice if you could just boot the cd/dvd, apt-get update, apt-get upgrade, run knoppix-remaster. Thats what I plan for debix and due to the device-mapper infrastructure its just a matter of space. (snapshot, fsck, mkisofs, burn). > 4. Kernel and Hardware Detection: > > I am not sure that the Knoppix-scripts + hwsetup (based on kudzu without its > flaws (e.g. being too aggressive)) will work with a plain debian kernel. Have you tried the hotplug support from 2.6 yet? Correctly setup there should only be a very few modules that need detection/loading, e.g. loop, ppp, anything without actual hardware behind it. > As far as I have understand the debian-kernel is very modular. Well perhaps > its a bit too modular. I dunno how knoppix would react to having to load the > ide-support first. Discover fails there too. D-I loads them manually on top of what discover finds. > Our "boot-floppies" linuxrc / miniroot.gz and the whole > knoppix-autoconfig concept is grown up. > > Well this has disdavantages, but one of the mail goals is still > reached: > > Knoppix with an almost vanilla kernel runs on most of the hardware > and does not crash. > > And if it does crash we have "cheatcodes" to avoid this. Some are > kernel parameters, but there are mor to disable acpi, > ide-scsi-emulation, scsi, usb, sound, and so on. > > Gnoppix for example in my opinion does a rather bad job (yes I filed > already a bug report) as it disabled the noscsi cheatcode (by > building it into the kernel), thus letting my machine crash. It also > disabled the "expert concept". > > In my opinion it is important to have some concept to disable > hardware-detection features and I found cheatcodes a convenient > way. (Well there is a concept with grub-menus, but that are details) > > I don't know if discover can support all of that yet, so I would > propose to work with the standard knoppix packages for the live-CD > and do a smooth migration. > > One step could be to modularise knoppix-autoconfig, but I have not > yet found the need to do so ... > > You must understand: Most of the things knoppix uses are there for > certain reasons. Of course it needs to be checked if they apply > still, but for example hwsetup is nice, as it shows a progress > meter. I dunno about discover here. > > Hardware detection for Knoppix also means: Setup of X11-config, > Setup of /etc/fstab, automatic DHCP-Requests (that are in > background), include of persistent home / saved configuration ... Most of that stuff can be done without policy violation or by saying "The intention of the deb is to modify etc/fstab so it may violate policy there". Know of any that are problematic? X11-config isn't, which is the one I'm most intrested in for debix. Problem is when you have to replace some essential/required package with a patched one. Updating such a system would be painfull since frontends tend to pull such debs back in. > 5. X11 / Xsession > > Knoppix currently uses /etc/inittab and /etc/init.d/xsession to start the > Xserver, which basicly does a startx. Do we have any mechanism to modify /etc/inittab in debian? Otherwise one has to justify modifying that when "knoppix-x11-config.deb" (or other name) is installed and adds the startx. The /etc/init.d/xsession can be renamed/moved along with the scripts using it and the XF86Config file. It means a Knoppix X11 setup uses scripts/config in a different place but it can be done policy compliant and easily. > The real sessions dependant on desktop is started > in /etc/X11/Xsession.d/45xsession, which imho is a nice solution, as one can > display an image and such give visual feedback very soon. > >... > 7. Modified Init > > That is the most complicated step, knoppix needs to use a modified > init to be able to eject the CD, what many users like and prevents > forgetting to eject and letting it in the drive with nerved > computer-owners and so on ;-). Could this be done with a pivot_root (change into a chroot where /sbin/init is actually eject) and telinit u? I haven't tried it but I was thinking of features that also need init to quit and execute something else. > Ok, so much for the philosophy and technology. > > I think I can as soon as the CVS is up, update my trunk and I'm also > willing to upload it for you before thats the case. (At least the > meta-packages I created are usable) > > Where I could need help, was in writing man pages or some smaller > things, that don't need much technical know how, but work :-). Another thing to think about is having some udebs to build the initial rmadisk from. For debix I tried to use the D-I udebs to setup the initrd but failed on the kernel images (missing lvm support). The udebs are ment for creating a initial ramdisk (as D-I does) and already small and clean. The binaires/libs in the udebs can be smaller than the versions from the debs, using -Os on compile and all that. There should only be one or two things missing thatare special for knoppix and those could go into a knoppix.udeb. > Ok, what you can do: > > - Test the original debian kernel with Knoppix: What does work - > what does not work? > - Debootstrap a testing, install all packages from > developer.linuxtag.net/knoppix/ boot into it and use Klaus' build > scripts. Upload to see where it needs work / tweaking ... I will try to add this as option to debix. Lets see if I can produce bootable images from that without human intervention. > See also: > > http://mailman.linuxtag.org/pipermail/debian-knoppix/2003-July/003389.html > > Yes, before last linuxtag I did knoppify a woody ... > > I don't think its all that much work. The worst step probably is to get it > into debian, but with some support and motivation a CVS it can get > reality ... > > Well I'll set it up on my todo :-). > > Tell me what you think. > > cu > > Fabian Dying to see it. MfG Goswin
