Re: Knoppix to Debian - A Roadmap what needs to be done
Am Donnerstag, 15. April 2004 01:19 schrieb Sergio Talens-Oliag:
> El Wed, Apr 14, 2004 at 11:12:31PM +0200, Fabian Franz escribió:
> > Hi,
>
> Hello,
>
> > 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.
>
> Well, I don't think a new section is needed, probably a task or a
> metapackage can solve this, but that's not important right now.
Well no, in what section would you put a package, which is not useful unless
its used on a live-CD?
>
> > 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)
>
> You mean an upstream CVS, don't you?
Yes, but upstream at the moment is the most important souce for knoppix and
its really difficult to sync without. We can prepare the packages upstream
and then get it step by step into debian.
>
> > 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)
>
> I think this is the aproach we all were talking about, I don't know
> why the booting is needed, but the rest is what we were talking about.
The booting is needed to speed up the booting after with a sortlist, rather
tricky but very performant.
>
> > The second solution is what most "Remastering"-scripts / howtos propose,
> > it has the advantage that there is no need to boot into the system.
>
> Yes, but the aproach taken in those howtos is too manual. I belive
> that our system has to be more automatic and totally reproducible.
The only steps that are manual there are the removal / installation of
packages. I can do a remaster in an hour plus mastering.
>
> > 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.
>
> I don't know, but my idea was to use the debian-installer system, and
> the kernels used by it are different than the plain debian kernels, as
> far as I know. Anyone can confirm/deny this? I plan to study how d-i
> works, but I still haven't done it ...
I disagree here. Of course it would be nice to help debian-installer also with
that project, but after all it should be possible to install / copy the
system to hd and it should then work exactly like from CD. And as we all know
having a install-kernel on hd is no good idea.
>
> > Our "boot-floppies" linuxrc / miniroot.gz and the whole
> > knoppix-autoconfig concept is grown up.
>
> Yes, and I know it works, so it is one good starting point.
ok.
>
> Anyway, I think that we should try to reuse as much as possible from
> the current debian pool of packages, because this would benefit debian
> as a whole.
Yes, for sure. Or brings the knoppix-utils to debian.
>
> My point here is that, from my personal point of view, the
> installation system *is* a special kind of *LiveCD*, so the
> technologies used for the general purpose *LiveCD* and the
> *debian-installer* should be as similar as possible.
Yes and no. Debian-Installer is modular as hell ( ;-) ) and needs to work in
very bad circumstances ...
>
> > 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.
>
> Ideally, the same thing has to work with a debian-installer system,
> with the added bonus that it works on all debian supported
> architectures.
Yes. So both kernels must work perfectly from live-CD (as everything that
worked from live-CD should also work from HD).
>
> > 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.
>
> Well, I don't know about discover and discover2, but I agree with you
> on the point about starting from knoppix and migrating later, mainly
> because we know that it works now and I don't know what is the current
> status of the debian-installer hardware autodetection system.
ok.
>
> > 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.
>
> I'm sure that knoppix uses things because it needs to, what I want is
> to share all this knowledge with other debian subsystems, and I'm sure
> that all this problems are also interesting for the debian-installer.
Yes and no. I was at debcamp d-i and found not so much, where I could help.
>
> > 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 ...
>
> Yes, that's another set of tasks that I would like to share between
> the LiveCD system and the CDD's installer (well, most of them),
> because they would remove some of the main problems that make people
> say that debian is difficult to install.
Yes.
>
> > 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.
>
> Well, this is something that I think has to be studied, my main
> complaint here is that knoppix alters the standard init system using
> the same configuration files that an installed system should use
> (correct me if I'm wrong, please).
Yes, it does use /etc/rc*.d, but with the installer we ship the main
rc.d-files for debian and replace the knoppix-specifica again through the
original ones.
>
> I belive that we sould handle the init scripts of the livecd with a
> different set of configuration files, leaving the root filesystem as a
> debian install would do.
I think its a nice idea, to at least have the original-runlevels
in /etc/rc*.d-old/
>
> This would allow us to *copy* the root filesytem into the hard disk
> with little or no modification (well, we can overwrite some of the
> configuration files, mainly the ones that have been autogenerated),
> install a bootloader, and we have a fast installation of the CDD
> identical to the one that can be obtained by installing from packages.
Yes, we do this successfully with knoppix all day ;-).
Well the installer is also somewhat ready at last. (It now does a bit more
instead only copying)
>
> > 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.
>
> Agreed.
ok
>
> > 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.
>
> Well, I don't use KDE, but all the needed tricks should be applied by
> scripts to be reproducible ... is this automatic or the tricks are
> applied manually?
Automatic with deb-packages of course.
>
> > 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 ;-).
>
> Well, I think we should have a livecd-init, so the changes applied on
> knoppix can be integrated into it.
>
> By the way, is this really needed? What are the changes applied to the
> init program?
It is statically linked with dietlibc and has umount-syscall to be able to
eject the CD ... kind of tricky :-)
>
> > 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 work?
>
> I can try this, but to be on the safe side we can start the
> integration including the kernel configuration used to build the
> knoppix kernel and the patches it needs (if any) and prepare a script
> to build this kernel using make-kpkg as one of the first tasks on the
> livecd generation procedure.
There is one small patch needed for commandline longer then 255 chars also
applied to syslinux I think.
>
> > - 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'll try this as soon as I have the time.
ok.
>
> > Tell me what you think.
>
> Well, I think is great to have someone interested in the Debian -
> Knoppix integration with enough knowledge about Knoppix and I'm happy
> to see that this is moving again, lets see what can we do to make it a
> reallity.
Ok, just one last word to me:
What I need is motivation, which mostly comes from feedback and publicity ;-).
Just to be honest ...
cu
Fabian
Reply to: