Why would the running knoppix partition be mounted rw?

[Albretch]

# mount | grep mnt
/dev/sda4 on /mnt-system type ext4 (rw,relatime)

# uname -a
Linux Microknoppix 3.16.3-64 #10 SMP PREEMPT Fri Sep 26 02:00:22 CEST 2014 x86_64 GNU/Linux


lbrtchx: http://knoppix.net: Why would the running knoppix partition be mounted rw?

[Capricorny]

Only Klaus Knopper can give you the correct answer, but after some weeks with Debian 8.3 live - which mounts the partition ro when there is no persistence, I think I can provide some motivation. Have you tried Debian live with and without persistence?
In short: While it can be argued that mounting a partition with a compressed image readonly is the "correct" thing to do, in practice we often lose more than we gain that way. There are usually quite a few other files apart from the compressed live image on the partition, and why should it be impossible to modify any of them, or, for example, add more compressed images to the partition while running off it? Personally, I have found ro mounting to be mostly a hassle for me. Over time, partition sizes have grown dramatically, while the Knoppix CD and DVD images have stayed essentially the same size.

As for Knoppix, ro mounting would make it impossible both to change the booting configurations - unless they are placed on another drive, and I think many would find that impractical. Maybe more important, is that we would not be able to do any administration work on any persistent image, like fixing the file system, take a backup on the same partition or resizing it, from any Knoppixes on that partition. To patch this newly created problem, add a cheatcode for "mount rw" - and get back to where we started.

I'm quite sure you could modify init in minirt.gz to add and implement a "ro" cheatcode if you really want it, shouldn't be too hard.

[utu]

(snip)
Personally, I have found ro mounting to be mostly a hassle for me.
(snip)
I'm quite sure you could modify init in minirt.gz to add and implement a "ro" cheatcode if you really want it, shouldn't be too hard.

I'm really interested in this.
I hope you will share some examples of why making persistence ro by default is reasonable,
and enlighten us on how to _easily_ tweak minirt.gz to add a ro option to Knoppix.

As you know, I take some pains to make a cloop or two to protect most of my Knoppix perstence material;
cloops having the nice feature of being not only virtually ro, but also much more compact than regular persistence.

I'd like to see a Knoppix variant which has persistence ro with a chance at shutdown either
to capture what's in the ramdisk, or stick with whatever was in persistence at boot.

atb

[Capricorny]

I haven't even looked into the last couple of versions of init in minirt.gz myself. But from the unchanged cloop mounting, I feel quite sure that making adjustments to the basic mounting procedure should not be too hard. If knoppix-data.img is present and not cheatcode noimage, then mount rw, otherwise mount ro. There is already code for detecting this in init, it just has to be applied somewhat differently.

But I am not going to do it. The principal reason for mounting ro is that whenever what you are going to use is ro, it's best to mount the partition ro. There may have come another reason recently, with linux being less filesystem-safe - but I think this is mostly anecdotal so far.
From my experience with Debian, for me, the drawbacks with mounting ro outweighs the advantages. IMHO, the most important practical advantage is for checking out a live distro version: When you just copy the squashfs to the hard disk to test a bit faster and more thoroughly, it is much safer to run it readonly. I'm not in that situation.

I'm quite with you on the idea mounting persistence ro in the aufs stack, and only update upon shutdown. I think that has become even more useful recently. But for that last update, having the whole partition mounted ro would just require an extra umount/mount step on shutdown, extra complexity with little visible gain.

[utu]

having the whole partition mounted ro would just require an extra umount/mount step on shutdown, extra complexity with little visible gain.

If that were the only consideration, then wouldn't this occur only when I want to keep new changes at shut-down?
If so, a small delay to umount and mount would seem like a reasonable trade-off to me.

Here's my current persistence file

 knoppix@Microknoppix:/KNOPPIX-DATA$  
sudo du -h --max-depth=2 
 72K    ./etc                     # half a dozen,or so, one-line tweaks    
202M    ./var/lib                 
100M    ./var/cache              
301M    ./var                     # after reloading Synaptic 
5.5M    ./usr/share               # ttfmscorefonts for LibreOffice 
5.5M    ./usr     
 59M    ./home/knoppix            # my /home stuff 
 59M    ./home 
 12K    ./root 
   0    ./.wh..wh.orph 
365M    . 
knoppix@Microknoppix:

Refering to this arrangement, one may observe... /var requires r/w capability.
ramdisk provides this until shutdown, but to retain for re-boots, needs r/w storage.
/etc, /usr /home for sure could be ro until I choose to change them.
In that event, I could put up with a small delay on shut-down.

[Capricorny]

Yes, with that kind of use, mounting the whole partition ro might be sensible. I often have a similar situation myself, because the data I work with are on other partitions. So if I had a "commit" option, where changes made temporarily are saved, I would more often work with readonly-ramdisk. Implementing such functionality is much more work than just adding a "ro" cheatcode, but AFAIK, some distros operate that way, so it should be possible to build upon the work done there.

One possible scheme (don't know how smart it is, but apart from space use, it should be fairly efficient) could be to operate with two persistent images, and mount them readonly alternatingly, saving changes to the one that was not mounted. With compressed image c and persistent images p1 and p2, we could quite easily do something like this with two aufs mounts, the compressed image being used in both:
rsync from ramdisk : p1(ro) : c -> p2(rw) : c
On next bootup, p2 will be mounted ro, and p1 will be updated. With changes in the order of tens of megabytes, this should only take a few seconds. There is also a primitive kind of backup in returning to last version.

[utu]

Yes, with that kind of use, mounting the whole partition ro might be sensible. I often have a similar situation myself, because the data I work with are on other partitions. So if I had a "commit" option, where changes made temporarily are saved, I would more often work with readonly-ramdisk. Implementing such functionality is much more work than just adding a "ro" cheatcode, but AFAIK, some distros operate that way, so it should be possible to build upon the work done there.

Here's my suggestion:

Assume persistence is a cloop or squash partition to begin-with,
and normal usage is similar to a LiveDVD rather than LiveUSB
in which case persistence is virtually read-only.
Just add noimage to current boot cheatcodes.

Provide Knoppix with three new menu choices:
1. Unsquash, mount & rsync current persistence with current unsquashed ramdisk
then cloop or squash the union of these two --> produces 'new' squashed persistence file
2. Trade old for new cloop or squash files and vice versa; the un-do/re-do persistence update.
3. Remove unnecesary cloop or squash files as a secondary, 'never mind' option.

This wouldn't require any nagging at shut-down, and would only mean relatively small additional
changes to minirt.gz and/or init.

Another alternative for menu Choice 1 might rather be:
1. Squash current ramdisk and 'merge' this with current squashed persistence, using
overlayfs. There is a Ubuntu precedent for this.

In both cases, persistence would take up much less room than it does now.
Switching from cloops to squashfs and overlayfs would also bring Knoppix closer to
everyday Debian and Ubuntu, in terms of building blocks.

[Capricorny]

Because of trouble with cloop handling, I'm going to make a squashfs version of 7.6.1 and try to run form it.
Old-style cloop remastering doesn't seem to work. Mounting manually and inspecting, there didn't seem to be anything wrong with the cloop remasterings of 7.6.1, but for some reason, Knoppix wouldn't mount them at startup. Have just started looking into 7.6.1 minirt init, though.
Maybe we should try with overlayfs too, while we are at it? But I know absolutely nothing about it, and I am hardly able to handle aufs - it hasn't been necessary with more than the mere basics.

I think you should try to implement your ideas, with some luck, I might be able to make a minirt_sq_ovl.gz that you could start from.

[Capricorny]

Just have to correct myself: Just discovered a missing file stopping findknoppix() in init, remastering works as usual. Just copy all surrounding files over to the directry with the remastered KNOPPIX image - that hasn't been necessary before, and there is just one file needed now, but just to be sure... Still, for more fleixble use, squashfs may be the way to go. I also had a lot of problems with cloop in standard Debian - it is kind of outlawed.

[utu]

.
I agree that Knoppix might be easier to hack if cloops and aufs
were replaced with squashfs and overlayfs. These seem to be where the action is going these days.

You might want to google 'mergeusb' and see how Dav Stott & others are handling remastering.
I had some luck with Mint 17.2 using mergeusb, but my Mint 17.3 has a low-memory corruption problem
I can't solve.

I recommend mergeusb as probably a good example of how to code overlayfs and squashfs
instead of cloops and aufs to combine filesystems. I wouldn't necessarily just
plop all his code in and hope for the best; just refer to his overlayfs code to see how easy it
is to set up.