persistent image on dvd

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:

Code:

---

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

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

Quote:

---

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.

Quote:

---

Originally Posted by 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
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

Code:

---

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

---

Quote:

---

Originally Posted by 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

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.

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

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

Quote:

---

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.

---