Re: Knoppix to Debian - A Roadmap what needs to be done
Hi,
I just subscribed to the list so sorry I break the threading.
Fabian Franz <FabianFranz@gmx.de> 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
Reply to: