persistent image on dvd

[proctor]

by multiple knoppix-data.img do you mean at the same time (ie. on possibly different media)? if so then "no, not at this point." i am guessing this would require a cheatcode to work, as the user would need to specify a non-default location for the different image files (if for example you were using a dvd AND a flash chip at the same time).

if by multiple knoppix-data.img you mean "will it support either a writeable OR a read-only image?" the answer is yes. it already does that.

i hadn't thought of the use case of simultaneous writeable and non-writeable images when i wrote the patch. do you think there would be demand for that?

it also does not support multiple image overlay images simultaneously at all. however i believe implementing that (all on the same media) would be relatively trivial.

sincerely,
proctor

[proctor]

hello list,

the following information has come to light from klaus knopper, rendering moot my patch. this functionality has been available all along:

sincerely,
proctor

Please have a look at minirt.gz's /init:

mountunion(){
local dir tree=""
for dir in /KNOPPIX /KNOPPIX[0-9]; do
[ -d "$dir" ] && tree="$dir=ro${tree:+:$tree}"
done
mount -t aufs -o "br:$1=rw:$tree,noplink" unionfs /UNIONFS
return $?
}

mountunion() supports incremental overlays, i.e. the filesystem mounted
as /KNOPPIX is the base, /KNOPPIX[0-9] are changes vs. the base and vs
each other in ascending order, and the only argument to mountunion() is
the ONLY writable branch, either ramdisk or a read-write on-disk image
that's mounted somewhere.

Don't worry about "unionfs" here, it's just naming because of historical
reasons.

Now, if you want to record your changes from, let's say /ramdisk, to
another read-only image, you would do a

mkisofs -R /ramdisk | create_compressed_fs - 65536 > /tmp/KNOPPIX2, and
put the resulting file on your new DVD master directory into the KNOPPIX
folder. On next boot, KNOPPIX/KNOPPIX2 will be read-only mounted as
/KNOPPIX2, and mountunion() will stack your changes there on top of the
base image and put the read-write branch on top of that.

If you would like to do this without rebooting, you have to call the
full mount -t aufs command with all branches and with /UNIONFS as target
mountpoint, which will shadow the previous mount. In theory, a "-o
remount" with the additional branch in the "add" option, should also be
possible, but it never worked for me, maybe because of existing process
references to the previous stack.