persistent image on dvd

[proctor]

hi,

i would like to make a dvd which contains my customizations, in the spirit of kyle rankin's "Remaster Knoppix without Remastering (http://www.knoppix.net/wiki/Remaster_Without_Remastering)"

his article was written in the era if 5.1 and i have been unsuccessful in finding a way to do this with the 6.x series.

what i have tried is using the "persistent" feature to install to a usb stick, and then try to move the resulting "knoppix-data.img" file to the KNOPPIX folder of the cd and use it from there. but when i then try to boot with this image unionfs fails.

i get:


Using /mnt-system/KNOPPIX/knoppix-data.img
mount: mounting unionfs on /UNIONFS failed: Invalid argument
/init: line 693: /bin/mount: not found
/init: exec: line 742: /sbin/init: not found

i am guessing that this might be because it wants the knoppix-data.img file to reside on a writable media, but i am not sure....

so, have we lost the ability to "remaster without remastering" or is there a smarter way to get persistent changes onto a dvd/cd without going through the "official" remastering process?

sincerely,
proctor

[klaus2008]

You can find a file called KNOPPIX-CHEATCODES.TXT in the KNOPPIX directory of the Knoppix V6.2 CD. It has an interesting section


If you place an update*.zip or update*tar.gz file on the medium holding
the KNOPPIX data, it will be unpacked onto the overlayed filesystem
before starting "init", thus allowing quick reconfiguration of the
system.
I think you should save your customizations in a file update01.tar.gz using the tar program and place that file in the KNOPPIX directory before you burn your new DVD.

[proctor]

You can find a file called KNOPPIX-CHEATCODES.TXT in the KNOPPIX directory of the Knoppix V6.2 CD. It has an interesting section
I think you should save your customizations in a file update01.tar.gz using the tar program and place that file in the KNOPPIX directory before you burn your new DVD.

thanks! that looks like an excellent approach, and one that i missed while reading the init script.

as i reported on the thread http://www.knoppix.net/forum/threads/28207-Adding-more-persistent-disk-images i have been successful now with this approach using the knoppix-data.img data files (after mounting the image and "tarring" the contents), but only after removing the "dot-wh-dot" entries first. apparently this approach to the dot-wh-dot entries is not the best way forward however (see above mentioned thread).

while tinkering with this myself i came up with a different approach, which has some benefits and some drawbacks as compared to the "update*.tar.gz" approach:

one drawback to my approach is that it requires a hacked init script (inside minirt.gz).

but once this is in place, the knoppix-data.img files can be used on read-only media without modification.

i have done only basic testing of this patch, but so far it seems to work as prescribed. perhaps someone more knowledgeable will see some problems i have missed. but in case it seems useful to anyone, here are the modifications i made:

sincerely,
proctor



--- arst/init 2010-10-26 04:09:31.568928798 +0000
+++ initramfs/init 2010-10-26 15:35:05.007733846 +0000
@@ -571,15 +571,19 @@ createdata(){
return 1
}

+IS_DATA_MEDIUM_WRITEABLE="ro"
+
mountdata(){
- local img base ext m mods found=""
+ local img base ext m mods found="" IS_DATA_MEDIUM_WRITEABLE_MASK="555"
for base in /mnt-system/"$knoppix_dir"/knoppix-data /mnt-system/knoppix; do
for ext in aes img; do
img="$base.$ext"
[ -r "$img" ] || continue
+ IS_DATA_MEDIUM_WRITEABLE="ro"
+ stat -c %A "${img}" | grep -iE 'w' > /dev/null && IS_DATA_MEDIUM_WRITEABLE="rw" && IS_DATA_MEDIUM_WRITEABLE_MASK="755"
message -e "\r${CRE}${GREEN}${USING} ${YELLOW}$img${NORMAL}"
[ -b /dev/loop0 ] || mknod -m 755 /dev/loop0 b 7 0
- [ -d /KNOPPIX-DATA ] || mkdir -m 755 /KNOPPIX-DATA
+ [ -d /KNOPPIX-DATA ] || mkdir -m "${IS_DATA_MEDIUM_WRITEABLE_MASK}" /KNOPPIX-DATA
found="true"
case "$ext" in
aes)
@@ -595,8 +599,8 @@ mountdata(){
[ "$try" -gt 1 ] && echo -n "${CYAN}(#$try/3) "
if runknoppixlib /sbin/losetup -e aes -k 256 /dev/loop0 "$img"; then
echo -n "$NORMAL"
- runknoppixlib /sbin/e2fsck -y /dev/loop0 >/dev/null 2>&1
- mount -t ext2 -o rw /dev/loop0 /KNOPPIX-DATA && return 0
+ [[ "${IS_DATA_MEDIUM_WRITEABLE}" == "rw" ]] && runknoppixlib /sbin/e2fsck -y "$img" >/dev/null 2>&1
+ mount -t ext2 -o "${IS_DATA_MEDIUM_WRITEABLE}" /dev/loop0 /KNOPPIX-DATA && return 0
fi
echo -n "$NORMAL"
losetup -d /dev/loop0 >/dev/null 2>&1
@@ -604,8 +608,8 @@ mountdata(){
done
;;
*)
- runknoppixlib /sbin/e2fsck -y "$img" >/dev/null 2>&1
- mount -t ext2 -o loop,rw "$img" /KNOPPIX-DATA && return 0
+ [[ "${IS_DATA_MEDIUM_WRITEABLE}" == "rw" ]] && runknoppixlib /sbin/e2fsck -y "$img" >/dev/null 2>&1
+ mount -t ext2 -o loop,"${IS_DATA_MEDIUM_WRITEABLE}" "$img" /KNOPPIX-DATA && return 0
losetup -d /dev/loop0 >/dev/null 2>&1
;;
esac
@@ -647,11 +651,17 @@ mountknoppix(){
}

mountunion(){
- local dir tree=""
+ local dir tree="" media writeable
for dir in /KNOPPIX /KNOPPIX[0-7]; do
[ -d "$dir" ] && tree="$dir=ro${tree:+:$tree}"
done
- mount -t aufs -o "br:$1=rw:$tree,noplink" unionfs /UNIONFS
+ for media in "${@}"
+ do
+ writeable="ro"
+ mount | grep -iE "${media}.*\(rw," > /dev/null && writeable="rw"
+ [[ -d "${media}" ]] && tree="$media=$writeable${tree:+:$tree}"
+ done
+ mount -t aufs -o "br:$tree,noplink" unionfs /UNIONFS
return $?
}

@@ -659,7 +669,12 @@ if mountknoppix; then # compressed
checkbootparam "debug" && debugshell "Past mounting /KNOPPIX."
if ! checkbootparam "noimage" && mountdata; then
checkbootparam "debug" && debugshell "Past mounting /KNOPPIX-DATA."
- mountunion /KNOPPIX-DATA
+ if [[ "${IS_DATA_MEDIUM_WRITEABLE}" == "ro" ]]
+ then
+ mountunion /KNOPPIX-DATA /ramdisk ### make sure the writeable branch is last argument for aufs filo tree construction (see function mountunion)
+ else
+ mountunion /KNOPPIX-DATA
+ fi
else
mountunion /ramdisk
fi

[proctor]

i have done only basic testing of this patch, but so far it seems to work as prescribed. perhaps someone more knowledgeable will see some problems i have missed. but in case it seems useful to anyone, here are the modifications i made:



i should also mention that the above patch is for the 6.2.1 init script

[kl522]

Personally I think your patch is the way to go. The 'tar' thingie does not seem right to me.
This is rightfully "Remaster Knoppix without Remastering (http://www.knoppix.net/forum/../../wiki/Remaster_Without_Remastering)". I did not study the patch,
perhaps if it could ( or already ) support multiple knoppix-data.img (one on read medium
and one on readwrite medium currently ) that will be great.

[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.