... 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)
Printable View
... 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)
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.
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.
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.
@ 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.
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.
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.
Better than none but they are not the kind of information which interest me in.
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 ....Quote:
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.
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.
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.
Code:";;
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 "[0;0H[J";;
---
> *\ vga=[0-9]*|*debug*|*\ splash*) true;; *) echo -n "[6;0H[J";;
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$SECUREOPTIONS
< mount "${NFSDIR}" "${BOOTISO}" -o ro,rsize=8192,wsize=8192,hard,nolock,intr$SECUREOPTIONS > /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
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?
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.
@ 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.
.
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.
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 ?
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.
(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?
Found this note concerning 6.7
http://www.knopper.net/knoppix/knoppix67-en.html
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.
May I know why you think so?
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.
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
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.
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.
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.
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.
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.
Regards
-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)
@ 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.
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
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.
@ 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.
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.
Code:#!/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
@ 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 ;-)
@ 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.