Using overlayfs to re-master 64-bit Linux Mint 17.2 Xfce

.
I use a Linux LiveUSB as my everyday computing medium by choice. I prefer to maintain
my Windows hardware unaltered, except for OEM boot media selections. In other words,
I don't care to even dual-boot Linux and Windows on the same hardware.

A LiveUSB with self-contained read-write persistence has served me well for years as
a proxy for an 'installed' Linux system architecture. The down-side of this architecture
is the volatile nature of the persistence mechanism which may easily be catastrophically
corrupted by inadvertent user commands. Knoppix allows making iso9660/cloop-compacted
overlays, which combine compaction and protection in that these compacted overlays are
read-only and virtually immune to being inadvertently written-over and corrupted.
Up until now, combining overlays with Knoppix either is either restrictive on whether base
and overlay material 'overlaps' in use of address space, or prohibitively demanding in
workspace required to carry out the combining of overlapped material.

In its simplest form overlays are assumed not to refer to any storage addresses in common
and may therefor be combined in a simple additive manner. If there is some overlap
of common address material, simple addition is not appropriate. The best example is
where a program in an earlier overlay is 'deleted' in a later overlay. Simple addition
will not recover the unused space the 'deleted' program occupies.

A more involved treatment known as re-mastering is often used to more properly join the
net material represented as a result of the final overlay with redundant use of
storage eliminated. This is usually achieved by first expanding any compacted overlay,
then dealing with redundancies, and finally joining and re-compacting the resultant
material. The workspace required to do this is often larger than twice the size
of the original, un-compacted live system. The final result may be either larger
or smaller than the initial configuration to be re-mastered, depending on the net
additions and subtractions that are involved.

Mint 17.2 uses overlayfs as a replacement for aufs to perform the necessary LiveUSB
start-up capability of combining compact read-only base OS material with read-write
persistence file contents. But, as an enormous bonus, with the advent of overlayfs,
there now exists, in principle, a way to combine COMPACTED material rather than only
EXPANDED material to achieve the effect of re-mastering. The resultant workspace
required is much less in this instance. For example, fully within the capability
of an 8 Gb LiveUSB to contain both persistence and the ability to re-master an identical
8 Gb clone.

Dav Stott has provided a blog to describe-, and a bash program using overlayfs on
a Ubuntu LiveUSB- to carry-out an actual proof-of-principle of 'merging' compacted
program material to achieve the same end as 're-mastering' un-compacted program
material and in much less workspace. Dav's September 14, 2013 blog is here:
http://davstott.me.uk/index.php/2013...stent-storage/
Dav's March 23, 2015 updated bash program is here:
https://github.com/davstott/ubuntu-u...aster/mergeusb

I used Dav's program to 'merge' the basic squashed 1.5 Gb of my Mint Linux OS with
~400 MB net of my unique ext3 persistence additions, and one subtraction. The
result being a fully functional new squashed 1.4 Gb tailor-made-adaptation of
Mint 17.2 to suit my own specific needs. My one 'subtraction' was Ubiquity,
Mint's borrowed Ubuntu installed-program installer, which I don't need.
I provided for ~4.0 Gb of Fat32 persistence (ext3fs) in order to have enough
workspace for this effort. Even so, there is still 2.2 Gb yet-unused Fat32
filespace on my 8 Gb LiveUSB. More-than 4.0 Gb persistence would have exceeded
Fat32 address space limitations, and 2.0 Gb isn't quite enough to do the job
in this instance.

To use Dav's program, one's Mint 17.2 LiveUSB also needs its own squashfs-tools,
which Mint 17.2 currently doesn't otherwise need. Mint 17.2 does use overlayfs, but
only for the usual start-up combining of the squashed Mint OS and the ext3 persistence material.
It took 24 minutes using an exact clone of the original un-merged 64-bit Mint 17.2
Xfce to carry-out the merge on an 8 Gb Class 10 SDHC.
The clone used a 7.51 Gb partition of a 16 Gb USB3 SanDisk Cruzer; 7.51 Gb is
the same size as the '8 Gb' SDHC to facilitate dd cloning.

I've been composing all this on my first mergeusb/re-mastered Mint 17.2 LiveUSB,
while enjoying all my favorite tweaks and additions. I have a whopping 3.6 Gb of
unused volatile persistence to use, and a good feeling that most of my own tweaks
and additions are now protected in read-only form, alongside a slimmed-down
Mint 17.2 sans Ubiquity.

Nice to hear that things are moving a bit in the field of union file systems. But I really don't see the big point in doing filesystem-remodeling in small spaces on flash media. Computers usually have disks, and if they don't you can always use an external USB disk. My cloop/squashfs images are usually 3.3-4.1GB, and together with persistent store, they expand to 8-12 GB when the union file system is copied to an ordinary structure. From there, a new image is created by compression, so the total extra space requirement for remastering a 4+4 GB system in this case is about 16 GB. Doesn't sound like av awful lot, and it isn't.

As for backing up, I do remasterings so often that it is less of a point to have a good backup regime for persistent store. I just create a backup copy of that every now and then, as needed.

Update: I have done quite a few remasterings lately, and the filesystem copy takes about 3-5 minutes for ca 16GB on my SSDs. So it is in no way a showstopper, but the main reason I think I will keep it even if I switch from aufs to overlayFS, is (perceived) robustness. When the persistent store is damaged, some files get lost during the copy process, but this may be fixed by reinstalling the packages the lost files belong to, or restoring them from backup. It may well happen the overlayFS merging procedure is as robust (or even better) in this respect, but that remains to be seen. I have also become very convinced that using FAT32 for system administration is a very bad idea whenever it is possible to avoid it. But for daily use, it is the opposite for me: I keep the volumes at