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

[utu]

I get the value of 465 MB.

The difference between this value and its counterpart in your 'backup'
is what you have at risk IF your knoppix-data.img becomes corrupted.

In my case

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

My time to on-line is 28 seconds.


I appreciate your comparative numbers a lot.

[Werner P. Schulz]

The difference between this value and its counterpart in your 'backup'
is what you have at risk IF your knoppix-data.img becomes corrupted.

I have no backup within my USB stick. Where do you see it?

[utu]

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.

On a different medium, I suppose.
Did you misplace it?

[Werner P. Schulz]

1. screenshot: Here you can see the situation before I purged "xpdf"

2. screenshot: Now are the deletion-marks in /KNOPPIX-DATA/ (/dev/loop0) for the two files xpdf and xpdf.real. This is the proper way, Knoppix will use persistent memory.

3. screenshot: After running your script "xpdf" is reastablished?!
The deletion-marks now within /KNOPPIX1/ (/dev/cloop1) doesn't work.

You cannot use /dev/cloop1 like /dev/loop0.

[utu]

Greetings, Werner.

I really do appreciate that you are concerned, and I respect your expertise,
but I don't know what you are trying to say here.

You can see that I am operating with Knoppix and three compressed images somehow
or other. I can't offer an IT proof of any kind. It just works. I may be
missing something here, but it's not obvious to me what it might be.

I gave you a reference to KK's suggestion along these lines. Did you look into
that? Is there any problem with my interpretation of his idea there?

Respectfully.

[utu]

Post 14 is unclear to me in its message, but I'll take a shot at it.

I describe an algorithm that is useful to my purposes which packages
compressed images of program material which collects and add capabilities
to my OS over time. The collection has two good qualities. First it
makes the saved material less likely to be inadvertently over-written.
Secondly it stores this material more compactly than otherwise.
Its an algorithm.

It's not good or bad. It's a definition. You have to add your own
criteria to describe it as better or worse than some other definition.
It does have its own peculiarities, as do all algorithms.

A peculiarity of this particular algorithm is that it demonstrates
how adding stored material and removing stored material in any OS
are not necessarily reversible inverse operations.

If you object to this as a 'shortcoming' of this algorithm, you must
surely be upset with Synaptic sometimes when you try to un-install
a previously installed program and end up in 'dependency hell'.

I find it a very minor restriction for my purposes to avoid situations
which would require _removing_ previouly compressed and saved material.

I expect it will take more resources to eliminate this _perceived_ flaw.
I find the restriction less onerous than the thought of bringing to
bear additional resources to eliminate this restriction.

[Blacksimon]

Hi Utu,
my point of view about the use of Stackimu is that it can be useful for:
- speed up the boot process
- decrease the size of knoppix-data.img
- compress images of personal customizations
But these customizations (loaded in one or more dev/cloop) may be only the most important ones and will not be changed for whole time that you will use the OS chosen.
For everything else you have to use the knoppix-data.img to store data as usual.
Feel free to tell me if I'm wrong in interpreting.
So I'm not sure Stackimu can be useful to me as it is for you, but by ideas of others can always create something interesting...

bye

[utu]

Greetings, Blacksimon

Thanks for your comments. Glad to discuss this with you.

My primary purpose in using stackimu is safeguarding my personal customizations.
It's one of several back-up methods of Klaus K's I've looked at.
It is my current method of coping against the occasional knoppix-data.img disaster.
I keep my 'used' fraction of knoppix-data.img small and its default total at ~500 Mb.

There are several things that just come along for free:
stuff stores more compactly; 2.5:1 compression.
stuff takes less time booting up; 30 second boot to on-line.
the idea works with minimal total device capacity; 2 Gb SDHC is only about half-full

[Capricorny]

My own experience is that full remastering is so quick and simple for me, that I rather do that than creating incremental modificatons. As for persistent store backup, I would guess that rsync -axu to another loop-mounted image should work just fine. In case a full file copy is deemed to take to long. If day-to-day modifications are not too extensive, using a subversion (or git) repository is also something to think about - then you will also be able to go back in time to any specific time you have checked in.

As Werner noted, use/not use of persistent store does not seem to affect boot-up times very much (DVD version). So in my use case, time would not be an important factor for choice of method.

[utu]

General Observation:

The title
'An alternative to remastering for Knoppix CD-Size LiveUSBs'
seems to offend some of the remastering cognoscenti.

Perhaps a better title might have been
'A minimalist script to transcribe Knoppix cloop customizations'

My focus is on saving my customizations and my style is to work with
adequate, but reasonably minimal resources. Remastering, as purely defined,
would be a poorer alternative to achieve these ends.

The latent capability within Knoppix to use overlaid compressed images
is under-utilized for its worth, in my opinion.


Specifically, in regard to stackimu as presented for download in Post #1:

1. I have downloaded the material posted on Knoppix.net, checked and found that
Stacked.Images (1106) is working as I intended.

2. Knoppix has a built-in (un-explained) minimum 200 Mb value for persistent store.
A recent Synaptic update brought in 287 Mb to /var; this came close to over-running a
350 Mb knoppix-data.img allotment originally in use. I'm now using 500 Mb as my
(default) persistence file size.

3. There may be a surprise at KNOPPIX8, if one hasn't provided enough cloops.
The Knoppix standard is to provide cloop[0-7]. linux cloop.cloop_max=10 (or more) at boot
would provide cloop8 and cloop9. mountknoppix and mountunion in /init might need to be re-
defined as well, beyond KNOPPIX[0-9], to further increase the number of updates beyond 9.
For the time being, my stackimu update limit is set to provide only 7 updates,
in accordance with the KNOPPIX 7 current default definitions.

4. 'View Contents of /KNOPPIX-DATA' is more informative if defined with a replacement
for the $V4 stackimu line which reads:
$V4) TL=$V4; du -m --max-depth=2 --exclude=.wh* $KDF \
| sort -g -r | sed 's_/KNOPPIX-DATA_._' > SF;;
This improved the View of /*DATA Option is to allow assessment of specifically where
additional material is coming from and to serve as a guide in editing of what's stored
by prepare_update.

5. Added 'View Option, df -h device assignments'. Note that KNOPPIX[n] files are reported
in the expanded size in Mbs in df reports, and in condensed size in Mbs in du reports.
Therefor, the size of contents of the /*DATA directory may appear more than twice their
size in df -h than in du -h.

6. Removed Main Option 6 to provide a compacted, off-line, prior-knoppix-data.img as a
belt-and-suspenders back-up option, since it seemed both clumsy and unnecessary
in practice.