Some thoughts on the 'fromhd' cheatcode

First, some definitions:

FileA: This is the LiveCD.iso image offered for download.

FileB: The root directory you see on a mounted CD (not booted)
after you've downloaded FileA and 'burnt its image to a CD'.
This CD root directory contains boot, and KNOPPIX directories, and some
small files. The boot subdirectory contains an isolinux subdirectory.
The KNOPPIX subdirectory contains an empty module subdirectory,
a large KNOPPIX file, call it FileC, and some small files.

FileC has no file designation, per se. I believe it to be a
compressed Knoppix filesystem.

One usage of these files is not only to make a LiveCD, but also to
use the LiveCD to make a LiveUSB. In this case, FileB LiveCD
contents are adapted to create a self-booting LiveUSB. The LiveUSB
can be used to further modify itself to incorporate a unique persistent
store capability. This new capability allows the USB to retain system
changes for subsequent reboots. These changes are retained in a file
called knoppix-data.img.

The liveUSB has a similar FileB (mounted, not booted) appearance.
This USB root directory contains boot, and KNOPPIX directories, and some
small files. The boot subdirectory contains a syslinux subdirectory.
The KNOPPIX subdirectory contains an empty module subdirectory,
a large KNOPPIX file, the same FileC I presume, a new large file
knoppix-data.img and some small files.

In the 6.4 version of Knoppix there is a cheatcode 'fromhd' which is
intended to allow selection of different versions of Knoppix to be
selected at boot time. Supposing you had the foresight to have several
different knoppix FileB's stored on say /dev/sda1 like /dev/sda1/FileB1,
/dev/sda1/FileB2,... /dev/sda1/FileBn. And suppose your LiveUSB is
on /dev/sdb1. Supposedly you could use your sdb1 LiveUSB to boot up
using the cheatcode fromhd=/dev/sda1/Filem, ignoring some sdb1 FileB
code and instead using parts of /dev/sda1/FileBm to boot.

At this point one might conceive of a yet another cheatcode that
would take the current knoppix-data.img in /dev/sdb1 and incorporate
its changes into a revised compressed KNOPPIX FileC and save it with
appropriate supporting files as a new candidate /dev/sda1/FileBx.
I would have called this new cheatcode 'tohd', but that name is
probably taken.

If the new candidate /dev/sda1/FileBx doesn't work out we can fall back
on earlier sda1 candidates or even sdb1 if necessary.

So what's not to like?

@ utu san

May I ask you a question ?

What was the USP that got you started with Knoppix and is that Unique Selling Point still valid today with Knoppix 6 ?

Help me with some numbers. I can do the math but I have the DVD, not the CD, edition so my numbers are huge.

Code:

---

du -hs /mnt-system/KNOPPIX

---

This gives you an upper bound on your current flash file system requirements. Remaster will generate a new KNOPPIX directory so double this first number.

Code:

---

sudo du -hs /UNIONFS

---

This gives you an upper bound on the temporary file system space you would need to remaster unless we can find a way of improving on kl522's method for remastering a USB installation.

Add the second number to the (doubled) first number and you get an idea of the minimum size flash file system you will need to do what you want.

I don't think you'll be able to do this on a mere 2 Gb SD card. You might able to do it on a 4 Gb SD card but I think you would have to live with a small (512 Gb) persistent store so you might find you have to 'revise' the KNOPPIX file quite often.

Life would obviously be a lot easier with an 8 Gb SD card but wait a minute.

I've never done an install to HD but I guess the difference between this and an install to USB is that the HD install decompresses the KNOPPIX file. You don't need knoppix-data.img because you can update, add, delete software, tweaks and whatever to your heart's content.

How much file system space might this requires ? At a guess, round about the amount of temporary file system space needed to remaster. I'm guessing you could get that onto a 4 Gb file system and continue to be happyily innocent of remastering.

I'm not trying to suggest this is what you should do, merely suggesting you can't have it always have it all so it's a good idea to think, from time to time, about what is essential for you and what would be merely nice to have.

Now, do you see why I ask what, for you, is the Knoppix 6 USP ?

@ Forester

du -hs /mnt-system/KNOPPIX is 1.9 Gb;
sudo du -hs /UNIONFS is 2.1 Gb

6 Gb is more than I would care to devote to the cause.
I don't need a new KNOPPIX (the condensed file), remember,
just a small tar.gz, all the other processes are already in place.

I guess my 'USP' is that I don't want to have to go off-line to
service the system. I'd like to have some menu commands and/or
cheatcodes that I could manage within what appears to be the
present desktop.

Can't we break my processes (not the re-mastering processes)
down to a few menu choices & cheatcodes?

Such as...
0...Make a copy of the current knoppix-data.img somewhere,
in case we need it later;
1...Make a tar.gz version of the current goodies in knoppix-data.img
and store this tar.gz file in the same directory as the
unmodified compressed KNOPPIX file;
2...Zero out the curreny knoppix-data.img;

On reboot...what I hope will then will happen is that
Knoppix will expand and merge the new tar.gz file, then
ask if we want to (Re-) establish a persistent store, using its
normal process to compute available space and then go ahead
and establish a new (smaller and empty) knoppix-data.img

The overhead here is a few new bash commands in an init (or two)
somewhere. Might even save a few bites rather than be an overhead.

Hi anyone reading this post and wondering where it all started and whether it went anywhere.

It started on ... http://www.knoppix.net/forum/threads...home-cheatcode

and continues on ... http://www.knoppix.net/forum/threads...update*.tar.gz