El Thu, Apr 15, 2004 at 03:02:37AM +0200, Fabian Franz escribió:
> Am Donnerstag, 15. April 2004 01:19 schrieb Sergio Talens-Oliag:
> > El Wed, Apr 14, 2004 at 11:12:31PM +0200, Fabian Franz escribió:
> > > 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?
Oh, I see, I thought that the packages you were talking about were the
ones used to build the LiveCD, but I suppose that you mean that they
are not installable on a standard system.
If I am right my answer to your question is in no one; I don't think
is a good idea to include packages in the Distribution that are only
useful when installed on the LiveCD chroot.
As I've said before, I belive that our chroot has to be as similar as
possible to the one produced installing the CDD, all the modifications
done by the LiveCD tools should be done by scripts that can be
installed on a standard Debian system, not installing special packages
on the chroot.
Can you give us a list of this packages and a brief description of
each? I would like to know what they are used for and see if is easy
to distribute those packages in a way that permits us to install them
in a standard system (i.e., installing all binaries and config files
under /usr/lib/knoppix an /etc/knoppix) and use them as spected on the
LiveCD ...
> > > 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.
I don't understand, I'll have to look at the scripts.
> > > 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.
Well, maybe the problem is that I've only read one of this remastering
HOWTOS, but I belived that a lot of people customizes knoppix copying
and moving configuration and data files manually.
> > > 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.
Well, my idea about installing the LiveCD contents in the HD is that
it should work as a real installation does, not as the CD version,
mainly because the CD uses a lot of tricks that are not needed on a
real installation.
And talking about the kernel, I'va always used the boot floppies
kernel to boot after an installation and once it works I've installed
or compiled another one optimized for my system, why can't we do that?
> > 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, a generic LiveCD generator has the same requeriments ;)
> > > 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.
Well, I belive that d-i has a lot of problems not present on the LiveCD
case, but almost all the LiveCD problems are or can be present in d-i.
> > > 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.
Hmmm, I know this is just a question of taste, but doing this means that
your root filesystem is different from the result of a real installation,
my idea is to put all the LiveCD hacks out of the standard places,
because this allows us to simply drop the root image and reboot ...
in fact, the autogenerated files don't have to be copied, the system
can be designed in a way that regenerates them on the first boot from
CD, probably with the only exception of the bootloader installation and
maybe the /etc/fstab of the newly installed system.
> > 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/
I would prefer something like using /etc/knoppix/rc*.d/ for the
knoppix-init ... ;)
> > 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)
Can you elaborate more on this? A short description of the additional
tasks and a poiter to the current code would be great.
> > > 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.
Probably this is one of the uses of the knoppix only packages.
> > > 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 :-)
And can be modified to use /etc/knoppix/inittab instead of
/etc/inittab leaving standard files untouched ... ;)
> > > 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.
Can't this be applied on the syslinux debian package?
> > > 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 ...
Well let me tell you that you will have my feedback and cooperation. I
only wish I had more time to work on this project.
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