Unofficial cheatcode for those who miss the old official home= cheatcode

[Forester]

For Knoppix 6, the initialisation script (init) and others were rewritten and several cheatcodes folks used under Knoppix 5 disappeared. Among these is home=, which allowed the Knoppix persistent data to be stored on a different device from the main Knoppix image and was the way to use persistent data with a CD/DVD.

Below is a patch for the init script that implements a cheatcode that does the same job. The patch is for Knoppix 6.4.3 (developed against a USB install of the EN version of the DVD). Since it is a patch, there is a fair chance it will apply cleanly to the init script of other Knoppix 6 releases. It should also apply to init scripts with other local modifications provided the functions createdata() and mountdata() have not been changed.

This is not an attempt to port the old implementation of home= from Knoppix 5 to Knoppix 6 but an new implementation from scratch. As such, it may behave differently so it is named differently.

Use:


knoppix_data=/media/aDev/someDirectories/theImage.extThe cheatcode will attempt to mount the device /dev/aDev on /media/aDev and try to mount a persistent data image at the path someDirectories/theImage.ext.

If the persistent data image does not exist, the create image dialogue will create one but the file type extension is ignored and you will get a persistent image with the file type aes or img, depending on whether you choose the encryption or not.

If the attempt to mount /dev/aDev on /media/aDev fails, then the fall back is the default of /mnt-system/KNOPPIX/knoppix-data.{aes,img}. /dev/aDevmust be a block device with a file system recognised by the init script on a partition recognised by the Knoppix boot kernel (possibly with the addition of extra modules).

File systems currently supported are vfat, ntfs-3g, reiserfs, ext3, ext2 (no, lvm2 is not recognised). Devices supported include hard-drive and USB block devices but probably not SD and other camera flash devices (but you're welcome to try).

The init script function that creates the persistent data image checks that there is enough space on the device and gives up silently if there is not. A consequence of this is that when you boot from a CD/DVD, the init script does not ask if you want to create a persistent image because there is no free space on a CD/DVD.

There is no reason to suppose the knoppix_data= cheatcode is will not work with (a remastered) Knoppix CD/DVD but this has not been tested.

The patch is to be applied to the init script, which is packed into minirt.gz, See the Wiki for notes on how to pack and unpacked minirt.gz. For a USB installation, minirt.gz can be copied from and back to the Knoppix boot partition. For Knoppix on a CD/DVD, a remastering of the Knoppix iso file is required and a new CD/DVD burnt.



--- init.org 2010-11-25 18:53:50.000000000 +0000
+++ init 2011-02-20 09:40:29.000000000 +0000
@@ -565,7 +566,8 @@

createdata(){
local rc size avail
- avail="$(df -m /mnt-system | awk '{size=$4}END{print size - 1}')"
+ knoppix_data="${knoppix_data%.*}"
+ avail="$(df -m "${knoppix_data%/*}" | awk '{size=$4}END{print size - 1}')"
[ "$avail" -ge 200 ] 2>/dev/null || return 2
runknoppixchroot /usr/bin/dialog --timeout 10 --inputbox "\n${CREATEIMG1}${avail}${CREATEIMG2}\n" 16 75 2>/tmp/knoppix.size; rc="$?"
echo -n "${CLEAR}"
@@ -576,6 +578,7 @@
[ -b /dev/loop0 ] || mknod -m 755 /dev/loop0 b 7 0
[ -d /KNOPPIX-DATA ] || mkdir -m 755 /KNOPPIX-DATA
if [ "$rc" = 0 ]; then # Encrypted
+ knoppix_data=$knoppix_data.aes
local pw1="" pw2="" len=0 mods="" m
setkeyboard
while [ -z "$pw1" -o -z "$pw2" -o x"$pw1" != x"$pw2" -o "$len" -lt 4 ]; do
@@ -592,27 +595,41 @@
[ -d /sys/module/"$m" ] || mods="$mods $m"
done
[ -n "$mods" ] && runknoppixchroot /sbin/modprobe $mods >/dev/null 2>&1
- createfile /mnt-system/"$knoppix_dir"/knoppix-data.aes "$size"
+ createfile $knoppix_data "$size"
losetup -d /dev/loop0 2>/dev/null
- runknoppixlib /sbin/losetup -p 0 -e aes -k 256 /dev/loop0 /mnt-system/"$knoppix_dir"/knoppix-data.aes </tmp/knoppix.pw; rc="$?"; rm -f /tmp/knoppix.pw
+ runknoppixlib /sbin/losetup -p 0 -e aes -k 256 /dev/loop0 $knoppix_data </tmp/knoppix.pw; rc="$?"; rm -f /tmp/knoppix.pw
runknoppixlib /sbin/mke2fs -F -m 0 /dev/loop0
sleep 2; echo -n "$CLEAR"
mount -t ext2 -o rw /dev/loop0 /KNOPPIX-DATA && return 0
else # Unencrypted
- createfile /mnt-system/"$knoppix_dir"/knoppix-data.img "$size"
- runknoppixlib /sbin/mke2fs -F -m 0 /mnt-system/"$knoppix_dir"/knoppix-data.img
+ knoppix_data=$knoppix_data.img
+ createfile $knoppix_data "$size"
+ runknoppixlib /sbin/mke2fs -F -m 0 $knoppix_data
sleep 2; echo -n "$CLEAR"
- mount -t ext2 -o loop,rw /mnt-system/"$knoppix_dir"/knoppix-data.img /KNOPPIX-DATA && return 0
+ mount -t ext2 -o loop,rw $knoppix_data /KNOPPIX-DATA && return 0
fi
return 1
}

mountdata(){
local img base ext m mods found=""
- for base in /mnt-system/"$knoppix_dir"/knoppix-data /mnt-system/knoppix; do
- for ext in aes img; do
- img="$base.$ext"
+ if [ -n "${knoppix_data}" ]; then
+ [ "${knoppix_data#/dev/}" != "${knoppix_data}" ] && knoppix_data="/media/${knoppix_data#/dev/}"
+ if [ "${knoppix_data#/media/}" != "${knoppix_data}" ]; then
+ img="${knoppix_data#/media/}"; img="${img%%/*}"
+ mkdir -p "/media/${img}"
+ trymount "/dev/${img}" "/media/${img}" >/dev/null 2>&1 || knoppix_data=""
+ [ -n "${knoppix_data}" -a "${knoppix_data#/media/*/}" == "${knoppix_data}" ] && knoppix_data="${knoppix_data}/${knoppix_dir}/knoppix-data"
+ fi
+ [ -d "${knoppix_data}" -o "${knoppix_data}" != "${knoppix_data%/}" ] && knoppix_data="${knoppix_data%/}/knoppix-data"
+ fi
+ [ -z "$knoppix_data" ] && knoppix_data="/mnt-system/$knoppix_dir/knoppix-data";
+ for base in "$knoppix_data" "/mnt-system/$knoppix_data" "/mnt-system/$knoppix_dir/$knoppix_data" /mnt-system/knoppix; do
+ for ext in "" .aes .img; do
+ img="$base$ext"
[ -r "$img" ] || continue
+ [ -d "$img" ] && continue
+ knoppix_data=$img
message -e "\r${CRE}${GREEN}${USING} ${YELLOW}$img${NORMAL}"
[ -b /dev/loop0 ] || mknod -m 755 /dev/loop0 b 7 0
[ -d /KNOPPIX-DATA ] || mkdir -m 755 /KNOPPIX-DATA

[utu]

@ Professor Forester

Your observations and the avenue you have opened up here prompt me to
ask a question I could not articulate before. It is the following:

I'm happy enough working with a 2Gb SD Card which emulates a LiveUSB
rendition of Knoppix, currently 6.4.4, with lots of tweaks saved up
in knoppix-data.img. I have 1181 Mb allotted to knoppix-data.img.
I've only used about 240 Mb so far, so economizing for space is not
for me a motivator for any change.

I save my knoppix-data.img occasionally in case of a crash. But
restoring from a crash is a clumsy affair I'd like to improve upon.
A crash is defined as having shut down such that a knoppix-data-img
was written to the SDCard that now won't boot or operate properly.
Recovery for me means deleting the unworkable knoppix-data.img
and replacing it with a saved copy. Requires a CD Knoppix and time.

I'd like to re-master, without all the fuss and real estate usually
associated with it. I'd like to be able to accumulate my tweaks within
the same SD Card into past-knoppix-data.img and current-knoppix-data.img
possibly, by successively, and occasionally incorporating the
past-knoppix-data.img tweaks into the basic Knoppix compressed image
and re-allocating a diminished space for current-knoppix-data.img additions.

This, in essence, might be a mere variation of your idea.
Except here only one medium involved, the single SD Card, or USB device,
if you prefer. It may only require an option in your patch which
enables this to occur when selected by a slightly different cheatcode.

Also, FYI, my laptop thinks the SDCard slot is its USB #3 (out of 4),
and I have not found any resrictions, other than mechanical, in
treating the SD Card as any other USB device.

[Forester]

@ utu san

Much to learn I still have !

You touch upon a number of interesting points that may each merit their own thread but I can find no question mark that delineates the question you articulate.

Why I can't see my camera card from Knoppix is on the list of things to look into some day. Meanwhile a thead that collects together what works already and what doesn't might be handy.



$ lsusb
Bus 001 Device 003: ID 0cf2:6250 ENE Technology, Inc.
For me, it may be as simple as adding 0cf2:6250 to a list somewhere.

You have a large knoppix-data.img that is little used. I started with a much more modest 512 Mb image and was alarmed at how fast this space was gobbled up by greedy programs. I am interested in folks' experience and that might be another thread.

Back up and restore of knoppix-data.img could be the topic for yet another thread. I'm still thinking about this but I guess it means messing around with the init script again. * Sigh *

I am new to remastering and I'm deliberately making it hard by using the DVD rather than the CD. I am actively looking into ways of reducing the 'fuss and the real estate requirements' but that's a thread for a different forum.

My 'avenue' ? Do you mean my use of patch to present the changes ? That's hardly new. I use patch as a way of keeping my 'tweaks' separate and reapplying them after a major upgrade. That's another thread and I don't think 'How do I do it ?' is the question you articulate.

Are you referring to my attempt to emulate the old home= cheatcode ? I believe that something like home= should be an option for all, even those who may never need it. I, myself, am not using it at the moment. I've made it public in what I hope is the true Open Source tradition. If someone finds it useful someday, tant meiux, if not, tant pis but the best would be for someone take it and improve on it.

The loss of home=means Knoppix 6 is considerably less versatile that its predecessors and that is regrettable. My 'observation' is the assumption that it is OK to insist the compressed image and the persistent store are in the same directory is a case of 'premature optimisation'. A cardinal sin often committed by projects with resources or time inadequate to the task. If Knoppix is very largely a solo effort, then the Ingenieur has my pity but not my sympathy.

My goal is indeed to simplify (aka make safe by reducing the number of manual steps involved) the process of folding changes recorded in knoppix-data.img into the KNOPPIX image. I think 'Is this possible ?' is your question. That too is another thread and I think you have already started that one.

[utu]

@ Forester

Here's what I'd like to automate into Knoppix by means of
its cheatcodes, and for extra credit, do this without re-mastering.

In principle, the Knoppix system is made up by bringing together
three files. The compressed image KNOPPIX, a compressed file
update*.tar.gz and an un-compressed knoppix-data.img.
For simplicity, let's call these A, B & C.

Most of us don't use the compressed B, but it's there to be used.

Most of us have an uncompressed C which has all our neat little
tweaks, saved in a file that is ALWAYS bigger than necessary.
It's not full, and it's not compressed.

After using C for a while without changes and without finding
problems, I'd like to promote the tweaks in C into a compressed
version of the same in B.

Having done so, I'd like to re-allocate the space availabe for
a new ~empty C, to make room for B or a bigger B as the case
may be.

Being an optimist, I'd like to achieve all this on-line rather
than off-line (as in re-mastering), manipulating cheatcodes.

The question is, how do I do this?
Provoking someone proficient in bash scripting, maybe?

[Forester]

HI anyone reading this and wondering whether there was any follow up to utu san's digression.

Yes there was ... see http://www.knoppix.net/forum/threads/29064-Some-thoughts-on-the-fromhd-cheatcode though there utu is actually thinking about the knoppix_dir cheatcode,

[Forester]

New patches for the knoppix_data= are needed to work properly with 'squashed' Knoppix.

Attached are:
- generalise.txt which is the same patch as uploaded in post #29 of http://www.knoppix.net/forum/threads/28484-Squashfs-ed-knoppix
- mountbypath.txt which is the same patch as uploaded in post #1 of http://www.knoppix.net/forum/threads/29082-Unofficial-cheatcodes-to-backup-and-restore-persistent-data
- knoppix_data.txt which implements the knoppix_data= cheatcode (in a single line)
- knoppixsh.txt which is a patch for /etc/init.d/knoppix-autoconfig

Remember knoppix.sh ? The old Wiki is full of talk of how this can be used to customise Knoppix start up by the back door. Until someone wrote in there that is didn't work with Knoppix 6.0.1.

Perhaps it didn't but it does work with Knoppix 6.4.3 and 6.4.4. The snag is that in the simpler world of Knoppix 6, knoppix.sh has to be in the same directory as KNOPPIX and knoppix-data.img. If you're running from CD or DVD, you can't have a knoppix.sh any more than you can have a knoppix-data.img.

Since the knoppix_home= cheat code allows you to put knoppix-data.img somewhere else so that you can have a persistent store even when running from CD or DVD, it seems only fair that you can put knoppix.sh there too and expect it to work. This is what the final patch implements.

Have fun,

[utu]

Professor Forester,

In my small LiveUSB world, may I ignore these four new creations for the moment?

Are these new pronouncements meant only for liveCD/DVD and hd installs?

[Forester]

In my small LiveUSB world, may I ignore these four new creations for the moment?


Yes is the short answer. The long answer is almost as complex as the instructions for filling in a tax return form.

If you don't want to use the cheat code, then don't apply the patches.

If you want to use the cheat code and have not already used the original patch in the post that started this thread, then use these patches and not the original.

If you have already applied the original patch and don't want to try squashed knoppix, then stay as you are.

If you applied the original patch you might still want to try the patch for knoppix.sh but that does not involve remastering.

@ utu

BTW I can now remaster my USB install without fuss or additional real estate. I'll write up how when I've fewer distractions.

[utu]

@ Forester

I'm good at taxes, but bash scripting's not my thing.

So, if I'm not sold on squashing yet, I can go ahead with
the earlier scripts to see how a standard Knoppix 6.4.4
might be patched to allow cheatcodes to effect the
processes outlined in 'Making use of update*.tar.gz'.
Right?

What have you and the others done to convince anybody
that squash beats anything by any useful measure?
Is it 30% faster or does it take 30% less resources or
is it 30% cheaper in some way? I don't buy 30% more
complicated or 30% more interesting or 30% newer.

Your last line is a real grabber. I presumed that this
item on my wishlist was 'a bridge too far'.
Really interested to see how you made this leap.

[dinosoep]

it is about 200 % faster to compress otto :p
it boots a tad faster and is also smaller.
squashfs is under very active development and cloop isn't

you don't need to squashify your knoppix install but it's really easy to do (even I succeeded after screwing up 4 times) :D

[dinosoep]

excuse me for my noobyness forrester, but if I were to apply those patches, do I need to use the commands described here:http://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/ ? (I have never used a patch before)

I really like things like this getting released. It'll keep knoppix a bit more 'alive' and makes knoppix even more usable.
now we just need to get klaus knopper's attention to this thread.
He should really implement the knoppix_data, knoppixsh and mountbypath while considering moving to squashfs?

[Werner P. Schulz]

it is about 200 % faster to compress

.. I can't believe this result. What did you compress, Knoppix CD or DVD? How long (exact) will it take to compress with sqashfs and with cloop (create_compressed_fs)?

And which command-line for "create_compressed_fs" did you use?

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.4.4 remaster)

[Forester]

excuse me for my noobyness

Noobyness excused.



if I were to apply those patches, do I need to use the commands described here:http://www.cyberciti.biz/faq/appy-patch-file-using-patch-command/ ?

Yes, the patch is a simple one to apply. You should get some messages about offsets and possibly fuzz. That's OK. A message that says hunk failed is not OK.

Here's a tip for noobyness ...

Every Linux command comes with a man page. To find out about patch(1) from a console terminal, type in man patch. To find out more, try man man.

If you don't like man pages (and I can see why) but you do like html, you can find the man pages on-line. Here's two I use ..http://linux.die.net/man/1/man2html and http://www.linuxmanpages.com/man1/man2html.1.php.

I also cheat. I've the MAXI (aka DVD) edition so I've KDE and I've Konqueror. For installed software, I simply type into the Konqueror address bar something like #bash to call up in html format the man page for bash(1). If I type in ##sed I get the GNU project info pages on sed(1) in a form I can actually use. :)

BTW, patch(1) means section 1 of the man pages - that means user command. Compare with passwd(5), which describes the format of the passwd file, not the command passwd(1) while mount(8\) and mount(2) mean the system administration command and the operating system call respectively.



I really like things like this getting released.



Thank you for your enthusiasm but I would not go so far as to call what I done a release. Without other people trying it, it cannot be called tested thoroughly and so cannot be called released.



now we just need to get klaus knopper's attention to this thread.


KK has a mailing list. He does not need a forum - he already knows all the answers. :D



He should really implement the knoppix_data, knoppixsh and mountbypath while considering moving to squashfs?

First you would have to ask politely why there is no home=anymore. If he he does not have a good reason why such a thing is a bad idea (and he might) then you might ask if he would welcome a patch that might do the job.

Have you ever tried to get a 'developer' to accept a patch from someone he has never heard of before ? Camels and the eye of a needle come to mind.

[utu]

Re this whole thread: Nicely done, Forester; My thanks as well.

[kl522]

Have you ever tried to get a 'developer' to accept a patch from someone he has never heard of before ? Camels and the eye of a needle come to mind.

A lot of wisdom in this paragraph. :)

[dinosoep]

mkisofs & mksquashfs
well, it wasn't really that accurate. I used mkisofs the first time I remastered and mksquashfs the second time, a lot had changed in the meantime. But mkisofs took really a lot of time while mksquashfs took considerably less.


.. I can't believe this result. What did you compress, Knoppix CD or DVD? How long (exact) will it take to compress with sqashfs and with cloop (create_compressed_fs)?

And which command-line for "create_compressed_fs" did you use?

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.4.4 remaster)

[Forester]

it is about 200 % faster

@ werner

The only thing more versatile than the English language is the users of the English language in their use of the English language.

Take a time interval of 2 hours. 50 % longer is 3 hours, 50 % shorter is 1 hour. 100 % longer is 4 hours, 100 % shorter is no time at all.

If I take 2 hours to do something and dinosoep takes twice as long, then he does it 100 % slower than I and do it 100 % faster than he.

When dinosoep says squashfs compression is 200 % faster, he is saying it takes only one third the time but I do not think that is what he meant to say and that is almost certainly not what you understood him to mean.

@ dinosoep

From yesterdays post I see you have 2 Gb of RAM and swap space. There is no excuse for the cloop compression to be so slow. When you did your remastering, how many clever loop devices mounted from files on your (shock horror :rolleyes:) windows partition did you use ?

Further discussion of squashfs should take place under the relevant thread and that is not this one,

[dinosoep]

Your right, it doesn't really belong here but I will try to find the commands I used and I had one loop device mounted.
going to try the patches tomorrow and see if it works for me :)

[Werner P. Schulz]

.. I can't believe this result. What did you compress, Knoppix CD or DVD? How long (exact) will it take to compress with sqashfs and with cloop (create_compressed_fs)?

... now I have done a test for my own.

using virtual machine (VirtualBox), 1 GB RAM, swap partition 1 GB

using Knoppix CD-Version 6.4.4

decompress /KNOPPIX/KNOPPIX (705211 K => 100%) to directory '/remaster' (2054135 K)

losetup /dev/cloop0 /media/sr0/KNOPPIX/KNOPPIX
mount -t iso9660 /dev/cloop0 /knoppix/loop
rsync -aH /knoppix/loop/* /remaster
a) compress '/remaster' to KNOPPIX

genisoimage -R -U -no-bak -quiet \
/remaster | create_compressed_fs -q -B 65536 \
-f /tmp/knoppix_tmp - /knoppix/KNOPPIX/KNOPPIXsize of new KNOPPIX: 740461 K (104,96%)

compression time: 7 min 03 sec


b) compress '/remaster' to KNOPPIX.squasfs

mksquashfs-lzma /remaster
\/knoppix/KNOPPIX/KNOPPIX.squashfssize of KNOPPIX.squashfs: 719876 K (102,08%)

compression time: 6 min 42 sec

I think the differences are not worth the trouble to leave a well established compression method.


Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.4.4 remaster)

[utu]

@ Werner

Would a comparison of expansion times be comparable?
Thanks.

[kl522]

I think the differences are not worth the trouble to leave a well established compression method.

I don't want to get into the war of the compression speed comparison, as I mentioned earlier, as some of the comparison what not a fair one, basically they did not use the same compression algorithm, it is not apple to apple.

However, I would like to dispute this point about cloop being the well eastablished compression method.

Which is more established compression method ?

Maybe my knowledge is skewed but here is what I know :-

1. Squashfs has long existed if not as long as cloop compression.
2. Squashfs is accepted into stock kernel a few versions back but cloop is still an external patch.
3. You can find squashfs in almost all embedded devices, including your typical home routers, home ADSL modems, home media players, home appliances such as TVs and so on. If you count the number of seats ( linux OS ) uses squashfs compared to cloop, squashfs is many many times more widespread than cloop..
4. Just run this utility on the compression file system :-


$ file /mnt-system/KNOPPI/KNOPPIX
KNOPPIX: POSIX shell script text executable

$ file /mnt-system/KNOPPIX/KNOPPIX.sq
KNOPPIX.sq: Squashfs filesystem, little endian, version 4.0, 630912472831 bytes, 189043 inodes, blocksize: 147 bytes, created: Mon Jan 7 04:52:16 1991Now even a utility like 'file' knows about squashfs, which is more established ?

[Werner P. Schulz]

... with
".. to leave a well established compression method" I did mean, that Klaus Knopper may have good reasons not leaving a well established compression method for his Knoppix distribution.

@ utu

I have no comparison of expansion times. And I only did my compression test because I couldn't believe the result of dinosoep.



Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.4.4 remaster)

[kl522]

... with I did mean, that Klaus Knopper may have good reasons not leaving a well established compression method for his Knoppix distribution.
He should submit this cloop patches to the kernel team if he continues to want to use it for Knoppix. The knoppix kernel, there are still two modules which are compiled outside the standard distro, ie the aufs2 and cloop. I am seeing there is significant progress in integrating aufs2 into the standard distro, it will not be long aufs2 will be part of a standard kernel source.

cloop will soon be left as the only one needed as an external patch. I am not aware that there is any effort to put that into standard kernel source. I hope I am wrong in this. :)

[dinosoep]

forester,
I have no clue how you got the patches working or what I am doing wrong on my end.
I retried to apply all the patches a couple of times but got kernel panic or other problems.
Now I just decided to apply generalise.txt on a new minirt.gz and make no other modifications.
after booting up he tries to search for knoppix a couple of times in usb and hard drives but never finds them.
then in red there pops up "could not mount disk to mnt-system. Starting debug shell..."
and I can navigate around :p
/KNOPPIX is empty
/KNOPPIX-DATA non-existing
/mnt-system empty
...

where did I made a mistake?

[Forester]

forester,
I have no clue how you got the patches working or what I am doing wrong on my end.
I retried to apply all the patches a couple of times but got kernel panic or other problems.
Now I just decided to apply generalise.txt on a new minirt.gz and make no other modifications.
after booting up he tries to search for knoppix a couple of times in usb and hard drives but never finds them.
then in red there pops up "could not mount disk to mnt-system. Starting debug shell..."
and I can navigate around :p
/KNOPPIX is empty
/KNOPPIX-DATA non-existing
/mnt-system empty
...

where did I made a mistake?

Oh dear dinosoep,

The red message means /init can't find your KNOPPIX image on any flash or hard drive partition. The patch generalise.txt has nothing to do with this part of /init.

However, I remember you have squashed KNOPPIX. Is that still the case ? Is your KNOPPIX file now named KNOPPIX.sq ?

You say you have started again with a new minirt.gz. If this is the one that came with Knoppix 6.4.4 then its /init script will be looking for an unsquashed KNOPPIX. That would explain the red message.

I suspect you need either to 'patch' /init with your own patch to boot squashed Knoppix or use the squashfs.txt patch I offered.

Get that working first. If that's OK save your minirt.gz somewhere safe before trying to put on any other patches.

If you are wondering, no you don't need to apply any patch more than once, even if it appears on more than one thread.

When you apply a patch you will get Hunk messages. They should say succeeded. If any say failed, stop right there. We'll have to figure out why the patch failed. It certainly isn't safe to go forward with only half a patch.

[dinosoep]

oops, I'm terribly sorry forester
I thought generalise.txt had squashfs included too.
trying it out right now