[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Knoppix to Debian - A Roadmap what needs to be done


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.

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 

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 

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.

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.

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.

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.

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 

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 

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 

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 ...

5. X11 / Xsession

Knoppix currently uses /etc/inittab and /etc/init.d/xsession to start the 
Xserver, which basicly does a startx.

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.

6. General Security management

Knoppix' philosophy is it to have invalid passwords and use the sudo-mechanism 
to gain root-rights.

Also there are no services running.

I think we should keep this policy as far as possible.

6. KDE Tuning

We are using several tricks to get the most out of KDE.
We disable the screen lock for example, have our knoppix-menu and some addons 
on that.

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 ;-).

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 :-).

Ok, what you can do:

- Test the original debian kernel with Knoppix: What does work - what does not 
- 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 ...

See also:


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.



Reply to: