Re: Knoppix to Debian - A Roadmap what needs to be done
Sergio Talens-Oliag <sto@debian.org> writes:
> El Thu, Apr 15, 2004 at 02:38:00PM +0200, Goswin von Brederlow escribió:
>> > 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.
>
> From your words, I think that debix is more or less what I was thinking about:
>
> http://lists.debian.org/debian-custom/2004/debian-custom-200404/msg00036.html
>
> Am I right?
Debix is getting there. Its more than one thing:
1. A tool to make a live-cd out of any linux system.
2. Premade sets of package lists and configuration and patches to
automatically create nice live-cds like knoppix.
In cvs (on alioth) is a version of Debix that can be called "proof of
concept" of part 1. I'm working of changing the build scripts to be
modular and flexible so part 2 can be started.
>> > 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.
>
> Well, as I see it there's no need to use debs that modify other
> packages' config files, they should only modify them at runtime when
> running from the LiveCD.
Which would be a policy violation since /etc is read-only per policy
and a package would modify some other packages files.
But most of the time one can setup things so they use alternative
config files, like from /var/run/knoppix-etc/... or some other policy
conform writable place. Maybe thats not the nicest thing and maybe one
can overlook writes to /etc but strictly speaking moving them all to
var would be needed.
>> 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.
>
> Is this really needed? I mean, we can install special versions of the
> packages that don't conflict with the original ones and use them only
> when running from CD.
I just know that isn't done yet. Like the patched sysvinit or
mount-aes. They could just as easily divert the binaries with patched
versions and leave the rest alone. Thats something to be thought about
case by case.
E.g. with mount-aes the debian package should be enhanced instead.
>> > 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.
>
> With a special LiveCD's init we can use a different 'inittab' and a
> different runlevel schema that is only used when booting from the
> LiveCD. I see no policy problems with this schema.
>
>> > 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.
>
> I'll be happy to test this.
>
> Greetings,
>
> Sergio.
One thing I have seen in various mails in this thread (here too) I
completly disagree with:
Things like 'that is only used when booting from the LiveCD'.
One main design trick of Debix is that all the live-cd specials are
contained _just_ in the initial ramdisk (+ some files on the cd for
space reasons). The ramdisk finds (when I get it finished) the CD (usb
stick, CF card, harddisk install, whatever medium) and sets that up as
a writeable snapshot (COW to ram) with device-mapper.
After that there is absolutley no difference between that snapshot
device and any other _writable_ block device and I don't intend to
artificially introduce any. You can HD install the image and it would
still be volatile just like on CD. If changes should persist the
initrd has to be changed (or better just a bootparameter). This could
even be switched on/off at runtime at any moment. The HD installed
live-cd should keep behaving just like the live-cd with all its
autoconfig magic until the user chooses to change it.
Preferably the live-cd autoconfig magic should keep working even with
apt-get upgrade or dist-upgrade. In fact that should update the
live-cd packages to newest versions and not revert the system to a
normal debian.
If that can be archived (especially the last part) I would say Knoppix
is integrated into Debian.
MfG
Goswin
PS: Changing between volatile and persistent is realy great to test
sid upgrades. Turn on volatile, upgrade, if it fails reboot. If it
works go back to persistent.
Reply to: