Ramdisk and partial remastering in Knoppix 7

[Capricorny]

.
This is not to take away from heretofore 'standard' re-mastering procedure(s) but to
highlight a subtle refinement in using Knoppix that accomplishes much of what one hopes to
achieve by re-mastering, or making backups of some kind. This alternative is elegant
in minimizing the resources required in re-mastering, including time.

A full remastering of a Poor Man's Install using squashfs needs about 12GB temporary space, for example on a Windows partition, and it can take 15-20 minutes. For precise timings of an actual process, see my squashfs report, #7 in http://knoppix.net/forum/threads/298...l=1#post127051 So while minimization is obviously correct, the savings achieved may be less than impressive. IMHO, the relevant reasons for using this kind of scheme is to improve workflow, backup safety etc. That a full remastering can be done with a minimum of work, doesn't mean one should do it. On the contrary, the easier it is, the more careful one should be about checking out alternatives.

[utu]

.
I've had great success in successively updating my Knoppix 7.0.2 DVD-size LiveUSB
using the process of stacking successive compressed images mentioned by Klaus K in
the link noted in my Post #1. This is a LiveUSB on an 8 Gb Class 10 SDHC made using
a Knoppix 7.0.2 LiveCD. At present, I have 230 Mb unused of my 500 Mb persistence,
and have 3.1 GB unused in /mnt-system.

I consider success in this instance is in being able to efficiently save whatever
small increments I develop in my LiveUSB, and to do so in such a fashion that
the occasional inadvertent ruination of tweaks stored only temporarily is 'no big deal'.

My KNOPPIX1, in 31 Mb, contains the bulk of my usual tweaks, except flash;
my KNOPPIX2, in 85 Mb, contains flash, an ntfs revision and Hidden Gems.
My current KNOPPIX-DATA has only a few new tweaks, so it hardly qualifies yet
for moving to the safety of KNOPPIX3.
These two new compressed images added about eight seconds to my boot-up time.

If one starts out with a LiveUSB and persistence, one may disregard ramdisk as a
necessary special case. The little program I use for this progression is as follows.
I have only chosen to automate a few of the steps, leaving several simple procedures
that require some judgment to the process as outlined in my Post #14.

#!/bin/bash
# Declare Integer count
#
# ~/text/smite: remember to do 'chmod +x backup' & 'chown root:root smite'
# Activate in /home/knoppix/text as sudo ./smite
#
IMGDIR=/mnt-system/KNOPPIX/; count=1
cd $IMGDIR; for dir in KNOPPIX[0-9]; do let count++; done
UPDIMG=$IMGDIR'KNOPPIX'$count

# No more than 9 images allowed
if [ "$count" -gt  9 ]; then echo 'Too many images; exiting.'; exit 0; fi

cd /KNOPPIX-DATA/; sudo mkisofs -x '*[Cc]ache*' -x '*.wine*' -R -U etc home root usr var| \
create_compressed_fs -B 131072 -m - - > $UPDIMG

exit 0

So far, it is my impression that for the purpose of progressing one's LiveUSB by
stacking successive images one may disregard a lot of the mkisofs options that are
required to define an iso for a bootable CD or for handling non-Linux files.
The exclude option is one that IS essential, to allow editing of what's ultimately saved.

I'd be pleased to hear of anyone else's experience with this stacking idea.

[Capricorny]

Just one technical remark about number of images handled. I haven't tried the cloops, but for ordinary loop the busybox version used seems to be limited in number. Has anybody tried how many will actually be mounted of KNOPPIX..KNOPPIX9? All, as we should hope for, or less?

BTW, I wonder how a subversion repo would work for persistent store backup with the modest amount of data/files we have there after remastering. I think about trying it myself, but if anybody already has, it would be interesting to hear about the experiences. The rationale is that it is inefficient to back up the image file often when the actual changes made are only to a limited number of files.