PDA

View Full Version : Knoppix V6.7.0



Werner P. Schulz
08-03-2011, 10:24 PM
... Klaus Knopper has finished his new version of Knoppix
http://www.knopper.net/knoppix-mirrors/

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

kl522
08-04-2011, 02:33 AM
... Klaus Knopper has finished his new version of Knoppix
http://www.knopper.net/knoppix-mirrors/

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

Again, changelog is not available ?

utu
08-04-2011, 02:51 AM
Greetings Werner & kl522

I've got my new Knoppix 6.7 LiveUSB running.
Kernel is 2.6.39.3 #21; desktop background is new; Chromium replaces IceWeasel.
adriane not on menu, but lots of /user/bin/adriane components.
mis-behaving aumixer applet on my install. Flash not working for my Chromium; is for IceWeasel.
otherwise much like old-faithful 6.4.4. Was hoping for a built-in re-mastering option.
CD version really fills a CD with 730.7 Mb.

utu
08-04-2011, 03:19 AM
ps

Knoppix 6.7 still uses networkmanager, but now goes from start-of-boot to wifi-on-line in 52 seconds.
Best in this regard of any LiveUSB I know of.

utu
08-04-2011, 03:23 PM
pps

My Knoppix 6,7 Chromium still will not do flash even after update synaptic & re-install. I like IceWeasel better anyway & have exchanged these.
My LXterminal & root terminal will not hold preferences unless I add the 'optional' LXDE package with synaptic.

LibreOffice seems to be a full-monty version to keep up with the Joneses.
Apparently all the extra dimensions don't add much space over and above just calc & write.

First rate, snappy LiveUSB, a trifle better than 6.4.4, but that was already superb.
Hidden adriane capability needs some explication.

utu
08-04-2011, 08:27 PM
@ kl522

I don't know of a changelog, but this DstroWatch table lets you compare 6.7 with previous versions:
http://distrowatch.com/table.php?distribution=knoppix

This table indicates Firefox 5 to be an option with 6.7.
I was unable to verify Firefox 5 as an option with my CD version of 6.7, even opening up all possible repositories.
I had found Firefox 5 to have a few problems in Ubuntu Unity, so I'm not that anxious about this.
For example, it would not retain preference changes in font maxes & mins and disabling of url underlines.

utu
08-04-2011, 11:56 PM
Well, here's an update on Firefox 5 for Knoppix 6.7:

After you've used 6.7 for a little while with IceWeasel as your
browser, Firefox 5 will invite you to download & install Firefox 5.0.1
from a tar.bz2 file. I did so. My downloaded Firefox 5.0.1 does
not have the Ubuntu Unity problem of holding the preferences.
Has its own flash, already. Only initial problem I see is figuring how
to integrate this on the LXDE desktop. At first, it is started via a
command line.

I moved my download to /usr/local and unzipped it with tar -xjf there.
To start it, make sure IceWeasel's not running and enter the command
/usr/local/firefox/firefox.

So, I guess the DistroWatch table is correct as it stands.

I'll run with both browsers for a while to see if FF5 is worth changing
from IceWeasel.

utu
08-05-2011, 01:19 AM
Firefox suggests you download libstdc++5 to install an icon on
the desktop to start FF5. That costs 1 Mb, and doesn't work for me.
Luckily just add a 'new blank file' to the LXDE desktop, for example
a file called ff.sh, executable, contents you guessed:
/etc/local/firefox/firefox. Acts like a click-on icon.
Pretty plain, but it works, costs only a few bytes.

FF5 is pretty snappy; I think I might switch.

kl522
08-05-2011, 03:59 AM
@ kl522

I don't know of a changelog, but this DstroWatch table lets you compare 6.7 with previous versions:
http://distrowatch.com/table.php?distribution=knoppix
Better than none but they are not the kind of information which interest me in.


This table indicates Firefox 5 to be an option with 6.7.
I was unable to verify Firefox 5 as an option with my CD version of 6.7, even opening up all possible repositories. I am amused. :) The way things are classified, we may as well also list Opera and M$ Window Explorer as options too ! True enough, if you willing dig up everything and put in new things ....

Capricorny
08-05-2011, 01:28 PM
From the documentation I have seen so far, this is mostly a kernel upgrade/bugfix/driver update release. Plus quite a bit of reworked Adriane stuff. I'm most curious about any changes to the innards, can't wait to take a diff of the minirt init ;) (But I don't think so much has changed there recently.

As for Firefox 5.0.1, at least in 64 bits it looks promising.

Capricorny
08-05-2011, 02:25 PM
Here's the init changes (ADRIANE 6.7). Among other things, ext4 mounting is now in place.
Also, the kernels, both 32 and 64 bits, have grown a lot - probably heaps of extra modules included as deemed necessary.


";;
4c4
< # (C) 2011 by Klaus Knopper <knoppix@knopper.net>
---
> # (C) 2010 by Klaus Knopper <knoppix@knopper.net>
140,141d139
< local rc="1"
< # Try to be quick, and probe the "most likely" file systems first
146,161c144,146
< mount -t ext4 -o "$RW" "$1" "$2" || \
< mount -t ext3 -o "$RW" "$1" "$2" || \
< mount -t ext2 -o "$RW" "$1" "$2"
< rc="$?"
< # Still no luck? Try everything else that the (static) kernel supports
< if [ "$rc" != 0 ]; then
< local fs
< for fs in `awk '!/^nodev/{print $1}' /proc/filesystems 2>&1`; do
< case "$fs" in
< ext[234]|reiserfs|ntfs|fuse*|*fat|iso9660) ;; # Already did that
< *) mount -t "$fs" -o "$RW" "$1" "$2"; rc="$?";;
< esac
< [ "$rc" = "0" ] && break
< done
< fi
< return "$rc"
---
> mount -t ext3 -o "$RW" "$1" "$2" || \
> mount -t ext2 -o "$RW" "$1" "$2"
> return "$?"
303c288
< [ -r "$mod" -a ! -d /sys/module/"${mod%.ko}" ] && insmod "$mod" >/dev/null 2>&1
---
> [ -r "$mod" -a ! -d /sys/module/"${mod%.ko}" ] && insmod "$mod"
338c323
< *\ vga=[0-9]*|*debug*|*\ splash*) true;; *) echo -n "";;
---
> *\ vga=[0-9]*|*debug*|*\ splash*) true;; *) echo -n "";;
341,347d325
< message \
< ' _ __ __ __ _____ _____ _____ __ _ __ ___ _______
< / / / / / | / / / ___ \ / __ \ / __ \ / / | |/ / / ___/ \___ /
< / /__/ / / | / / / / / / / /__/ / / /__/ / / / \ / / /_ __/ /
< / / _ - / /| |/ / / / / / / _____/ / _____/ / / / | / __ \ /_ _\
< / / \ \ / / | / / /__/ / / / / / / / / /\ \ / /_/ / _ / /
< /_/ |_|/_/ |__/ \_____/ /_/ /_/ /_/ /_/ |_| \____/ /_/ /_/'
447,455c425
< #@@@GvR
< # Try using other (SMB) mounts
< [ -z "$MOUNTED" ] && [ -x /static/mount.cifs ] && { if [ -n "$NFSDIR" ]; then
< message -n "${CRE}${BLUE}Trying to SMB mount CD on ${MAGENTA}$NFSDIR${BLUE}...${NORMAL}"
< message /static/mount.cifs "${NFSDIR}" /mnt-system -r -o guest,noserverino,nounix
< /static/mount.cifs "${NFSDIR}" /mnt-system -r -o guest,noserverino,nounix > /dev/null 2>&1 && MOUNTED="yes"
< [ -z "$MOUNTED" ] && umount /mnt-system > /dev/null 2>&1
< fi; }
< #@@GvR
---
>
482c452
< checkbootparam "bootfrom" || debugshell
---
> debugshell
488,580d457
< # Return existing device names listed as regular expressions
< listpartitions(){
< local pattern file
< for pattern in "$@"; do
< for file in $(find /sys/class/block -maxdepth 2 -name "$pattern"); do
< file="${file##*/}"
< [ -b "/dev/$file" ] && echo "/dev/$file"
< done
< done
< # awk 'BEGIN{old="__start"}/'"$1"'/{if($0==old){exit}else{old=$0;if($4&&$4!="name"){print "/dev/"$4}}}' /proc/partitions # Insufficient, does not find CD-Roms
< }
<
< #@@@GvR Bootfrom Section start
< BOOTSYS="/mnt-system"
< if [ ! -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then
< # find BOOTFROM variable (/dev/sda1/boot/k620/*.iso)
< BOOTFROM=""; bootfrom="";
< for i in $CMDLINE; do case "$i" in [Bb][Oo][Oo][Tt][Ff][Rr][Oo][Mm]=*) eval $i;; esac; done
< [ -n "$bootfrom" ] && BOOTFROM="$bootfrom"
< if [ -n "$BOOTFROM" ]; then
< # we may have an ISO file, try mounting it
< BOOTISO="/mnt-iso"; BOOTDEV=""; BOOTFILE=""
< mkdir -p $BOOTISO $BOOTSYS
< [ -b /dev/loop1 ] || mknod -m 755 /dev/loop1 b 7 1
< if [ -n "$NFSDIR" ]; then
< umount $BOOTSYS; MOUNTED=""
< message nfs remount "${NFSDIR}" "${BOOTISO}" -o ro,rsize=8192,wsize=8192,hard,nolock,intr$SECUREOP TIONS
< mount "${NFSDIR}" "${BOOTISO}" -o ro,rsize=8192,wsize=8192,hard,nolock,intr$SECUREOP TIONS > /dev/null 2>&1 && MOUNTED="yes"
< if [ -z "$MOUNTED" ]; then
< umount $BOOTISO >/dev/null 2>&1
< if [ -x /static/mount.cifs ]; then
< message cifs remount "${NFSDIR}" "${BOOTISO}" -r -o guest,noserverino,nounix
< /static/mount.cifs "${NFSDIR}" "${BOOTISO}" -r -o guest,noserverino,nounix > /dev/null 2>&1 && MOUNTED="yes"
< [ -z "$MOUNTED" ] && umount $BOOTISO > /dev/null 2>&1
< fi
< fi
< BOOTFILE=$BOOTFROM
< else
< BOOTDEV=$(echo "$BOOTFROM" | awk -F/ '{print $1"/"$2"/"$3}')
< BOOTFILE="${BOOTFROM#*/}"; BOOTFILE="${BOOTFILE#*/}"; BOOTFILE="${BOOTFILE#*/}"
< message -n "${CRE}${BLUE}Trying to mount the ISO partition ${MAGENTA}$BOOTDEV${BLUE}...${NORMAL}"
< trymount "$BOOTDEV" "$BOOTISO" >/dev/null 2>&1
< fi
< if [ ! -r "$BOOTISO/$BOOTFILE" ]; then umount $BOOTISO >/dev/null 2>&1
< message "${CRE}${RED}Cannot mount the partition ${MAGENTA}$BOOTDEV${NORMAL} (cannot find: ${RED}${BOOTISO}/${BOOTFILE}${NORMAL})"
< ls -al "$BOOTISO"
< else
< message -n "${CRE}${BLUE}Trying to mount CD image on ${MAGENTA}${BOOTFILE}${BLUE}...${NORMAL}"
< losetup /dev/loop1 "$BOOTISO/$BOOTFILE" && mount -r /dev/loop1 $BOOTSYS >/dev/null 2>&1
< if [ ! -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then umount $BOOTSYS >/dev/null 2>&1
< message -n "${CRE}${RED}Cannot mount CD image on ${MAGENTA}${BOOTFILE}${NORMAL}"
< umount "$BOOTSYS" >/dev/null 2>&1
< losetup -d /dev/loop1 >/dev/null 2>&1
< else
< message -e "\r${CRE}${GREEN}$DISTRO ${FOUNDAT}: ${MAGENTA}${BOOTDEV}/$(cd $BOOTISO; ls -a $BOOTFILE)${NORMAL} "
< fi
< fi
< # try to find ISO in an alternate locations using the same path
< if [ ! -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then
< message -n "${CRE}${MAGENTA}Trying to find the ISO image in an other partition...${NORMAL}"
< # If USB storage device, wait for USB...
< if [ -d /sys/bus/usb/drivers/usb-storage ]; then WUSB="1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20"; else WUSB="1"; fi
< for i in $WUSB ; do
< for BOOTDEV in $(listpartitions 'hd[a-z]' 'hd[a-z][0-9]*' 'scd[0-9]*' 'sr[0-9]*' 'sd[a-z]' 'sd[a-z][0-9]*'); do
< if [ -b "$BOOTDEV" ]; then
< message -n -e "\r${CRE}${BLUE}Searching for ISO in: ${MAGENTA}${BOOTDEV}${NORMAL} "
< trymount "$BOOTDEV" "$BOOTISO" > /dev/null 2>&1
< if [ ! -r "$BOOTISO/$BOOTFILE" ]; then umount $BOOTISO >/dev/null 2>&1; else
< message -n "${CRE}${BLUE}Trying to mount CD image on ${MAGENTA}${BOOTFILE}${BLUE}...${NORMAL}"
< losetup /dev/loop1 "$BOOTISO/$BOOTFILE" && mount -r /dev/loop1 $BOOTSYS >/dev/null 2>&1
< if [ ! -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then
< umount $BOOTSYS >/dev/null 2>&1
< losetup -d /dev/loop1 >/dev/null 2>&1
< else
< message -e "\r${CRE}${GREEN}$DISTRO ${FOUNDAT}: ${MAGENTA}${BOOTDEV}/$(cd $BOOTISO; ls -a $BOOTFILE)${NORMAL} "
< fi
< fi
< fi
< done
< if [ -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then
< break
< else
< message -n -e "\r${CRE}${BLUE}${WAITFORUSB}${NORMAL} $i ";
< sleep 1
< fi
< done
< fi
< fi
< fi
< if [ -r "$BOOTSYS/$knoppix_dir/KNOPPIX" ]; then MOUNTED="yes"; FOUND_KNOPPIX="true"; fi
< #@@@GvR Bootfrom Section end
<
<
582c459
< amount=$(awk -F: '/^MemTotal/{printf "%d",int($2); exit 0}' /proc/meminfo 2>/dev/null); #'
---
> amount=$(awk -F: '/^MemTotal/{printf "%d",int($2); exit 0}' /proc/meminfo 2>/dev/null)
594,607c471,481
< #@@@GvR add "ramdisk" parameter to allow specifying ramdisk size, otherwise just use max(ram*4/5,2000)M
< for i in $CMDLINE; do case "$i" in [Rr][Aa][Mm][Dd][Ii][Ss][Kk]=*) eval $i;; esac; done
< case "$ramdisk" in
< [0-9]*[KMG]) RAMDISK="$ramdisk" ;;
< esac
< if [ -z "$RAMDISK" ]; then
< if [ "$TOTALMEM" -ge 2000 ] >/dev/null 2>&1; then
< RAMDISK="$(expr $TOTALMEM / 5)"; RAMDISK="$(expr $RAMDISK \* 4)M"
< else
< # Too large, but we can still use swapspace
< RAMDISK="2G"
< fi
< fi
< #@@@GvR
---
> # Return existing device names listed as regular expressions
> listpartitions(){
> local pattern file
> for pattern in "$@"; do
> for file in $(find /sys/class/block -maxdepth 2 -name "$pattern"); do
> file="${file##*/}"
> [ -b "/dev/$file" ] && echo "/dev/$file"
> done
> done
> # awk 'BEGIN{old="__start"}/'"$1"'/{if($0==old){exit}else{old=$0;if($4&&$4!="name"){print "/dev/"$4}}}' /proc/partitions # Insufficient, does not find CD-Roms
> }
609c483
< if [ -z "$FOUND_KNOPPIX" -a -z "$TSCLIENT" ]; then
---
> if [ -z "$TSCLIENT" ]; then
650c524
< mount -t tmpfs -o size="$RAMDISK",dev,suid,exec tmpfs /ramdisk
---
> mount -t tmpfs -o size=2G,dev,suid,exec tmpfs /ramdisk
671c545
< [ -r /KNOPPIX/lib/ld-linux.so.2 -a -x /KNOPPIX/"$cmd" ] && /KNOPPIX/lib/ld-linux.so.2 --library-path "/KNOPPIX/lib:/KNOPPPIX/usr/lib:/KNOPPIX/lib/i386-linux-gnu" /KNOPPIX/"$cmd" "$@"
---
> [ -r /KNOPPIX/lib/ld-linux.so.2 -a -x /KNOPPIX/"$cmd" ] && /KNOPPIX/lib/ld-linux.so.2 --library-path "/KNOPPIX/lib:/KNOPPPIX/usr/lib" /KNOPPIX/"$cmd" "$@"
739c613
< for base in $home /mnt-system/"$knoppix_dir"/knoppix-data /mnt-system/knoppix; do
---
> for base in /mnt-system/"$knoppix_dir"/knoppix-data /mnt-system/knoppix; do

utu
08-05-2011, 04:50 PM
Since I find 6.7 pretty solid for my meager needs, I'll complain about
something else.

Looking at the new minirt init reminds me that there's been no revision
of the Knoppix cheatcodes in a long time.

The last time I checked I thought there were some omissions and some
ambiguities that ought to get corrected.

Anyone else have this feeling?

Capricorny
08-06-2011, 10:55 AM
I think the cheatcode list could get an overhaul, yes. I'm not so sure about the need for new codes, generally. They should only be introduced with new functionality, when needed.

New functionality may be introduced without the need for new cheatcodes. With the latest init modification, Knoppix has, in fact, become completely file system-agnostic wrt what kind of system carries the Knoppix files.

Now, init goes through the usual list (ext4 now included, that inclusion possibly prompting Klaus to take it further). When no mount is achieved, init goes through the kernel's file system capabilities, and tries anything not already tried. This means, that for a new application using some odd-type fs, (think Knoppix on your espresso machine or some other embedded device), it is enough to compile the odd-type fs module into the kernel, and copy the ordinary files over. From there on, things are, in principle, handled just like they resided on FAT32, ext3, etc.

The most significant new cheatcode I can think of now, is squashfs. Knoppix should absolutely support squashfs out of the box, but the init modifications needed are rather small, almost trivial. (I've uploaded a patch against 6.4.4 init to handle cloop and squashfs transparently for the end user..)

We have been talking about several kinds of new functionality, and the best way to proceed, I think, is to make an example implementation that could be directly included and publish it, like I have done with squashfs.

Right now, the basic system I run is remastered 6.4.4 pure 64-bits, with custom compiled kernel 2.6.39.2 and squashfs image. This is written in iceweasel 5 running off the 6.7.0 DVD iso image under qemu-kvm, 1GB RAM (System RAM 8GB). I just synaptic-installed and test ran R in this vm, so I think I can say things are working right off the shelf here.

utu
08-06-2011, 06:23 PM
@ Capricorny

Two questions for you:

1. My cat /proc/filesystems says my kernel knows squashfs. From your post #13 should I expect
that Knoppix 6.7 will mount squashfs _without_ some unique new cheatcode?

2. Are you tracking what Ruymbeke is doing in regard to minirt.gz mods for 6.7?
There is a very recent thread to that effect elsewhere on these forums.

Cheers.

Capricorny
08-06-2011, 06:40 PM
@ Capricorny

Two questions for you:

1. My cat /proc/filesystems says my kernel knows squashfs. From your post #13 should I expect
that Knoppix 6.7 will mount squashfs _without_ some unique new cheatcode?

2. Are you tracking what Ruymbeke is doing in regard to minirt.gz mods for 6.7?
There is a very recent thread to that effect elsewhere on these forums.

Cheers.

1. No, not at all. That initial trymount is for the basic file system, it has nothing to do with the later aufs-mounting of files from that file system. Besides, that mounting currently applies only to file systems, not files. Think it is very special to create a squashfs file system on some writable drive.. But it is surely possible to make all sorts of modifications to init - it's only question of why.

2. I haven't looked into Ryumbeke's modifications so far, but I'm going to do it some time. As far as I have understood, it's not so much about squashfs, which has been the main concern for several of us. It doesn't seem that he aims at something that might get included in stadard init either, but I don't know for sure. As for myself, I don't need more than that minimal set of modifications right now. And I am using the same kernel and minirt for full HD installs and compressed images.

utu
08-06-2011, 09:11 PM
.
I am embarrased to admit that I've got Chromium working with flash, after all.
Not being familiar with its symbology, I missed the clue that 'some plug-ins are blocked'.
Look for a little icon with a red 'x' in the address bar at the top.

Even so, I prefer Firefox-5 1st, IceWeasel-3.6 2nd and Chromium 3rd.

My bad. I don't know why the default is to block the built-in capability.

kl522
08-07-2011, 05:33 AM
Is knoppix V6.7.0 more usable inside virtualbox compared to 6.4.4 ? Does it still need the 'noudev', after that mouse is not working ?

klaus2008
08-07-2011, 08:34 AM
On my system (Oracle VirtualBox 4.0.12 on Windows 7 host) it is not necessary to use the cheat code 'noudev' but it takes about 3 minutes until the LXDE is ready to use.

utu
08-07-2011, 12:01 PM
(Not in response to Virtual Box context)

In 6.4.4, I used 'fromhd=/dev/sb1' or similar and it seemed to speed up
finding my knoppix LiveUSB.

I can't complain about 6.7 being slower to load thant 6.4.4 since the
network manager 50 second hangup I used to complain about is now gone.

However, it looks like 'fromhd...' is pretty much ignored in 6.7 , at least initially.
I would guess this now would only make a second or two difference,
so why bother(?)

Is this obvious from those who read the init of the new minirt.gz?

kl522
08-07-2011, 12:47 PM
On my system (Oracle VirtualBox 4.0.12 on Windows 7 host) it is not necessary to use the cheat code 'noudev' but it takes about 3 minutes until the LXDE is ready to use.
Ok then I will try to download it tomorrow and give it a shot. Thanks.

utu
08-07-2011, 06:37 PM
Found this note concerning 6.7

http://www.knopper.net/knoppix/knoppix67-en.html

knopper
08-07-2011, 10:03 PM
Greetings Werner & kl522

I've got my new Knoppix 6.7 LiveUSB running.
Kernel is 2.6.39.3 #21; desktop background is new; Chromium replaces IceWeasel.
adriane not on menu, but lots of /user/bin/adriane components.
mis-behaving aumixer applet on my install. Flash not working for my Chromium; is for IceWeasel.
otherwise much like old-faithful 6.4.4. Was hoping for a built-in re-mastering option.
CD version really fills a CD with 730.7 Mb.

It fits on a standard 700 MB CD-R (which may contain up to 737280 bytes). Flash should work OK if installed via the flashplugin-nonfree Debian package, though you have to enable the plugin in Chromium on a per-page base (click on the icon in the address bar).

utu
08-07-2011, 10:59 PM
Greetings, Herr Knopper.

I've discovered most of what I didn't know at first about Knoppix 6.7.
It is really a nice distro, and even an improvement over 6.4.4.
It is the only distro that anticipates (both) my laptop's display & wifi.

I do have some second thoughts, however:
1..Chromium seems like a backward step, relative fo Firefox 5.
2..It would be nice if there were a LibreOffice Lite, that just gave us
...calc and write, say for 2/3 the Mbs of the all-up suite.
3..I'd like to see a remastering menu item ala PCLinuxOS that would
facilitate remastering for the intellectually challenged.

Best Regards.

knopper
08-07-2011, 11:29 PM
Greetings, Herr Knopper.

I've discovered most of what I didn't know at first about Knoppix 6.7.
It is really a nice distro, and even an improvement over 6.4.4.
It is the only distro that anticipates (both) my laptop's display & wifi.

I do have some second thoughts, however:
1..Chromium seems like a backward step, relative fo Firefox 5.


May I know why you think so?



2..It would be nice if there were a LibreOffice Lite, that just gave us
...calc and write, say for 2/3 the Mbs of the all-up suite.


I may have to do this sooner or later, since space is tight on the CD.
However, it will not save too much space, since the largest part is the Libreoffice core.



3..I'd like to see a remastering menu item ala PCLinuxOS that would
facilitate remastering for the intellectually challenged.

Best Regards.

What should a remastering menu do, exactly?

Just adding your own packages should be fairly easy, using the overlay feature in an USB installation. Rebuilding the compressed part, on the other hand, is surely not a beginners task, and I don't think this can be done easily with just a few clicks.

Regards
-Klaus

kl522
08-08-2011, 02:22 AM
May I know why you think so?
Regards
-Klaus

Welcome to Knoppix forum. I am particular amused by Klaus Knopper coming to this forum who is registered since 2002 but the status is a junior member. This forum is particularly hostile to new comers due to anti-spamming measures.

utu
08-08-2011, 02:47 AM
Greetings again, Klaus

In regards my comment on Chromium being a step backward:
I am used to tailoring font types & sizes and deleting underlines to suit my
own taste as one can do with Firefox & related browsers. This feature is
diminished in Chromium. Chromium has the feel of a browser for a netbook.
Firefox 5 has a very elegant feel to it by comparison, better suited I think
to a laptop.

In regard to LibreOffice, it seems to me that in earlier versions of
OpenOffice that there were stand-alone packages for write & calc, possibly
other elements. The current arrangement with LibreOffice as you know,
cannot be slimmed down much by unloading unused elements. The option to use
some earlier versions would suit my needs. I've been using this LibreOffice/
OpenOffice since it was called StarOffice.

I've been using the overlay feature, if I recall, since 6.2.1 and it continues
to serve me well. My niche has been 2 Gb SanDisk LiveUSBs. I've resisted
remastering new compressed images up until now for lack of Gigabytes and for
resistance against the complexity . I've just solved the storage restriction.

A menu feature in PCLinuxOS called 'mylivecd' purports to do all the hard work
of making a new compressed image. Presumably one uses Synaptic to add &
remove program elements from a live system and then points mylivecd to an
appropriately large area in which to prepare a compressed image (iso).
This iso is usually first tested in a VirtualBox or VMWare Player before
making an actual LiveCD or LiveUSB. Uses a lot of Drake processes.

Werner Schulz, on this forum, has a similar approach requiring, as you say
more than just beginner's talents to accomplish. In my case, I know what
I want to accomplish, but I want some automation to make it happen.

Very nice to have you join our forum. I hope you'll check in on us more often.

Best regards.

kl522
08-08-2011, 04:26 AM
On my system (Oracle VirtualBox 4.0.12 on Windows 7 host) it is not necessary to use the cheat code 'noudev' but it takes about 3 minutes until the LXDE is ready to use.

Had the same problem Knoppix 6.7 ( and Knoppix 6.4.4 ) when using Oracle VirtualBox 4.1.0 on a Linux host ( my custom version of Knoppix ). Without the cheatcode is just hang at udev thing and stuck forever. Putting in noudev cheatcode could get pass the booting and graphical windows started but there is no mouse, a virtual keyboard appeared. It's closed to impossible to menu around the system without the mouse.

kl522
08-08-2011, 04:48 AM
There are many similar reports on the internet. Likely is not udev problem per se but rather it is stuck at trying to figure out the display. Might be a problem specific to Linux host, as it was also reported that it works on a Windows host.

knopper
08-08-2011, 08:17 AM
Greetings again, Klaus

In regards my comment on Chromium being a step backward:
I am used to tailoring font types & sizes and deleting underlines to suit my
own taste as one can do with Firefox & related browsers. This feature is
diminished in Chromium. Chromium has the feel of a browser for a netbook.
Firefox 5 has a very elegant feel to it by comparison, better suited I think
to a laptop.


Ok, though I had the opposite impression, chromium being very elegant and slim, with focus on the "content" part which fills over 90% of the screen, and no unnecessary buttons or status bars, the latter ones being replaced by small on-screen status messages. The impression I had of chromiums look&feel plus rendering speed may be related to the fact that I do use mostly small netbooks for everyday work, rather than large screens. The font setting does not look too much different to me than the one in firefox, and many options not in the settings menu, can be set via gconf instead.

One problem I noticed is the missing support for the graphical screenreader orca.



In regard to LibreOffice, it seems to me that in earlier versions of
OpenOffice that there were stand-alone packages for write & calc, possibly
other elements. The current arrangement with LibreOffice as you know,
cannot be slimmed down much by unloading unused elements. The option to use
some earlier versions would suit my needs. I've been using this LibreOffice/
OpenOffice since it was called StarOffice.

I've been using the overlay feature, if I recall, since 6.2.1 and it continues
to serve me well. My niche has been 2 Gb SanDisk LiveUSBs. I've resisted
remastering new compressed images up until now for lack of Gigabytes and for
resistance against the complexity . I've just solved the storage restriction.

A menu feature in PCLinuxOS called 'mylivecd' purports to do all the hard work
of making a new compressed image. Presumably one uses Synaptic to add &
remove program elements from a live system and then points mylivecd to an
appropriately large area in which to prepare a compressed image (iso).
This iso is usually first tested in a VirtualBox or VMWare Player before
making an actual LiveCD or LiveUSB. Uses a lot of Drake processes.


I use a quite complex Makefile for this procedure, but you still need to know how to properly install or remove packages in Debian in order to rebuild the compressed image. I would tend to see advanced filesystem tree knowledge as requirement for successfully building a compressed file system, and don't trust automatic tools too much. But then, that's just my opinion. If you can write a script suitable for beginners, that does everything automatically, I can schedule it for inclusion. :-)



Werner Schulz, on this forum, has a similar approach requiring, as you say
more than just beginner's talents to accomplish. In my case, I know what
I want to accomplish, but I want some automation to make it happen.


Still, someone has to write and package the automatism in a way that makes it difficult to break something seriously, by accident.



Very nice to have you join our forum. I hope you'll check in on us more often.
Best regards.


It's a matter of time resources. Unfortunately, I don't have as much as I should, but I always try to answer the most urgent questions.

Regards
-Klaus

Capricorny
08-08-2011, 11:42 AM
I use a quite complex Makefile for this procedure, but you still need to know how to properly install or remove packages in Debian in order to rebuild the compressed image. I would tend to see advanced filesystem tree knowledge as requirement for successfully building a compressed file system, and don't trust automatic tools too much. But then, that's just my opinion. If you can write a script suitable for beginners, that does everything automatically, I can schedule it for inclusion. :-)
....

Still, someone has to write and package the automatism in a way that makes it difficult to break something seriously, by accident.
....

It's a matter of time resources. Unfortunately, I don't have as much as I should, but I always try to answer the most urgent questions.

-Klaus

Klaus,
To take the last point first: I for one is very thankful for your extremely useful work, regardless of support level. It is of course very nice when you can take time to answer questions and discuss, but for me, the Knoppix releases are what really matters.

Remastering script: I and others are using kind of "poor man's remastering", and it seems to work well - at least I'm running these multiple remasterings on a daily basis. The different operations are gathered in a rather simple script, the original version posted by Forester here.
First, and most important step:

1. Copy most of /UNIONFS to a remastering directory, but use only the "stubs" of /var and /home from original KNOPPIX image.
2. Create compressed file system (Seems that we tend to prefer squashfs here, but cloop is also used.)
3. Create new persistent image, copy over /home and /var.
4. Test run the new version, e.g. in qemu.

Only after extensive testing, I think the second step, creating a new ISO image, should be carried out.
The two scripts carrying out those steps would not necessarily need much competence to run, would they? and, rather than trying to be all things to all people. it could be rather picky about some details to maximize the chances of success. (Like 0wn requires reiserfs, for example)

utu
08-09-2011, 01:13 AM
@ Capricorny

I would like to encourage you to take Klaus up on his offer in his post #29
to present him with 'the automation' to make 'poor-man's re-mastering'
a menu item in some later Knoppix release.

One way to do this might be first to lay out a proof of principle that others
on this forum might emulate and/or suggest improvements to. You've probably
done this already, and only need to collect all your notes, and Forester's
as well if they are relevant, in one place.

It may be more likely to succeed earlier, as a Knoppix refinement, if squashfs
vs cloop differences were left to be suggested as a subsequent refinement
of the basic idea.

I know you also have an avenue to address this on the debian-knoppix mailing list.
I wish you good luck in this however you choose to proceed.

Capricorny
08-09-2011, 07:06 AM
@ Capricorny

I would like to encourage you to take Klaus up on his offer in his post #29
to present him with 'the automation' to make 'poor-man's re-mastering'
a menu item in some later Knoppix release.

One way to do this might be first to lay out a proof of principle that others
on this forum might emulate and/or suggest improvements to. You've probably
done this already, and only need to collect all your notes, and Forester's
as well if they are relevant, in one place.

It may be more likely to succeed earlier, as a Knoppix refinement, if squashfs
vs cloop differences were left to be suggested as a subsequent refinement
of the basic idea.

I know you also have an avenue to address this on the debian-knoppix mailing list.
I wish you good luck in this however you choose to proceed.

I will try to carry out something in the direction of this very good suggestion.
While the use of cloop vs squashfs is not peripheral in principle, it surely is peripheral in this context, as ordinary users don't need to be aware of such issues at all.

Furthermore, here on this forum we can see that there is a certain demand for remastering - the reasons may not always be that good, but if it can be done easily, then why not?

One important reason to make it simple, is that it will be easier to ask people to upgrade to newer Knoppix versions - older versions are very often the reasons for trouble, and having made a customization will often be an important reason not to upgrade.

There are some compromizes to be made, I think. Just updating the compressed and persistent images should really be a separate step, for testing before a new ISO image is made, but for the utmost ease for the user, a new ISO image is the best end point. That can be very easily tested, and handled with minimum knowledge of file systems etc.

Making an ISO image means, among other things, that the package database gets written to the ISO, and that extra content in /home may get lost if the users don't take the newly generated persistent image along. For several reasons, among them privacy, I will NOT write the whole of user's /home to the ISO! ;-)

Also, even if it is somewhat less efficient, I think making a separate loop-mounted image for the interim file handling during remastering is best. We can foresee many users running off NTFS, and for them, a new ISO file being the only thing left on the NTFS file system afterwards would be the safest and least intrusive option.

utu
08-09-2011, 04:12 PM
While the use of cloop vs squashfs is not peripheral in principle, it surely is peripheral in this context, as ordinary users don't need to be aware of such issues at all.

My suggestion is to avoid the possibility that KK may have his own preferences re squashfs vs cloop.
If so, it might be better to handle that issue later. I'm not offering any judgment as to that choice.
If that issue is truly essential, then disregard my caution, and by all means, bring it on.

Best Regards

Capricorny
08-10-2011, 11:50 AM
My suggestion is to avoid the possibility that KK may have his own preferences re squashfs vs cloop.
If so, it might be better to handle that issue later. I'm not offering any judgment as to that choice.
If that issue is truly essential, then disregard my caution, and by all means, bring it on.

It's surely not truly essential today, and even with pure 64 bits remastering, it turned out I might as well use cloop. The main reason we keep suggesting squashfs, is that there are some advantages, in particular when several modifications are done, and that support for squashfs can be added truly transparently to end users: Using cloop, you won't notice anything about squashfs until you extract minirt.gz and look at the init script.

And for end user tools like the remastering script we discuss, it is, as noted, of some value to deviate as little as possible from the starting point. When people create a new ISO, it should resemble the original one as much as possible.

utu
08-10-2011, 02:07 PM
@ Capricorny

I'm looking forward to your 'proof of priinciple' enterprise.
I addressed a few notes to you in that regard on Werner's other (Re-Mastering) thread.

Good Luck.

Capricorny
08-10-2011, 10:34 PM
OK, here's a quick and dirty, and not-that-well-debugged version of the basic poor man's remastering, which I just used for remastering 6.7.0 DVD (cloop version). I can guarantee that each single step works, but haven't had time to test the whole thing.
It takes 4 parameters:


Directory of remastering workspace
Size of workspace
Directory of remastered version
Size of new persistent store

All those may of course be skipped, and sensible defaults used.
Example: ./rem_02.sh /store/local 20000 /store/local/KNOPPIX670 4000

I'm running the remastered version under qemu right now, and it surely works. I see that I will get space problems with max 4GB compressed image, as the cloop is 3.6 GB after purging the obvious things and installing a few programs. Therefore, squashfs may be to prefer here.

Using cloop, space requirement is ca 2x uncompressed KNOPPIX image size, i.e. ca 18-20 GB for DVD version. Using squashfs, it's only 1x. Images are written directly to new KNOPPIX location, so space is needed for that too. I would not recommend writing directly to slow flash memory. Use some hard disk space if you can.



#!/bin/bash
# Based loosely on Foresters script on Knoppix-forum modified by tay 20110511-20110810


function to_exist() {
[ -d "$1" ] || sudo mkdir -p $1 ;
}

function purge_or_create() {
[ -d "$1" ] && sudo rm -rf $1
sudo mkdir -p $1 ;
}

function remaster_knoppix() {
command=$1; shift;
operand=$1; shift;

case "${command} ${operand}" in

"create workspace") # Setup workspace as loop image
workdir=$1; shift;
psize=$1; shift;
sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
sudo losetup /dev/loop7 ${workdir}/knoppix-remaster-data.img
sudo mkfs.ext3 /dev/loop7
sudo losetup -d /dev/loop7
purge_or_create /tmp/knx-remaster-data;
sudo mount ${workdir}/knoppix-remaster-data.img /tmp/knx-remaster-data -o loop=/dev/loop7 ;
;;


"copy live-system") # This is the simplified copy
to_exist /tmp/knx-remaster-data/knx_source ;
# Copy main /UNIONFS
sudo rsync -ax --delete --exclude=home --exclude=lost+found --exclude=var /UNIONFS/ /tmp/knx-remaster-data/knx_source;
# Use a couple of directories/files from KNOPPIX as stubs
sudo rsync -ax /KNOPPIX/home /KNOPPIX/var /tmp/knx-remaster-data/knx_source;
sudo rsync -ax /KNOPPIX/etc/fstab /tmp/knx-remaster-data/knx_source/etc;
;;


"make isofs") # We don't use pipe here
purge_or_create /tmp/knx-remaster-data/knx_tmpiso ;
sudo chmod a+rwx /tmp/knx-remaster-data/knx_tmpiso;
sudo mkisofs -R -U -V "KNOPPIX.net filesystem" -publisher "KNOPPIX www.knoppix.net" -hide-rr-moved -cache-inodes -pad /tmp/knx-remaster-data/knx_source > /tmp/knx-remaster-data/knx_tmpiso/knoppix.iso ;
;;

"compress isofs") # Not optimized cloop compression
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
sudo create_compressed_fs -B 65536 /tmp/knx-remaster-data/knx_tmpiso/knoppix.iso $newknoppix_dir/KNOPPIX;
;;

"make squashfs")
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
sudo mksquashfs /tmp/knx-remaster-data/knx_source $newknoppix_dir/KNOPPIX.sq -b 262144 -noappend ;
;;

"loopcreate persistent") # Create new persistent image, size in MB must be given.
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
psize=$1; shift;
sudo dd if=/dev/zero of=${newknoppix_dir}/knoppix-data.img bs=1M count=$psize
sudo losetup /dev/loop6 ${newknoppix_dir}/knoppix-data.img
sudo mkfs.ext3 /dev/loop6
sudo losetup -d /dev/loop6
purge_or_create /tmp/knx-data
sudo mount ${newknoppix_dir}/knoppix-data.img /tmp/knx-data -o loop=/dev/loop6 ;
sudo rsync -ax --delete /UNIONFS/home /UNIONFS/var /tmp/knx-data ;
sudo umount /tmp/knx-data;
;;

"purge workspace")
sudo umount /tmp/knx-remaster-data
sudo losetup -d /dev/loop7
workdir=$1; shift;
sudo rm -f ${workdir}/knoppix-remaster-data.img
;;

*)
echo oops;
;;

esac


}

# example: ./rem_02.sh /store/local 20000 /store/local/KNOPPIX670 4000
wrkspc_dir=$1 ; wrkspc_sz=$2 ; remaster_dir=$3 ; persist_sz=$4 ;
remaster_knoppix create workspace ${wrkspc_dir} ${wrkspc_sz}
remaster_knoppix copy live-system
# remaster_knoppix make isofs
# remaster_knoppix compress isofs ${remaster_dir}
remaster_knoppix make squashfs ${remaster_dir}
remaster_knoppix loopcreate persistent ${remaster_dir} ${persist_sz}
remaster_knoppix purge workspace

utu
08-10-2011, 10:53 PM
@ Capricorny

Excellent effort.
I think I can recall dinosoep correcting Forester's 'make isofs' chmod with chown.
Wouldn't that still apply here?
Also, seemed like Forester had some useful notes regarding the filesystems used.

Hope you don't mind the comments; trying to help.

Cheers

Capricorny
08-10-2011, 11:10 PM
@ Capricorny

Excellent effort.
I think I can recall dinosoep correcting Forester's 'make isofs' chmod with chown.
Wouldn't that still apply here?
Also, seemed like Forester had some useful notes regarding the filesystems used.

Hope you don't mind the comments; trying to help.

Cheers
That temporary iso-directory may have whatever properties it will for me, as long as I can use it for making a compressed image, and I can.
File systems: You need something allowing the necessary file system sizes for remastering. But as only one (temporary) file is created on the native file system, it can be NTFS or one of the Linux file systems. You can use FAT32 for the directory (drive) to write the remastered versions to. Like Knoppix in general, this is rather file system agnostic.

IMHO, not using a poor man's install on a hard drive (internal or external) for such enterprises is rather masochistic ;-)

utu
08-11-2011, 12:56 AM
@ Capricorny:

Let's see if I have this right:

0. What I shall call my working LiveUSB is one with persistent store which
has accumulated additions and 'deletions' of program material. I wish to modify
its original LiveUSB compressed image to embody all these accumulated
changes into a new LiveUSB compressed image and to provide a new 'empty'
persistence file for future temporary changes.

1. For these purposes, I need to add to my currently working LiveUSB a small
remastering script; I don't need to re-do the minirt.gz of the LiveUSB for this
version of remastering.

2. My LiveUSB is on /dev/sdb1; I have some external storage on /dev/sdc1,
exceeding 25 Gb or so which I mount as /store/local. It may be ext, fat, or ntsf:
it doesn't matter as far as the remastering goes.

This model of re-mastering separates (1) the development of useful modifications
by adding and removing program material from (2) the process of revising the
compressed image and the persistence file. With suitable safeguards, it is
hoped this might serve as a menu choice item in some future version of Knoppix.

Corrections or modifications welcome.

Capricorny
08-11-2011, 01:09 AM
@ Capricorny:

Let's see if I have this right:

0. What I shall call my working LiveUSB is one with persistent store which
has accumulated additions and 'deletions' of program material. I wish to modify
its original LiveUSB compressed image to embody all these accumulated
changes into a new LiveUSB compressed image and to provide a new 'empty'
persistence file for future temporary changes.

1. For these purposes, I need to add to my currently working LiveUSB a small
remastering script; I don't need to re-do the minirt.gz of the LiveUSB for this
version of remastering.

2. My LiveUSB is on /dev/sdb1; I have some external storage on /dev/sdc1,
exceeding 25 Gb or so which I mount as /store/local. It may be ext, fat, or ntsf:
it doesn't matter as far as the remastering goes.

This model of re-mastering separates (1) the development of useful modifications
by adding and removing program material from (2) the process of revising the
compressed image and the persistence file. With suitable safeguards, it is
hoped this might serve as a menu choice item in some future version of Knoppix.

Corrections or modifications welcome.

Re 2: The remastering storage must be able to accomodate files >4GB for realistic remastering work..

utu
08-11-2011, 01:24 AM
Help me out here.
What filesystems have this property.

kl522
08-11-2011, 02:36 AM
@ Capricorny:

Let's see if I have this right:

0. What I shall call my working LiveUSB is one with persistent store which
has accumulated additions and 'deletions' of program material. I wish to modify
its original LiveUSB compressed image to embody all these accumulated
changes into a new LiveUSB compressed image and to provide a new 'empty'
persistence file for future temporary changes.


That's the main spirit of flash re-master. Because the changes to the said LiveUSB with persistent store are accumulated, which means it has withstood the time test. If one were to re-master using a chroot, one will probably test it for at most a few hours. The user experience of testing using chroot is not as close resemblance to the final outcome, especially with regards to the graphic user inteface. Once remastered, there is a clean separation to allow one move on to experiment with new changes.

Werner P. Schulz
08-11-2011, 09:25 AM
The user experience of testing using chroot is not as close resemblance to the final outcome, especially with regards to the graphic user inteface.... within the chroot you can also test GUI-tools (starting from commandline) as root and as user knoppix.

You can test your remastered ISO as extensive you like and as long you need - days, weeks, months. And if you want to change something, enter chroot, make your modifications in '/opt/knx/remaster'. That's all!


Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

Capricorny
08-11-2011, 09:39 AM
... within the chroot you can also test GUI-tools (starting from commandline) as root and as user knoppix.

You can test your remastered ISO as extensive you like and as long you need - days, weeks, months. And if you want to change something, enter chroot, make your modifications in '/opt/knx/remaster'. That's all!


Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

Sure, but exactly what kind of modification is it that we can't do with a poor man's install instead? Exactly what is the great advantage of going all the way to the ISO, as compared to making new cloop and persistent images? I have found a poor man's install (PMI) to be very, very similar to a full HD install, and in fact I much prefer the PMI. And such an install can be run and modified in a VM, just like the ISO, only simpler and more thoroughly, IMHO, as I just add grub entries and can modify kernels and minirt, with modifications only in the /boot directory which grub uses.

It's not that chroot and all that stuff doesn't work - I just can't get what is the advantage of using it with present day hardware and technology.

Capricorny
08-11-2011, 09:50 AM
Help me out here.
What filesystems have this property.
Knoppix supported: NTFS, ext2/3/4,reiserfs among others. You really need more?
I am careful making generalizations, as all sorts of (for me) exotic file systems are in use nowadays.
I realize that there should really be a FAT48 KISS file system alternative, to accomodate larger files in very simple use situations like this. (All the complexity is hidden in the file systems in the loop images, and mounts thereof.)

kl522
08-11-2011, 11:08 AM
.
You can test your remastered ISO as extensive you like and as long you need - days, weeks, months. And if you want to change something, enter chroot, make your modifications in '/opt/knx/remaster'. That's all!


You just pointed out the weakness of 'chroot' testing. Yes, you can test as long as you want, but will one do it ? For sure I will not, because the testing is an additional work. Whereas flash install, the testing is implied in your everyday use. It is not an additional piece of work.

Capricorny
08-11-2011, 01:44 PM
Just a small remark re compressed sizes for 6.7.0.

With games, German help, some internationalization, icedove&kmail, abiword, lyx, ekiga, gnucash, epiphany and kdewallpapers purged, and R, Octave and some other math packages installed, and updated /var on the persistent image, we might call that a fully functional, trimmed, install.

Uncompressed system size then became 8.2 GB, unoptimized cloop-compressed 3.46, squash-compressed 3.26GB. Which means there may be installed 2-2.5GB more programs before 4GB is exceeded. Also with the fast compression options, squashfs gives us about 500MB more room.

Some 800MB is occupied on the persistent store, the largest part is Debian package-related information.

And there is no problem fitting the whole thing, with a 3+ GB persistent image, on an 8GB thumbdrive or SD-card.

What seemed a bit strange, was that about 300 MB of packages on this new release were upgraded when I ran aptitude upgrade. Surely, it can be good practice to run upgrade before remastering - I have now a better updated system than the 6.7.0 ISO.

utu
08-11-2011, 06:00 PM
@ Capricorny, kl522, Werner P.

I think we may achieve better progress by sorting out the different
dimensions of the 're-mastering problem'.

1. The problem of deciding what constitutes the best CONFIGURATION of the
end product: what's in & what's out; iso vs whatever; 32-bits vs 64.
....There are several ways to come at this and I don't see a clear winner here.
I suggest whatever works, do it. Like religion, don't insist yours is the
only answer. I'm aware of at least two approaches other than my own that have
been argued here.
....My method is to be always experimenting with my LiveUSB; I occasionally
make a simple tgz image of my persistent file. If or when I break my system
I haul out the tgz image and reset things using current Knoppix 6 built-in
capabilities. Works for me, but I don't insist anyone else has to like it.

2. The problems of RESETTING the compressed image and the persistent store,
and TESTING the end product.
....There are several ways to come at this as well. I personally would favor
an initial solution that seems to be only a small addition to the current
Knoppix, and holding off arguable refinements for subsequent further gradual
improvements.
....I personally would be satisfied with an initial solution to problem 2
that could be achieved without bringing in any new side issues, if they are
avoidable. For example, I gather that remastering a DVD may necessitate dealing
with 4 Gb filesizes, which may necessitate dealing with 64 bit solutions.
In which case, I'd be happy for an initial CD-only solution, if that post-
poned the necessity to solve these collateral issues . This initial
CD-only solution would be a good advertisement for additional heads to help
work this problem.
....Even in this CD-only case, testing the end product deserves special
attention. Making CD's to see if everything works is not the answer.
For me, Virtual set-ups on Windows is not the answer, either.

utu
08-11-2011, 06:35 PM
@ Capricorny

Several questions for you, relative to your remastering script in post #36

1. Does this script require any modification to the standard Knoppix 6.7 kernel or minirt.gz?
2. Are ext and ntfs the most reasonable choices for /store/local?
3. Is 64-bit configuration necessary to get around a 4 Gb filesize limitation with either ext or ntfs?
4. Should I concern myself with any difference between linux's ntfs-3g and Microsoft's ntfs?

Thanks.

Capricorny
08-11-2011, 08:00 PM
@ Capricorny

Several questions for you, relative to your remastering script in post #36

1. Does this script require any modification to the standard Knoppix 6.7 kernel or minirt.gz?
2. Are ext and ntfs the most reasonable choices for /store/local?
3. Is 64-bit configuration necessary to get around a 4 Gb filesize limitation with either ext or ntfs?
4. Should I concern myself with any difference between linux's ntfs-3g and Microsoft's ntfs?

Thanks.

1. No
2. No, what is most reasonable depends on your use. NTFS is surely most practical if a Windows partition or two is all you have got.
3. No
4. No, not as far as I know. But as mentioned, try to avoid complicated things with NTFS.

If you give an existing working KNOPPIX directory as target for the script, KNOPPIX and knoppix-data.img will be updated, Knoppix will run as before.

I'm going to modify the script a little bit to make it more robust, and there was at least one parameter omission in the last step. But, basically, it's working.

Capricorny
08-11-2011, 08:12 PM
@utu: Who needs to decide what is the best configuration of the end product?
I have some clear viewpoints about it, but they are surely not the only answer.
I'd rather spend time developing and trying out solutions than discussing.

With a script like I presented, you can remaster every day if you like.
And it can rather easily be complemented with an iso-creating step. The only real modification for ISO is writing the whole (or most of) /var directory
to the compressed image instead of to persistent.
Personally, I think package administration tools and testing methods are of much greater practical significance.

utu
08-11-2011, 09:13 PM
@ Capricorny

Would it be correct to say at the conclusion of your script
that there exists the content of a poor-man's install image on the workspace?

If so, then it would seem there is a lot of choice at this point
as to how to test the product-so-far. For examples:
(a) do a virtual install;
(b) do an actual install in, or adjacent to the workspace; or
(c) create and iso from which to burn a LiveCD or LiveUSB.

Capricorny
08-12-2011, 02:47 AM
@ Capricorny

Would it be correct to say at the conclusion of your script
that there exists the content of a poor-man's install image on the workspace?

If so, then it would seem there is a lot of choice at this point
as to how to test the product-so-far. For examples:
(a) do a virtual install;
(b) do an actual install in, or adjacent to the workspace; or
(c) create and iso from which to burn a LiveCD or LiveUSB.

No, there's more choice than that.

You could start up from the DVD or ISO, do a series of purges and installs, make some adaptations (like you would in a chroot environment), and then run the script to make a remastering which may then serve as your PMI. It could easily be expanded into copy-to-flash-with-remastering too.

I am not sure how useful the concepts "install" and "workspace" are in this respect.

1. Standard PMI is just copying the KNOPPIX directory into a root directory somewhere. Knoppix will find it even without being told where it is. How is that for an "install"?

2. You may just use the existing NTFS or Linux partitions. Using a non-FAT32 partition with 20+ GB free space, you can run remastering from there, it will be mounted on /mnt-system. How is that for a "workspace"? In fact if you have a dual boot system, you may want to drop KNOPPIX onto a NTFS partition, to avoid any unwanted interaction with other Linuxes, and/or keep the Knoppix system stuff properly separated from other data.

Capricorny
08-12-2011, 10:49 AM
Filling up towards 4GB, there's still ca 250 MB size difference between unoptimized cloop and squashfs images. Creating a 4GB cloop image + persistent store took about 40 minutes on an ASUS N53S core I7-2630QM, using external USB3 harddisk (1TB WD Passport with ext4 fs.)
Using squashfs, it took 25-30 minutes.

The image I made might be representative for one kind of customization. Main additions are:


R with a large selection of packages
Octave, with lots of extra packages
Axiom
Scilab
Bibble 5.2.2 Pro
Oracle XE 10g
VMware Workstation 7.1.4 (Must manually patch module code for 2.6.38+ kernels!)
Plus a few tools, like Jython, bison, flex

I think it is hard to trim down 6.7.0 DVD to make room for large additions - I had to purge chromium and a few doc packages this time.

I will leave 32-bits 6.7.0 here for now, and concentrate on a 64-bits version. I don't bother to post a new "uni init" for cloop and squashfs for 6.7.0, editing steps can be gathered from the diff. The most important steps are to substitute the mountknoppix function + change /dev/loop0 references. Probably not as I did to /dev/loop8, as busybox seems to stick with old kernel conventions in that respect. But maybe to /dev/loop7.

Here's the updated script - with squashfs and cloop packages installed, it works for me. I'm writing this from a freshly remastered version.



#!/bin/bash
# Based loosely on Foresters script on Knoppix-forum modified by tay 20110511-20110810


function to_exist() {
[ -d "$1" ] || sudo mkdir -p $1 ;
}

function purge_or_create() {
[ -d "$1" ] && sudo rm -rf $1
sudo mkdir -p $1 ;
}

function remaster_knoppix() {
command=$1; shift;
operand=$1; shift;

case "${command} ${operand}" in

"create workspace") # Setup workspace as loop image
workdir=$1; shift;
psize=$1; shift;
sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
sudo losetup /dev/loop7 ${workdir}/knoppix-remaster-data.img
sudo mkfs.ext3 /dev/loop7
sudo losetup -d /dev/loop7
purge_or_create /tmp/knx-remaster-data;
sudo mount ${workdir}/knoppix-remaster-data.img /tmp/knx-remaster-data -o loop=/dev/loop7 ;
;;


"copy live-system") # This is the simplified copy
to_exist /tmp/knx-remaster-data/knx_source ;
# Copy main /UNIONFS
sudo rsync -ax --exclude=home --exclude=lost+found --exclude=var /UNIONFS/ /tmp/knx-remaster-data/knx_source;
# Use a couple of directories/files from KNOPPIX as stubs
sudo rsync -ax /KNOPPIX/home /KNOPPIX/var /tmp/knx-remaster-data/knx_source;
sudo rsync -ax /KNOPPIX/etc/fstab /tmp/knx-remaster-data/knx_source/etc;
;;


"make isofs") # We don't use pipe here
purge_or_create /tmp/knx-remaster-data/knx_tmpiso ;
sudo chmod a+rwx /tmp/knx-remaster-data/knx_tmpiso;
sudo mkisofs -R -U -V "KNOPPIX.net filesystem" -publisher "KNOPPIX www.knoppix.net" -hide-rr-moved -cache-inodes -pad /tmp/knx-remaster-data/knx_source > /tmp/knx-remaster-data/knx_tmpiso/knoppix.iso ;
;;

"compress isofs") # Not optimized cloop compression
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
sudo create_compressed_fs -B 65536 /tmp/knx-remaster-data/knx_tmpiso/knoppix.iso $newknoppix_dir/KNOPPIX;
;;

"make squashfs")
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
sudo mksquashfs /tmp/knx-remaster-data/knx_source $newknoppix_dir/KNOPPIX.sq -b 262144 -noappend ;
;;

"loopcreate persistent") # Create new persistent image, size in MB must be given.
newknoppix_dir=$1; shift;
to_exist ${newknoppix_dir}
psize=$1; shift;
sudo dd if=/dev/zero of=${newknoppix_dir}/knoppix-data.img bs=1M count=$psize
sudo losetup /dev/loop6 ${newknoppix_dir}/knoppix-data.img
sudo mkfs.ext3 /dev/loop6
purge_or_create /tmp/knx-data
sudo mount -t ext3 -rw -o loop /dev/loop6 /tmp/knx-data ;
sudo rsync -ax /UNIONFS/home /UNIONFS/var /tmp/knx-data ;
sudo umount /tmp/knx-data;
sudo losetup -d /dev/loop6
;;

"purge workspace")
sudo umount /tmp/knx-remaster-data
sudo losetup -d /dev/loop7
workdir=$1; shift;
sudo rm -f ${workdir}/knoppix-remaster-data.img
;;

*)
echo oops;
;;

esac


}

# Calling examples:
#./rem_02.sh /mnt-system/store/local 25000 /mnt-system/store/KNOPPIX670 4000
#./rem_02.sh /mnt-system/store/local 12000 /mnt-system/store/KNOPPIX670 4000
#./rem_02.sh /media/sda2/store/local 10000 /media/sda2/store/local/KNOPPIX670 4000
# ./rem_02.sh /store/local 20000 /store/local/KNOPPIX670 4000

wrkspc_dir=$1 ; wrkspc_sz=$2 ; remaster_dir=$3 ; persist_sz=$4 ;
remaster_knoppix create workspace ${wrkspc_dir} ${wrkspc_sz}
remaster_knoppix copy live-system
remaster_knoppix make isofs
remaster_knoppix compress isofs ${remaster_dir}
# remaster_knoppix make squashfs ${remaster_dir}
remaster_knoppix loopcreate persistent ${remaster_dir} ${persist_sz}
remaster_knoppix purge workspace ${wrkspc_dir}

utu
08-12-2011, 03:53 PM
I don't bother to post a new "uni init" for cloop and squashfs for 6.7.0, editing steps can be gathered from the diff. The most important steps are to substitute the mountknoppix function + change /dev/loop0 references. Probably not as I did to /dev/loop8, as busybox seems to stick with old kernel conventions in that respect. But maybe to /dev/loop7.

So, does this mean YES, I have to redo minirt.gz?

Capricorny
08-12-2011, 09:26 PM
Utu,
can't you just try out things?
When do you think patching minirt is necessary? I answered NO when you asked. If you want to use squashfs, yes you have to patch 6.7.0 init. And if you want to run a purely 64-bit version. And for uncountable other special modificatons. But for ordinary cloop remastering: No. In the script, squashfs creation is commented out. It makes only cloops as it stands.

"Uni init" means that the same script can be used with cloop and squashfs, a cheatcode tells which to use.

Werner P. Schulz
08-14-2011, 09:36 AM
I have found a poor man's install (PMI) to be very, very similar to a full HD install, and in fact I much prefer the PMI. And such an install can be run and modified in a VM, just like the ISO, only simpler and more thoroughly, IMHO, as I just add grub entries and can modify kernels and minirt, with modifications only in the /boot directory which grub uses.... not yet mentioned: I in reality do all my testing and modifications of Knoppix within the HD-Installation, not with a Flash disk Installation of a remastered ISO.

All the things I install, purge, change and so on within the HD-Installation I collect in a script. If all is as I need it and runs very well, I execute this collecting script in the chroot and then build a new ISO.

If Klaus Knopper offers a new Knoppix version, I only have to do little changes in this collecting script and a remastered ISO of new Knoppix version will be done with little efforts.

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

utu
08-14-2011, 10:25 PM
All the things I install, purge, change and so on within the HD-Installation I collect in a script. If all is as I need it and runs very well, I execute this collecting script in the chroot and then build a new ISO.

If Klaus Knopper offers a new Knoppix version, I only have to do little changes in this collecting script and a remastered ISO of new Knoppix version will be done with little efforts.

I do the stone age equivalent of this.
I keep a changelog to remind me what I've done to my LiveUSB since it was new.
It's a script of sorts that I follow to put back all my little changes.

I can usually get back on-line in a few minutes after a version change,
unless there's something new structurally.

Not very elegant, but it works for me.
Leaving /home out of re-mastering sure works against this method, however.

Cheers

utu
08-15-2011, 05:46 PM
@ Capricorny

I now have your script working sufficiently well that I think I can
express some opinions for discussion:

1. I think the initial workspace should be saved as a subsequent starting
point for successive re-mastering attempts, rather than re-inventing it from
scratch each time. I fully realize this will double the storage used and
necessitate a copying phase as well. I'm assuming copying is much faster
than establishing the initial workspace from scratch, of course.
....I expect some will be shocked at the heretofore 2 Gb byte-miser is now
so profligate; but now he owns an extra Terrabyte of ntsf storage.

2. The rsynch and subsequent print-out is excessive and should be trimmed
down to whatever might serve some useful purposes.

3. The current choices of what to keep are way to restrictive for my uses.
I suggest keeping all of /home except for the compressed KNOPPIX file
and knoppix-data.img. That's where a lot of my stuff is.

4. I suggest we leave to Knoppix to replace the persistence file, and not
do its work for it.

5. In my case /dev/loop7 isn't found and deleted as it should be in the
purge process.

6. I suspect that the remastered product may often be larger than where
it started even if programs are removed. This is not a tolerable end solution.
Its ok to get things sorted out, but that's got to come under control at some
point.

utu
08-16-2011, 03:17 PM
7. One has to make sure the KNOPPIX670 file from a previous
remaster is indeed 'gone', not just hidden as PCManFM does when
you think it's deleting files.
You need to look for hidden files and delete them.

kl522
08-16-2011, 08:01 PM
It is not surprising that when people re-master, expecially the very first one, they end up having an image bigger than the original. There can be many reasons to it, one of them is due to the commands used, 'create_compressed_fs'. The command has additional switches which selects better compression scheme ( at the expense of MUCH slower compression time ).

If one really wants to remaster for the last time, like what K Klaus does when he releases his liveCD, he probably selects '-L -1' or '-L -2', which incorporates 7zip compression. 7zip compression is famous for able to produce higher compression ratio but at the expense of MUCH longer compression time. Squashfs has its equivalent, and does it with EVEN higher compression ratio.

utu
08-16-2011, 08:15 PM
@ kl522

Thanks. I'll give that a try.

My initial try is just to re-do my cd.
More than half the time is spent in 'preparing the workspace'.
only about one-quarter spent in sub-optimum compression.

One quarter spent in copious, unused print-out, I haven't found
out how to cut down on yet. This in the rsync area and what follows.

Thanks for your hints.

utu
08-16-2011, 08:46 PM
@ kl522

ps
I now have the gigabyte wherewithal and enough background to delve into your 'Remaster your flash installation'.
I hope to be able to report some success with your approach sometime in the near future.
Cheers.

utu
08-17-2011, 12:47 AM
@ Capricorny

Regarding your script as shown in post #54:
Are your case descriptors missing a left paren on purpose?
Missing relative to Forester's script, that is.
Thanks.

kl522
08-17-2011, 01:01 AM
@ kl522
More than half the time is spent in 'preparing the workspace'.

Something I haven't tried it myself but I think it might be possible to shorten the time by changing the 'dd' command to a 'sparse file'. It allows the time to be shortened to almost nothing, at the expense of risking into having not enough disk space in the subsequent use. This can be mitigated by doing disk space calculation prior to starting.

Example of sparse file :-


$ dd of=sparse_file bs=1024 count=0 seek=1000K
This will create a 1G file in below 1 second.

utu
08-17-2011, 01:12 AM
@ kl522

Incredible. My 15 Gb file takes 10 MINUTES to build as it is.
Are we on the same page here?

utu
08-17-2011, 03:32 AM
@ kl522

Is this the replacement you are suggesting?

# sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
$dd of=sparse_file bs=1024 count=0 seek=1000K

kl522
08-17-2011, 03:52 AM
@ kl522

Is this the replacement you are suggesting?

# sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
$dd of=sparse_file bs=1024 count=0 seek=1000K

Change it to :-

dd of=${workdir}/knoppix-remaster-data.img bs=1M count=0 seek=$psize

That will use back the same arithmatic, creating the required workspace in a couple of seconds.

Cheers.

utu
08-17-2011, 03:27 PM
Using the following input,
./rem_05.sh /media/sdc1 15M /media/sdc1/KNOPPIX670&

and the single line of modification, shown here:
"create workspace") # Setup workspace as loop image
workdir=$1; shift;
psize=$1; shift;
# sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
$dd of=sparse_file bs=1024 count=0 seek=${wrkspc_sz} # replace line above per kl522
sudo losetup /dev/loop7 ${workdir}/knoppix-remaster-data.img
sudo mkfs.ext3 /dev/loop7
sudo losetup -d /dev/loop7
purge_or_create /tmp/knx-remaster-data;
sudo mount ${workdir}/knoppix-remaster-data.img /tmp/knx-remaster-data -o loop=/dev/loop7 ;
;;

We get a 'command not found' error for the new line, and nothing produced
except an empty KNOPPIX file at the end.

1. Also, I don't see how sparse_file and {workdir} ever get together; and
2. Shouldn't the case descriptors have a left-parenthesis?

utu
08-17-2011, 04:15 PM
It also looks to me like sparse_files or sparse-files are elements
that require ntfs-3g driver(s). Having started with a cd version
of Knoppix, my synaptic doesn't show ntfs-3g as an option.

utu
08-17-2011, 06:21 PM
Following up on kl522's suggestion concerning sparse-files, I can report that
this seems to be a very useful wrinkle on the re-mastering scene.

Here's the magic combination that worked for me:
(replace the first line with the second in the Forester/Capricorny setup workspace stanza)
# sudo dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1M count=$psize
dd if=/dev/zero of=${workdir}/knoppix-remaster-data.img bs=1 count=0 seek=${wrkspc_sz}

With the input command,
./rem_05.sh /media/sdc1 15G /media/sdc1/KNOPPIX670&
the time to prepare a 15 Gb workspace went from 10 minutes to 40 seconds.

In addition to kl522's suggestion, the following site was helpful:
http://prefetch.net/blog/index.php/2009/07/05/creating-sparse-files-on-linux-hosts-with-dd/

I don't know if it was essential, but I installed ntfs-3g just in case.
Synaptic wouldn't help, but 'apt-get install ntfs-3g' did the job.

Werner P. Schulz
08-17-2011, 07:00 PM
I don't know if it was essential, but I installed ntfs-3g just in ca1se.
Synaptic wouldn't help, but 'apt-get install ntfs-3g' did the job. ... is there any advantage to use ntfs-3g instead of ntfs-3g-ng, which is already installed within Knoppix?

Greetings Werner * http://www.wp-schulz.de/knoppix/summary.html
Own Rescue-CD with Knoppix (Knoppix V6.7.0 remaster)

utu
08-17-2011, 08:01 PM
... is there any advantage to use ntfs-3g instead of ntfs-3g-ng, which is already installed within Knoppix?

I'm not sure either is needed, but some of the literature made me think that sparse-files required ntfs-3g.
A little later, if some pro doesn't answer the question, I'll remove it and we'll see what happens.

My immediate concern is revising the 'what's in' vs 'what's out' menu to suit my needs.

I do think kl522's suggestion is a powerful improvement in things.

kl522
08-17-2011, 09:09 PM
... is there any advantage to use ntfs-3g instead of ntfs-3g-ng, which is already installed within Knoppix?


Haha I did not know ntfs-3g-ng is still on Knoppix because I have removed it from my system since sometime ago.

When I check Knoppix 6.7, true enough ntfs-3g-ng is still there.

Please file a bug report with K Klaus. ntfs-3g-ng should not be there, it is an old thing which haven't changed since 2009. If you bring up synaptic it will show 'ntfs-3g-ng' as 'local or obsolete' or 'manual', because it could not be found in any of the current repositories. Whereas ntfs-3g is currently still an actively maintained piece of code.

utu
08-17-2011, 10:32 PM
@ Werner

ntfs-3g-ng is not on my cd-based Knoppix 6.7 Synaptic LiveUSB.

utu
08-17-2011, 10:39 PM
@ anyone

When I try to quiet down the command 'create_compressed_fs' by adding '-q' to its options,
without the quote marks, of course,
I get a program crash. All I want to do is turn off a lot of unnecessary output.
Any useful suggestions in this regard?

Werner P. Schulz
08-17-2011, 11:07 PM
ntfs-3g-ng is not on my cd-based Knoppix 6.7 Synaptic LiveUSB.
... but it is on Knoppix 6.7.0 CD- an DVD-version.

kl522
08-18-2011, 12:24 AM
ntfs-3g-ng should not be there, it is an old thing which haven't changed since 2009.

While at it, I went ahead to check the static version of ntfs-3g contained inside minirt.gz from Knoppix 6.7. To my surprise, it is yet even older. There is no version date information but based on the usage output, I am guessing the copy of ntfs-3g was created 2007 ! :)

utu
08-18-2011, 12:35 AM
ntfs-3g-ng IS on my 6.7 cd, but not on my LiveUSB.
I probably would not have gone to apt for ntfs-3g if -ng showed up in Synaptic.

Anyway, as I understand it, if I want ntfs, I probably want ntfs-3g.

I'm still having trouble getting all my stuff rounded up to be included in the
re-master. Only a few piddly /etc contributions made the move so far.
I have stuff in what seems to be (as mounted in LiveUSB) /home/knoppix/Desktop/KNOPPIX that just isn't transferring. So when I DONT exclude /home, I'm surprised
it gets lost.

I notice a lot of the re-mastering literature that Google dredges up is quite old.
Here, I thought we were on the cutting edge.

kl522
08-18-2011, 02:37 AM
I'm still having trouble getting all my stuff rounded up to be included in the
re-master. Only a few piddly /etc contributions made the move so far.
I have stuff in what seems to be (as mounted in LiveUSB) /home/knoppix/Desktop/KNOPPIX that just isn't transferring. So when I DONT exclude /home, I'm surprised it gets lost.


I am not surprised. I believe /home/knoppix/Desktop/KNOPPIX in the default configuration, is a symbolic link to /mnt-system. We will have to go back to look at how the scripts do the copying. Likely it is copying it as SYMBOLIC link, which means the actual files it points to are NOT copied.

You should either destroy the symbolic link and make it as hard links, or you could after you performed the remaster, copy the old /mnt-system/* to your new /mnt-system.

The scripts written made no such provision for this "Knoppix-ish" behavour. Perhaps someone interested to modify the scripts could make further enhancements to make special provision for this.

It's a smaller glitch I would say. But it is a rather important to be able to handle this, as this is a "Knoppix-ish" behaviour.

Werner P. Schulz
08-18-2011, 08:24 AM
ntfs-3g-ng IS on my 6.7 cd, but not on my LiveUSB.
I probably would not have gone to apt for ntfs-3g if -ng showed up in Synaptic....you made me curious. Therefore I did a Flash disk Installation of Knoppix CD6.7.0 "without" persistent memory, startet it and Synaptic shows me "ntfs-3g-ng" as installed.

utu
08-18-2011, 09:28 PM
Have you done an update for either Synaptic or apt?

utu
08-18-2011, 09:39 PM
I haven't got the ntfs-3g sorted out yet, but things go better here with than without ntfs-3g.
I think things go wrong in compressing the image and maybe also in using the sparse-file properties without it.
A 'fuse' property of the kernel may be a pre-requisite for all this, and I don't know if that is now
a property of our current kernel or not. Nothing simple here.

It really might be simpler to script all my changes as Werner does than solve all this remastering jazz.
If the remastering capability were a built-in, I have a few uses for it, but nothing huge, anyway.

I cannot figure how to quiet the 'compress isofs' phase, without crashing the process.
Any help there would be appreciated.

Werner P. Schulz
08-19-2011, 08:15 AM
Have you done an update for either Synaptic or apt?... of course no; why shall I do it? And Synaptic don't show me newer versions of apt or synaptic.

utu
08-19-2011, 06:39 PM
@ Werner

I must apologize. I have not chosen my words very well.
i meant to say that perhaps the difference between my LiveCD and my LiveUSB
in regard to ntfs-3g-ng MAY be explained by the fact that before I use Synaptic
on the LiveUSB, my first order of business is to RELOAD. Not UPDATE, of course.

That's just a guess. I don't really care now, since I think ntfs-3g is the right answer.

I have established another thread concerning re-mastering, I hope you will join me there.

Best Regards, utu

kl522
08-20-2011, 04:09 AM
The implication :-

1) If one puts his persistent store on NTFS, then he is using ntfs-3g inside minirt.gz ( 2007 binary ).
2) If one uses NTFS storage after he is booted, then he is using ntfs-3g inside ntfs-3g-ng package ( 2009 binary ).
3) If one install ntfs-3g ( which deletes ntfs-3g-ng ), then he is using 2011 binary.

Take your pick, :)

jm1944
09-05-2011, 05:15 PM
.
I am embarrased to admit that I've got Chromium working with flash, after all.
Not being familiar with its symbology, I missed the clue that 'some plug-ins are blocked'.
Look for a little icon with a red 'x' in the address bar at the top.

Even so, I prefer Firefox-5 1st, IceWeasel-3.6 2nd and Chromium 3rd.

My bad. I don't know why the default is to block the built-in capability.

utu:

I read your post with interest because I would like to get flash working with Chromium on my Knoppix 6.7 as well. I am new to Linux.

Had no problem with the red x "unblocking" and after being led to a number of adobe sites, downloading flash_player_10_linux.tar.gz and extracting it (libflashplayer.so) in the download folder, following some instructions I found about going to "about:plugins" and enabling chrome Nacl and Default Plugin - version 1 (IceTea v. 1.8.7 was already enabled). For good measure I went to the Contents settings and set Javascript to allow all sites, and Plugins to run automatically. I even added CNBC.com to the exceptions in both Javascript and Plugins, so I though I was all set.

But when I go to view one of the videos on a CNBC.com site, instead of getting a playing video, I'm told I need to install flash player. I can only think that I haven't installed the extracted flash linux.tar.gz file into the proper place.

Do I have to close chromium and/or reboot? I haven't done this yet because I don't want to loose all my bookmarks and preferences. Can you help me? (I also downloaded Firefox and have same problem with installing flash into it, although I could install Download YouTube Videos + 3.3.51.)

If I can get flash working on both browsers, I'd like to try and set up my chromium browser to keep all my setting (preferences and bookmarks) intact, so that when I boot up I don't loose everything. In reading through the postings that follow your message, I understand that this can be accomplished with Knoppix using "overlayering" (on the thumb drive I have Knoppix installed), but this sounds a bit complicated. Is it?

Thanks for any input.

John

utu
09-06-2011, 12:32 PM
@ jm1944

Greetings, John & welcome to the forum.
You have two main questions as I see it.
1. Getting flash going; and
2. 'Overlayering'

Let's tackle flash first. That's the easiest.
I think the best way to do that is to use Synaptic.
Synaptic is a menu item on you main menu.
First time you use it, do 'reload' to update the cache.
Then search for Flash. You should get an answer for flashplugin-nonfree.
Install this and you should be set for both Chromium and IceWeasel;
anyway, I was.

I use 'Silent Monks' on YouTube to test my flash & sound.
First hit on Google.

Get that under your belt first, then come back and lets talk
about overlayering. It's not really complicated.

utu
09-06-2011, 12:58 PM
@ jm1944

Greetings, again John.

When you last booted, were you given a choice on setting up a persistent store?
Did you answer that question, or did it just whiz by?

If this makes no sense, just say so, and we'll start from there.