An alternative to re-mastering for CD-size Knoppix flash disks.

[utu]

.
Greetings, Knoppix LiveUSB fans.

Attached please find two png screen snapshots to introduce you to
a script to manage Knoppix compressed image updates and persistence
files. The snapshots show two menus the script stackimu uses to
control the 'management' processes. The script is provided in
gzipped format.

If you are interested, I hope you will find or prepare a clone of a
recent Knoppix LiveUSB with persistence and try it out. Preferably
a LiveUSB derived from a Knoppix 7+ LiveCD, since that's what I use
all the time.

If you don't know what this is all about, you might first read a rambly
'Draft' within the Stacked.Images folder. You can read this 'Draft'
with leafpad alone if you wish, or with stackimu.

To get the whole picture you will need a working LiveUSB clone of Knoppix 7+
with a persistence file containing some added program material you would
like to safeguard by turning it into a compressed image update.

To do so, download the Stacked.Images.####.tar.gz file to your clone's
/home/knoppix directory, unzip it there with the command tar xvfz *.gz,
cd into your new Stacked.Images folder and there execute stackimu as knoppix
user with the command ./stackimu.

If you want to check the *tar.gz download, use the command,
echo "5e7142945d562c186cfe6c37683ee878 Stacked.Images.1106.tar.gz" | md5sum -c
and, note there must be exactly TWO spaces between the checksum and the filename.

As knoppix user examine stackimu's menus and text files and find out what
it is designed to do. After studying this material, if you want to try it
out more seriously, quit as knoppix user and begin again as root with the
command sudo ./stackimu.

I've used this technique myself for some time now on a LiveUSB made from
a Knoppix LiveCD built on a 2 Gb SDHC USB device and it suits my needs.
I hope you will find it useful as well. I would not be surprised to hear
that it may fail in some DVD-size situations, and certainly for any case
that a cloop tries to exceed 2 Gb.

Preview post does not clearly confirm *tar.gz upload, but here goes.

[utu]

If you are a cut-and-paste person, the previous should have read:

If you want to check the *tar.gz download, use the command,
echo "5e7142945d562c186cfe6c37683ee878  Stacked.Images.1106.tar.gz" | md5sum -c
and, note there must be exactly TWO spaces between the checksum and the filename.

Forum editor eats extra whitespace, you know.

[Blacksimon]

Hi utu,
you're doing a great job.
Stackimu only works for cd-size knoppix ? if I try with dvd-size could happen some kind of error ?

[utu]

Greetings, Blacksimom.

I'm no expert and don't use the DVD version very much, but I think
the problem is in the way cloops and iso9660 work together that makes
for complications with cloops larger than 2 Gb.

My program doesn't have the fine structure necessary to handle the DVD
case, but I think if one stays with CD-size Knoppix that no problems
will arise. The DVD complexity is what defines the generalized
remastering case.

From what I've read, the 'failure' which occurs with cloops larger
than 2 Gb is that file locations beyond a certain number 'wrap around'
and make inappropriate references. KK suggests you have to do a
file-by-file md5sum check to see this sometimes, the errors are
subtle, but deadly.

If you really want to work with DVD-size situations, I think you
might get into some serious trouble using stackimu.

I think stackimu makes it a virtue out of having ONLY a 2 to 4 GB
USB to work with, since I think (at least hope) this implicitly
gets around the filesize/cloop size considerations by its very
nature.

[Werner P. Schulz]

In my opinion it isn't useful to save the software device (the file knoppix-data.img). You have to store the content of this device, the folders and files within this.

For example: you have a persistent memory of 4GB and and the used size within this is 300 MB. Why store the whole knoppix-data.img and not only the content within this?

"knoppix-data.img" looks like a file, but it isnt't a file, it is a device with folders and files within it.

[utu]

Greetings, Werner.

You should read some of the text in 'Draft', Werner.
As I point out, I only save the .img long enough to make sure the Knoppix[n]
replacement is doing its thing.
You may, and I do, get rid of the .img when I'm confident it went ok.
I don't find it convenient to compress the .img, either, and may delete
this option in some upgrade.

I am not clear on your insistence on .img as a 'device'.
I thought the notion of unix was that everything might be thought of as a file.
Please be more explicit on why you make this distinction.
Otherwise this comes across as simply a cavil.

[Werner P. Schulz]

You should read some of the text in 'Draft', Werner.

I studied it carefully.

I am not clear on your insistence on .img as a 'device'.

Creating a persistent memory includes three steps:

1. make a file of max 4 GB (knoppix-data.img)
2. format it with ext2 filesystem
3. mount this device (/dev/loop0) on /KNOPPIX-DATA

In my example (CD flash installation on a 4 GB USB stick and 3.1 GB persistent memory) you can see, this device (persistent memory) works like a drive; within this drive 479 MB are used and 2.6 GB are available.

Why, for Heaven's sake, shall I save the whole 3.1 GB device and not only the content of 479 MB of this drive? Apart from doing so, there is no space left on the USB stick to go your way. And last but not least, it doesn't make sense, not to store a backup on a different medium.

[utu]

Why, for Heaven's sake

Greetings, Werner.

I would worry about the 479 Mb of persistent store that you have, should
your knoppix-data become corrupted. In that case you will probably
lose whatever the difference is between that 479 Mb and whatever you
have in your backup. I don't make daily backups, myself. Perhaps you do.
I just 'Install to flash disk' after a compressed image update and make a
clone after my last compressed image update. I do not operate with 479 Mb
of stuff in 'temporary' condition. Also, there would be, for me, an
un-necessary overhead in time on mounting 3 Gb persistence on every boot.

Whenever I have a 'significant' amount in persistent store, I prefer
to convert that to a compressed image equivalent which is less likely
to get written-over, and which can be recalled faster on boot. Much less
un-necessary re-writes to USB if you care about that. I'm not sure there
is a 'wear problem' for these re-writes.

Here's my stuff for comparison. I can tell I have 8.4 Mb diffence between
my last backup and the present. My 'backup' is in KNOPPIX1,2,3. I have a
clone as well. When I boot, it takes less time to bring in 485 Mb
persistent store, than for 3 Gb which I'd never use if I had it. I also know
the 8.4 Mb is mostly .mozilla cache stuff which I don't worry about.

Thanks for the nice comparison. I like what I've got better.
stackimu only costs 20-30 Kb to make this possible.

[utu]

Incidentally,
df over-reports the contents of /KNOPPIX-DATA by a factor of two or more relative to du in my case.
I think du is correct.

[Werner P. Schulz]

I would worry about the 479 Mb of persistent store that you have, should
your knoppix-data become corrupted.

No, there is nothing corrupted!

The size of the persistent memory is 3.1 GB and not 479 MB! 479 MB is the value of the used space within this drive. With

du -sh /KNOPPIX-DATA/

I get the value of 465 MB.

Also, there would be, for me, an
un-necessary overhead in time on mounting 3 Gb persistence on every boot.

In my case

• boot with persistent memory of 3.1 GB: 1min 4 sec
• boot without persistent memory 58 sec