Cheatcode wish list - some entries/suggestions

1. As has been discussed elsewhere, it would be handy with a nowear cheat code, using ramdisk as an extra writable layer for persistent store, with changes committed to disk only upon request/shutdown. I don't want to go into the rationale for this here, and alternative solutions - just point out that it could be useful in a number of actual use situations.

2. After remastering, all programs can go into the compressed KNOPPIX image, and persistent store is used for configuration and basic user data. What about, for example, RAW photo files, one CF or SD card often being bigger than the 4GB persistent store? To standardize setup as much as possible, I use one big partition, mounted on the traditional Unix directory /store, for virtually everything not going into knoppix-data.img. And I routinely create that directory, and mount the actual partition (varying from pc to pc) on it after system startup. Now, if I could give a cheatcode store, something like store=/dev/sda7, at the command prompt, this could be done by the system. This is analogous to the fromhd= and home= cheatcodes.

3. We can always have a separate storage directory /store, but we may not always be able to set aside a separate partition for it. For example, using a Windows PC with one big NTFS partition on it, it may not always be worthwhile or even possible to create a separate partition. Then we may repeat the persistent store trick, create one big file on the native system, set it up with a Unix file system and loop-mount it. In that case, we need a third cheatcode, storefile. Like in storefile=store-data.img.

In the single-partition case with a poor man's install, the partition with the store-image file is already mounted on /mnt-system. In this case, store is left out. In the case where both store and storefile are used, the disk partition with the image file is mounted on /storepart, and the image file is mounted on /store. This can be useful or necessary if several /store versions are in use, or the big partition is basically in use for something else (think, for example, video editing).

I have experimented with larger standard persistent store than 4GB, and it may come in handy sometimes. I tend, however, to return to Knoppix basics, and rather make more use of /store. It is also very easy to back up or copy systems. I just mount a corresponding harddisk in an external cabinet, and backup /store. (Or, rather, subdirectories - swap space, for example should be left alone.)

Any comments, more suggestions?

I favor two modifications of the following sort for the LiveUSB
version of Knoppix. These might be realized as cheat-codes or
menu choices or both.

1. Remove the obligatory saving of the persistent-stare image
on logout and make it an option to only save this image on the
user's choice to do so.

2. Provide a new option, on user command, to place a compressed
version of the current persistent store image in the /mnt-system
directory to serve as a self-contained backup, avoiding only
the specific /mnt-system/KNOPPIX directory.

Alas, I fear we are talking to ourselves here. I think we'd have
to post something to debian-knoppix to get any attention.

Quote:

---

Alas, I fear we are talking to ourselves here. I think we'd have
to post something to debian-knoppix to get any attention.

---

Speaking only for myself, I think it is good to discuss and test out the ideas as far as possible before we eventually suggest something to Klaus K. If we have aggred on some new features, and can produce "proofs of concept", it will also be much harder for him to reject it, too.

Your dropping of persistent image changes is easily implemented with the nowear option and a question about saving to store on shutdown.

The compressed backup can be produced with another alternative, Create compressed. Maybe wh could then have 3 shutdown options + default (save&exit).

<CR> : Save image and exit
N : No saving of image. (Option not available without nowear cheat code.)
C : Create compressed backup, e.g. knoppix-data.img.gz
M : Maintenance mode. /UNIONFS is unmounted etc

Doing things this way, we could also have safer unmountings of file systems.

@ Capricorny

I agree whole-heartedly with your 'proofs of concept' approach.

I've been using the idea #2 in my post #2 for some time now,
and it works fine for me. I could post an example.

Do you suppose we need a unique forum for this, or should we
just use one of those which already exists, like this one?

-------------

With regard to your concern on 'wear' on USB devices, are you
aware of the SD manufacturers' ass'n warnings about using Microsoft
or Linux formatting as opposed to manufacturers' ass'n formatting?
I can dredge up a link if you are interested.

an option to easily add new boot commands using knoppix.sh

Quote:

---

With regard to your concern on 'wear' on USB devices, are you
aware of the SD manufacturers' ass'n warnings about using Microsoft
or Linux formatting as opposed to manufacturers' ass'n formatting?
I can dredge up a link if you are interested.

---

I think this may illustrate the need for a nowear option, as it seems to indicate that the writing pattern (determined in part by formatting) influences flash device lifetime. I myself try to use standard Unix/Linux tools as much as possible, so I think going into this is more for the file tools developers than for me. I haven't had problems with flash device wear by normal use, the biggest threat for mine is getting into the washing machine, which they may or may not survive ;).

Quote:

---

an option to easily add new boot commands using knoppix.sh

---

This is very interesting, I think. I consider it as touching upon the boot loader use issues. For example, when I use grub for booting and just enter a standard Knoppix command line for it to run, I don't get the chance of entering boot options manually. Which is, generally, what I want. For me, and many other users, specifying boot options do not belong to normal use. BUT: When you need it, you often need it badly.

dinosep, have you looked into the modifications necessary to implement this? Most of the other suggestions (the boot part of them) should be implementable by modifying minirt.gz, eventually /etc/rc.local - how much more is needed here?

As for discussing such aspects of Knoppix development, I think this forum is nearly perfect. In my opinion, it is much better to approach Klaus K on the Debian Knoppix devel list with suggestions we have already tested ourselves - our friend Ryumbeke does this, and I think it works well. I also think it is better that we try out our ideas on something that is in effect Knoppix derivatives, rather than directly modifying Knoppix itself.

We could, for example, go all the way and make a version using squashfs for the compressed image and grub4dos/grub for all booting (not sure if grub4dos works with CD/DVD though) If we have a small suite of scripts to routinely turn standard Knoppix into this variant, it would make a stronger argument for applying the same changes upstream than just suggest them to Klaus K, I think.