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.
> 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?
> 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 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.
> 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 ...
> 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.
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.
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.
> 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.
> 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.
> 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.
> 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.
> 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).
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.
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.
> 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.
> 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?
> 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?
> 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.
> - 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.
> 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.
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.
Greetings,
Sergio.
--
Sergio Talens-Oliag <sto@debian.org> <http://people.debian.org/~sto/>
Key fingerprint = 29DF 544F 1BD9 548C 8F15 86EF 6770 052B B8C1 FA69
Attachment:
signature.asc
Description: Digital signature