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"

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...nt-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". 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.