2 Attachment(s)
Using a Read-Only Persistence Capability in Knoppix LiveUSBs
.
There is an intriguing comment by Klaus Knopper regarding an otherwise
little-advertised capability of Knoppix to bring in additional cloop-
compressed overlays and to combine their contents with that of the master
KNOPPIX compressed file at boot. Klaus uses this feature to add non-free
material, which CeBIT is licensed to distribute, to CeBIT versions
of KNOPPIX liveCDs, LiveDVDs and their isos. This may be found at:
http://lists.debian.org/debian-knopp.../msg00005.html
AFAICT, Knoppix can handle, at present, eight overlays,
KNOPPIX0, KNOPPIX1,...KNOPPIX7. The LiveCD iso has only KNOPPIX, aka
KNOPPIX0. That leaves, for a LiveCD-sized LiveUSB, KNOPPIX1, KNOPPIX2,
...KNOPPIX7 unassigned and available.
For rather-permanent, unchanging parts of one's persistence, there are
at least three reasons one might want to utilize some of these unassigned
overlay positions, assuming one uses a LiveUSB with persistence.
1. A read-only version of the persistence material is safeguarded
against inadvertent write-over;
2 A read-only version may be compressed to 40% its ultimate size after
boot, with the same scant time penalty with which the master KNOPPIX files
are brought in; and
3. A read-only version will decrease the amount of writes associated
with its contained material over that which would occur if the material
were both read/write and uncompressed. There is a wear consideration
peculiar to USB write cycling.
Prior to Knoppix 7, I had added and/or changed a number of files and
programs beyond the standard files which come with the standard LiveCD iso.
With the advent of Knoppix 7.0, I converted these to a cloop-compressed
KNOPPIX1 and added that alongside the master KNOPPIX file in
/mnt-system/KNOPPIX/. I have developed a few additonal such additions
using Knoppix 7 since it first came out. I've recently converted these
additional changes to KNOPPIX2. I am now looking forward to further
adapting these efforts to an upcoming Knoppix 7.1. Two Screenshots, mtab
and df-h illustrate this; see Attached Images below.
I used a small bash program to facilitate and position the cloop-compressed-
read-only KNOPPIX1 and KNOPPIX2. The essential part of this program uses
Klaus K's magic formula, in essence, and for example:
Code:
cd /;
sudo mkisofs -R -U KNOPPIX-DATA | create_compressed_fs -B 131072 -m - - > /mnt-system/KNOPPIX/KNOPPIX1
One may account for the content of Knoppix changes in two groups:
1. The totality of files in /home/knoppix/ plus a small number of
individual files that may have been changed or added.
These changes may be recorded with a small bash script, like Keep*.
These changes may be restored with another small bash script, like Restore*.
2. The totality of files added via apt or Synaptic, may similarly be
expressed by another small bash script, like Uncommon.dpkg*.
*These or similar small programs, may be added to /etc/profile as follows:
Code:
Keep() { # Aid to backing-up unique user files
cd /; KEEP=/mnt-system/keep$(date +"%m%d%H").tar.gz
echo -e 'Compressing data; patience, this may take a little time..\c'
tar -cz --exclude *gvfs* --exclude *cache* \
-f $KEEP home/knoppix/ \
etc/profile etc/rc.local etc/X11/Xsession.d/45* etc/syslog-knoppix.conf \
etc/chromium/ mnt-system/boot/syslinux/syslinux.cfg
echo ".Done."; echo "Restore using the command, tar -xzf '$KEEP' -C /"
}
Restore() { # Restore $PEEK given the date, $1 in %m%d%H format
PEEK="/mnt-system/keep$1.tar.gz"
echo "Restoring '$PEEK files to /."; tar -xzf $PEEK -C /
}
Uncommon.dpkg() { # Packages uncommon to dpkg.current & "dpkg.$1"
dpkg --get-selections > /tmp/dpkg.current
comm -3 --nocheck-order /tmp/dpkg.current "dpkg.$1" | less | tee uncommon
}
Result of the experiment, deleting .gvfs in /home/knoppix:
.
It turns out that .gvfs is re-established in /home/knoppix within
a few minutes or hours of normal operation using at most: pcmanfm,
lxterminal, libreoffice, firefox 19, leafpad and this forum's editor.
From this I conclude that removing .gvfs probably causes no harm, but also
solves no problem. Using the exclude option for scripts in /home/knoppix
will prevent triggering error messages.
The exclude option may not be necessary for scripts making overlays from
/KNOPPIX-DATA, if .gvfs is not in this part Knoppix. One may assess the
situation, for all of Knoppix with the commands: updatedb; locate .gvfs
puzzled why the cache re-location effort here:
Quote:
Originally Posted by
Blacksimon
To move cromium cache in ramdisk you have to use...
The chromium cache is already in ramdisk, operating without persistence. See
Code:
updatedb; locate *[Cc]ache* | grep chromium
after booting with noimage and no prior re-arrangement of the cache.
This cache's current contents are probably lost on re-boot of course.
