Sep 192013

Knoppix logoSince 2 or 3 years I have been building a Knoppix-based Linux-on-CD distribution for teaching (exercises and exams) at our University. A colleague of mine has written the proper server/client tools for source code submission and evaluation while I have adapted and hardened the system for our needs, based on tons of modifications on the CD and also on the server side, from where a lot of local behavior is controlled by server-side scripts which can dis-/enable the network or USB ports on clients, but which can also shut clients down or verify the media to effectively prevent CD forgery (Its pretty cool to see them students try, so far they never came even remotely close to breaking it).

Now I am supposed to ensure that the system can use sound. It seems some Java-based exercises may contain sound creation and playback in the future. To make sure the system can support new sound chips (which it currently does not) and potentially also new GPUs I tried to hack a new Linux kernel into the system to replace the good old, which had the ALSA sound system built in, so I couldn’t update it as a kernel module. Also, updating the whole 6.2.1 thing to Knoppix 7 is just not an option, as it would be far too much work. The kernel update it had to be.

And so the adventure began…

Before you continue reading please be aware that you should know how to actually remaster Knoppix. A guide can be found [here] for instance. To modify your disassembled Knoppix within another running Linux operating system (like Debian, CentOS, whatever) and then re-create the compressed image and final ISO image, this knowledge is essential.

First, I set up my virtual machine to boot from my Knoppix ISO as usual, but I also gave it a 5GB virtual hard drive to download stuff to and compile source code on, as Knoppix is limited to a rather small RAM disk. First I tried the latest stable kernel, Linux 3.11.1, but let me just say – don’t! Knoppix uses a modified kernel plus special modules, and some of the stuff will not play along if you’re going for 3.11.1, most importantly the cloop.ko kernel driver which is needed to mount the compressed Knoppix image on the CD/DVD. Even the latest Knoppix 7.2.0 currently cannot use Linux 3.11.1. So I went for 3.4.62 instead, a rather new kernel with long time support.

You can grab the vanilla 3.4.62 kernel source code [from here] at You could also try some 3.9 flavor, but I won’t vouch for that working.

Downloading aufs and violating the vanilla kernel:

One of the things Knoppix absolutely needs is [aufs], a fork of the older [UnionFS]. aufs is a multi-layered file system that can combine multiple read-only and writable file systems into one file system that organizes reads and writes appropriately where possible. According to Klaus Knopper it’s a must-have for Knoppix’ CD boot. Torvalds’ kernel development team however has rejected aufs together with other union style systems, all but union-mount, which has not seen much development either.

Because of this, no newer Linux 3.x kernel works with aufs by default. So before recompiling the kernel, it needs to be patched first.

Please boot up your reference Knoppix system from DVD (better than CD, more tools, essential kernel headers etc.) and mount some usable hard drive (like /dev/sda) so we can start working.

Lets assume you have downloaded the kernel into /mnt/sda1/, which shall be our source archive for now. On that drive, we will create and compile everything we need. But first, please go to that directory on your shell, and let’s get aufs first, as we need the patch files to make the kernel aufs-compatible before building it. Please become root by typing su and then go ahead:

cd /mnt/sda1/
git clone git:// aufs3.4
cd ./aufs3.4/
git checkout origin/aufs3.4

Note the aufs version, which is 3.4! This needs to match the version number of the Linux kernel, which is also 3.4(.62). You can not pick a kernel that there is no corresponding aufs version for, it won’t work! Now there will be a series of *.patch files in that directory. Unpack your kernel source, copy the patches in and apply them, also copy over some necessary files from the aufs source tree:

cd ..
tar -xJvf ./linux-3.4.62.tar.xz
cd ./linux-3.4.62/
cp ../aufs3.4/*.patch .
patch -p1 <./aufs3-kbuild.patch
patch -p1 <./aufs3-base.patch
patch -p1 <./aufs3-proc_map.patch
patch -p1 <./aufs3-standalone.patch
cp -r ../aufs3.4/Documentation .
cp -r ../aufs3.4/fs .
cp ../aufs3.4/include/linux/aufs_type.h ./include/linux/

Now prepare and build the kernel:

Now that the kernel is patched, we can build it. But first you should use the existing kernel configuration of your Knoppix distribution as a base for the new kernels configuration. This makes configuring the kernel a lot less painful and we’re not as prone to building ourselves a non-bootable system that way. So copy over the existing configuration. In case of my Knoppix 6.2.1 this comes from the shipped kernel (you need to unpack the Linux headers on the Knoppix DVD first):

cd /usr/src/
tar -xzvf linux-headers-
cd /mnt/sda1/linux-3.4.62/
cp /usr/src/linux-headers- ./.config

Now please open ./.config and search for “General setup”. The first configuration line under General setup should always read CONFIG_EXPERIMENTAL=y. If that line is missing, please add it and save the file, as you’d otherwise not get a lot of potentially important kernel drivers compiled, like certain network card drivers for instance.

Now let’s go and do this, make all will take a while though, so time for some coffee in the meantime:

make menuconfig (Do this if you want to check the configuration first.)
make all
make modules_install
make install

Now your new kernel is built and installed! Next step:

Building aufs:

Since we have already unpacked aufs, let’s just go back into its source tree in /mnt/sda1/aufs3.4 and build it. We will also need to show it which kernel to link against, otherwise it’ll try to link against the running kernel or whichever you’re using, and we can’t have that. It needs to be integrated into the patched kernel we’ve just built. For that we need to modify some files a little bit:

  • Makefile -> edit the file and set the KDIR variable to your kernel source tree root, in my case it’s KDIR = /mnt/sda1/linux-3.4.62.
  • -> add the following two options, this will also ensure aufs is built as a module, which is what we’ll want:
    • CONFIG_AUFS_FS = m

Save the files after editing, and build the aufs source code:


When that’s done, it’ll leave you with a kernel module called aufs.ko. Even if there are errors and the build does abort (maybe test errors related to aufs_type.h), it’s ok as long as you’ve got aufs.ko! That’s the file we need, so copy it to some place where you can later use it for insertion, like maybe to your host operating system, where your Knoppix is awaiting remastering.

Also, absolutely do copy it to the following location, this will be essential for building the module dependency file at the very end, please create the aufs subdirectory if necessary:

  • /lib/modules/3.4.62/kernel/fs/aufs/

Now we might also want the aufs userspace components, so the next step is aufs-util:

Building aufs-util:

First, we need to get aufs-util. This works in a similar fashion as it did with aufs itself:

cd /mnt/sda1/
git clone git:// aufs-util
cd ./aufs-util/
git checkout origin/aufs3.2

As you can see, the version is now 3.2, not 3.4. Reason is that there simply is no 3.4, only 3.2 and 3.9. The rule is, that if there is no aufs-util exactly matching your aufs+kernel version, use the next lower one, it will work. But do stick to that rule, as other versions will not work! Since aufs-util lives in user space, not kernel space it doesn’t have to match 100%. Ok, let’s start, and double-check the CPPFLAGS, those have to be correct or linking will go awry:

cd aufs-util
export CPPFLAGS="-I/mnt/sda1/linux-3.4.62/usr/include -I/mnt/sda1/aufs3.4/usr/include"
make install

That way our aufs-util package will be linked against the correct kernel headers and more importantly the correct aufs3.4 headers. Now we need to get the following files and copy them off the system, I would suggest just tar’ing them all:

  • /sbin/mount.aufs
  • /sbin/umount.aufs
  • /sbin/auplink
  • /usr/bin/auchk
  • /usr/bin/aubrsync
  • /etc/default/aufs
  • /usr/lib/libau.*

So just run this:

cd /mnt/sda1/
tar -cjvf ./aufs-util.tar.bz2 /sbin/mount.aufs /sbin/umount.aufs \
/sbin/auplink /usr/bin/auchk /usr/bin/aubrsync /etc/default/aufs \

Now just copy aufs-util.tar.bz2 off-system and that’s done! Now that’s one critical kernel module we will absolutely need, but there is a second one, the one that enables the kernel on the CD to decompress and mount the compressed Knoppix image, that allows the system to store a 2GB Linux distribution on a 700MB CD or a 9GB one on a 4.5GB DVD. It’s called cloop.

Building cloop:

First, you need to get the latest cloop source code of course, you can just grab that from [here]. As I am writing this, the latest version is 2.639, so we’ll use this version, if you get a newer one just adjust accordingly. Store the archive file in /mnt/sda1/ again and unpack it. After that we run the compilation, telling make what kernel headers to link against in the process:

tar -xzvf ./cloop_2.639-2.tar.gz
cd ./cloop-2.639/
make KERNEL_DIR=/mnt/sda1/linux-3.4.62 module

That’s going to give you the precious cloop.ko, one of the most essential parts of Knoppix’ early boot sequence. Copy that one off the system again, and also copy it to the following location, create the misc subdirectory if necessary:

  • /lib/modules/3.4.62/kernel/misc/

So far so good! Now a final step so our modules will be recognized by the final system, run this:

depmod -a 3.4.62

This will create the correct module dependency files in /lib/modules/3.4.62/ so that there won’t be any hiccups in the later boot sequence. It shouldn’t be critical for the Knoppix boot sequence style, as you will see later with the modules being loaded from yet another location early on, but it’s just much cleaner that way, so it’s better if you get used to always doing depmod -a <kernel version> whenever building & installing kernel modules.

Copying off the kernel and its modules:

We still need the kernel and our modules copied off like aufs.ko, aufs-util and cloop.ko before. Now that the modules folder structure is complete, we can do just that. Again, I’d suggest using tar here:

cd /boot/
tar -cjvf /mnt/sda1/kernel-binary-3.4.62.tar.bz2 ./*3.4.62*
cd /lib/modules/
tar -cjvf /mnt/sda1/kernel-modules-3.4.62.tar.bz2 ./*3.4.62*

Copy the resulting archives in /mnt/sda1/ off-system again.

Now we’re done doing stuff from within a running Knoppix installation (or a chroot environment for that matter if you’re walking that route instead of using a virtual machine). So shut down that VM or leave that chroot jail, and let’s continue our work on the host operating system, where you’ll have your Knoppix master and source (=unpacked compressed image) directories. You’ll know what I’m talking about, if you’ve read that Knoppix remastering HowTo that I linked to on the very top of this article. If you don’t know what I’m talking about, better read that right now, otherwise you’ll be lost from here on.

The beginning of the end:

First, let’s assume you compiled cloop on the host system too. That would’ve given you not just cloop.ko, but also the tool create_compressed_fs. If not done yet, copy that binary to /usr/local/bin/ on your host or wherever you’re comfortable with system-wide binaries lying around.

On top of that let’s assume your uncompressed parts of the Knoppix ISO are in /home/user/master/ and your decompressed Knoppix image contents are in /home/user/source/.

First, let’s fix the early boot sequence parts, which are all in the master directory. Unpack the kernel binary that you’ve copied off Knoppix before (kernel-binary-3.4.62.tar.bz2). All you will need here is the file vmlinuz-3.4.62, the actual kernel image. Copy it to the following location, overwriting the already existing file called linux:

  • /home/user/master/boot/isolinux/linux

Now you’ve also copied off aufs.ko and cloop.ko, right? Copy the modules to the following location, again overwriting the existing ones, which were maybe for

  • /home/user/master/KNOPPIX/modules/

Now the way cloop.ko is being loaded has changed a bit over time. The newer versions require a parameter being passed to the module when loading it. That parameter is telling cloop where to look for the compressed image that it’s supposed to decompress. The cloop in Knoppix 6.2.1 with kernel didn’t do it like that, so the call of the init script in the initramdisk is wrong now. The compressed image will be called /home/user/master/KNOPPIX/KNOPPIX in our case, as it is the default, and we’ll add the proper option by manually messing around with the initramdisk (Hey, it was a first for me too):

Modifying and recreating the initramdisk:

If you’re used to compiling Linux kernels yourself, you might’ve wondered why we haven’t built an initramdisk with yaird or mkinitramfs after compiling the kernel. That’s because Knoppix uses a very special initramdisk that typically does not require modifications when switching kernels. Typically. However, updating the kernel+modules is not such a “typical” thing after all, especially when going as far as from to 3.4.62, so yeah. The Knoppix initramdisk is in /home/user/master/boot/isolinux/minirt.gz and contains purely user space applications in Knoppix’ case. We are going to modify the init script inside, which is the mother of all user space processes. But first we need to unpack minirt.gz, and you might want to backup that file first:

cd /home/user/master/boot/isolinux/
gzip -d ./minirt.gz
mkdir ./workdir && cp ./minirt ./workdir/ && cd ./workdir/
cpio -iv <./minirt && rm -f ./minirt

Now it’s unpacked and you’re sitting deep in the belly of the earliest parts of Linux’ boot sequence, all without fancy initrd creation tools and shit. You’ll also see the init script right there. Edit it and look for cloop or insmod lines. You’ll need to find the one where insmod is being called on cloop.ko! In my Knoppix version 6.2.1 that’s on line #622. There will be a preload=32 or similar option already set to improve cloops performance. Now just before that option, insert this one:

  • file=/mnt-system/KNOPPIX/KNOPPIX

Just so you’ll better see what I mean, here is the vicinity of the line I’m talking about, already patched, so this is how it should look like:

  local k dev dir count=0 RC=0
  [ -b /dev/cloop ] || mknod m 644 /dev/cloop b 240 0
  insmod /mnt-system/KNOPPIX/modules/cloop.ko file=/mnt-system/KNOPPIX/KNOPPIX preload=32 || return 2
  [ -d /sys/module/aufs ]  || insmod /mnt-system/KNOPPIX/modules/aufs.ko || return 3
  for k in /mnt-system/"$knoppix_dir"/[Kk][Nn][Oo][Pp][Pp][Ii][Xx] \
           /mnt-system/"$knoppix_dir"/[Kk][Nn][Oo][Pp][Pp][Ii][Xx][0-9]; do

Don’t mind the /mnt-system/, I guess that’s already part of aufs magic right there. With that, the newer cloop will also find the image correctly! Now that we’ve fixed that, we need to rebuild the initramdisk so the kernel can unpack and use it. Run the following while still sitting in the same directory where init also sits:

find . | cpio --create --format='newc' >../minirt && gzip -9 ../minirt
cd ..
rm -Rf ./workdir

Done with master, now let’s implant the rest we copied off earlier into the actual Knoppix system!

Finalizing the actual Knoppix system:

You remember how you packed those aufs-util tools into a single archive called aufs-util.tar.bz2? Time to implant them into your Knoppix system! Copy the archive to /home/user/source/KNOPPIX/ and then unpack:

cd /home/user/source/KNOPPIX/
tar -xjvf ./aufs-util.tar.bz2

Now your kernel! Take your kernel-binary-3.4.62.tar.bz2 again and put it in /home/user/source/KNOPPIX/boot/! Then:

cd /home/user/source/KNOPPIX/boot/
tar -xjvf ./kernel-binary-3.4.62.tar.bz2

You may delete your old kernel files as well as the kernel-binary archive in that directory, we’ll only need the other *3.4.62* files (vmlinuz-3.4.62, and config-3.4.62), and that will save some space on the disc. Still not done, we also need to unpack the modules we copied off, that was kernel-modules-3.4.62.tar.bz2, put that in /home/user/source/KNOPPIX/lib/modules/ and run:

cd /home/user/source/KNOPPIX/lib/modules/
tar -xjvf ./kernel-modules-3.4.62.tar.bz2

Again, you may delete the old modules tree, maye a directory called or similar. Deleting the unused ones will save a lot of space, so you should probably do that and only keep the directory 3.4.62. You can also delete the archive you just unpacked from again of course.

Now, very important and easy to miss, there is a link that needs removal and fixing:

cd /home/user/source/KNOPPIX/
rm -f ./vmlinuz
ln -s /boot/vmlinuz-3.4.62 ./vmlinuz

That link may appear broken at first, but it’s not, it will become valid when the final system boots up.

All done, now we can build the image!

Stitching it all together:

Now you should be able to do this after reading the Knoppix remastering HowTo anyway, but I’ll show you my build commands nonetheless. For this we’ll use genisoimage and the create_compressed_fs binary from the cloop package. This benefits significantly from having multiple processors or processor cores and threads. For this example, I will assume 8 CPU cores. First, we’ll need to build the compressed image, just overwrite the existing one, if there is one:

cd /home/user/master/KNOPPIX/
genisoimage -R -U -V " filesystem" -publisher "KNOPPIX" \
-no-bak -hide-rr-moved -quiet /home/user/source/KNOPPIX \
| create_compressed_fs -B 65536 -m -t 8 -L 9 - ./KNOPPIX

The -t 8 option defines how many threads the compressor will spawn. So make this number the same as your logical processor count. If you do not know how many freaking CPUs you have, this’ll tell you on any x86 platform:

cat /proc/cpuinfo | grep -i processor | wc -l

Now, let’s build the real ISO file:

cd /home/user/master/
genisoimage -l -r -J -V "KNOPPIX" -publisher "KNOPPIX" \
-b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
-c boot/isolinux/ -o /home/user/knoppix.iso \

Now you can take that knoppix.iso file from /home/user/ and burn it to CD/DVD or just boot from it in a virtual machine to see whether it works or whether everything’s just plain dead now. I won’t give any guarantees here, it’s been a long three days and maybe I forgot a small detail here and there. But I sure hope not, as this article is supposed to serve as my very own documentation. ;)


So far, I haven’t done much stability testing, only a few VM runs and one quick test on a physical machine. Looking quite good. It was really interesting to see how Knoppix’ boot sequence works though, the isolinux bootloader loading the “outside” kernel which needs to be custom patched to work with aufs, loading the two kernel modules aufs and cloop with a rather generic custom-built initramdisk that works for just any kernel version (with a few very minor tweaks sometimes).

Also, learning how to link kernel modules against kernels other than the one currently running was something new for me, as was messing around in the hallowed halls of an initramdisk. So you can say, I learned quite something here. And now, thanks to this documentation right here, I can safely forget everything again and have a few beers on the coming weekend! Yay! :mrgreen:

CC BY-NC-SA 4.0 Hacking a new kernel into Knoppix 6.2.1 by The GAT at is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

  6 Responses to “Hacking a new kernel into Knoppix 6.2.1”

  1. Hi,
    In the past I remastered Knoppix but never tried to build the kernel myself. I am the IT-Admin of of College-like school in Austria. I need a Knoopix-like minimalistic distro ( only with some educational software stuff like geogbra, wxmaxima and so on) . I would be very interested on the architecture you were controlling the clients – and how is your experience with the different platforms (OS X, windows, ..). Is there some public docu?
    I don’t want to invent the wheel again! If I can use your experiences I would appreciate it.

    Would be fine to hear of You

    Angsuesser Johann

    • Hello Johann,

      Ah, a fellow countryman! :) I hope you don’t mind if I stay with English, otherwise it might be confusing for other visitors. Your use case appears to be highly similar to ours.

      I fear I cannot give you all the details, as parts of the solution involve measures to prevent cheating during tests. A large portion of the software is the so-called “evaluation server” and its “submission client” with which the students can submit their solutions to the server, which will compile and test the programs the students are submitting, in certain cases giving the student feedback about the outcome. That part I cannot talk about too much, because I didn’t write the software. Both client and server are written in Java by a colleague of mine (who is an academic, which I am not).

      First of all, while the evaluation client program runs everywhere (Windows, OSX, Linux, BSD UNIX, Solaris), our system is heavily based on pure Linux. So in essence, when we use it for some “real stuff” (meaning exams, but sometimes also regular exercises), all clients in a given room have to boot from Knoppix. We did this because it represents a trusted system, eliminating all weaknesses of any host operating systems that may be installed and potentially compromised already. This was requested especially because not all machines are under my chairs direct control, and trust is a thing you don’t easily come forward with when doing exams on computers you don’t know well enough. ;)

      The adaptation of Knoppix itself and hardening it against attacks / counterfeit attempts by students however was my job. So let’s tell you what I can off the top of my head.

      I altered the monolithic Knoppix startup script, which is run as root. The startup script will pull in code from a server via SSH and run that code. The code basically does some verifications on the CD based on checksumming arbitrary parts of the CDs surface (the raw block device) as well as some files. The checksums are sent back to the server, where it can be decided whether the students’ CD is legit.

      If it is broken or counterfeit, the lecturer will be notified silently of that including the IP address and location of the machine as well as the students ID who logged on to its evaluation client. In a real exam situation, the CD would be confiscated immediately for later assessment. For the time being, the student will receive a vanilla CD. The CDs are printed, so if it’s a bad quality counterfeit, we’ll know very quickly.

      Also, each and every CD runs a VNC server, for both lecturer and students. If required, the lecturer can click on a target machine on the room map in the evaluation client and “pull” its desktop onto the beamer to have the student demonstrate his/her solution, so everybody can see it on the big screen.

      Vice-versa, the lecturer may decide to project his own screen to all students so that they can see his own desktop (in case the beamer fails this can be very helpful).

      Also, the machines can be remotely shut down by the lecturer. Basically, he clicks the corresponding button in his own evaluation client, the client instructs the server that all machines in a certain room are to be shut down. The server logs in to all clients via SSH and issues a shutdown command. Also, the firewalls on the CDs can be altered via the interface of the lecturer at the click of a button, telling the server what to do. Again, the server would log in to all clients via SSH and run the proper iptables commands to loosen or tighten network access for the students. Needless to say, the root password has to be a closely guarded secret.

      So basically, all remote control is done via SSH and VNC. No CD has to be specialized, as the “role” of a CD (lecturer or student) is based on who logs in to the evaluation client program. If a lecturer logs in, he’ll get the proper interface for controlling the server and with it all the clients in a given room. Rooms are identified by client MAC addresses (which is a weak point when mainboards/network cards die, but yeah).

      So essentially, you’ll need some control program and a server/client architecture. The evaluation server/client is not open source at this time. If you wish to contact the developer, let me know here and I’ll drop you an email. I’ll need to talk to him about it first though!

      If you want to know some real details about what was changed for the Knoppix part and how it was done, you’d need to wait until Monday, which is when I’m back at work. :) I could just pull the documentation from the servers at work, but right now is a holiday, so please accept my apologies for not doing so. :)

      So yeah, just let me know if you want to learn more.

      • Hi thrawn – thank you for your immediate reply. Heard that you are an Austrian too. I am working at
        BORG Perg and our students use their own notebooks for exams in math. Your approach to manipulate the machine-firewall in the knoppix-startup-script sounds fantastic. I have unpacked knoppix minirt.gz but never applied severe changes there.
        In our test-scenario (for the future – perhaps? now we plug out the APs – but with the upcoming of notebooks with SIM-cards thats not a solution at all) we created a knoppix-USB-stick with a couple of programs and a script which compresses all files in a specific folder and rsynced this archive to the homepage (target was a secret rsync module fetched from the server) of the Evaluator (not in public_html of course).
        Our troubles: not all notebooks are compatible with this USB-stick. So we must use the newest kernel possible. And so I digged up (with googles help) your docu about changing the kernel in a knoppix-distro.

        Btw, I am a retired teacher for math, physics and computer science. In our area I was the only admin with LINUX servers. I do the maintenance for the servers now as a volunteer – most of the time from my “home-office”.

        Regards Hans

        • Hey again Hans,

          Talk about dedication right there… continuing to do all that work even in retirement! Also, kudos for staying on top of modern software.

          The firewall is relatively easy, given it’s not much more than a series of iptables commands executed in succession. I could definitely share a sample set of two or three different firewall configurations if you wish.

          One of the significant problems might be that you’d need to ensure that you can remotely log into the target clients from some “controller machine”. If you can ensure that, remote control via SSH is relatively easy. For us it’s easy, we don’t even have DHCP. Just statically mapped IP addresses, that we can bind to MACs directly on the CD; My Knoppix decides on the IP address based on the clients MAC address – I call that “poor mans DHCP”, very unflexible though, and not an option for your use case.

          And prohibiting network access completely isn’t possible anyway. People are just tethering their phones to their laptops via Bluetooth, using them as 3G modems while they’re in their pockets, well-concealed. Plus, built-in SIM card slots in most books naturally. You could of course just remove BT and 3G modem support from Knoppix though, and WLAN too if you wanna be radical. WiFi/BT/3G kernel modules *could* be force-unloaded and reloaded at will via remote control using the modprobe -r <module> and modprobe <module> commands too, possibly following an ifdown <interface> or ifconfig <interface> down command, keep that in mind! You’d just need to build a complete list of drivers that you’d need to take care of. People could just use their bare phones to cheat though. Just bad luck that signal jammers are illegal in Austria. ;) We do know that our students have special discussion forums set up where they’re trading exam information. Access is strictly regulated, so we can’t “infiltrate” those places, besides it being illegal. A student can just use the phone to access such information or to secretly discuss the exam with other students while it’s ongoing. Closely monitoring them during exams is just as important as it was many years ago, that much I can tell (despite not being a teacher myself).

          We’re at an advantage there of course, because we can use our own desktop machines anyway. The fact that you have to adapt to new (and arbitrary) hardware so quickly is a serious drawback, because it means constant work… and you never know what those students might come up with in terms of new hardware. And while I was very satisfied with the kernel rebuild, it’s a ton of nasty work too, took me quite some time.

          • Sorry for the delayed reply – was on a mountainbike tour the last 2 days.

            Thanks for the warning about the upcoming work – kernel adaptation, changing to squashfs instead of cloop (no kernel patching necassary – squashfs is now included) and all that stuff – but it’s all a kind of freetime-work for me. If I am successful thats OK, if I am not – nobody cares.
            Thank you for your ideas and the encouraging words.
            Liebe Grüße Hans

            • Hey,

              Ah, I wasn’t aware of the squashfs being added. I haven’t gone beyond our Knoppix 6.2.1 yet. Quite amazing that newer 3.x kernels would even work with the old glibc, udev, etc…

              And I’m surprised that the latest Knoppix wouldn’t at least cover everything up to current hardware (like Intel Haswell, AMD Kaveri based machines and such).

              In any case, I wish you success my friend! Let me know how it goes! :)

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">