Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Why would the running knoppix partition be mounted rw?

  1. #1
    Senior Member registered user
    Join Date
    Dec 2004
    Posts
    168

    Why would the running knoppix partition be mounted rw?

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

  2. #2
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802

    Only Klaus K can answer correctly - but here is some motivation

    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.

  3. #3
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    (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

  4. #4
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    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.

  5. #5
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    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
    Code:
     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.
    Last edited by utu; 04-07-2016 at 04:54 AM.

  6. #6
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    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.

  7. #7
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    Quote Originally Posted by Capricorny View Post
    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.

  8. #8
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    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.

  9. #9
    Senior Member registered user
    Join Date
    Sep 2006
    Posts
    802
    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.

  10. #10
    Senior Member registered user
    Join Date
    May 2006
    Location
    Columbia, Maryland USA
    Posts
    1,631
    .
    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.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


1PC Matching pair Xeon CPU Processor X5660 X5670 X5675 X5680 X5690 LGA1366 picture

1PC Matching pair Xeon CPU Processor X5660 X5670 X5675 X5680 X5690 LGA1366

$35.13



Intel - Core i9-12900K Desktop Processor 16 (8P+8E) Cores up to 5.2 GHz Unloc... picture

Intel - Core i9-12900K Desktop Processor 16 (8P+8E) Cores up to 5.2 GHz Unloc...

$331.99



Intel - Core i7-12700K Desktop Processor 12 (8P+4E) Cores up to 5.0 GHz Unloc... picture

Intel - Core i7-12700K Desktop Processor 12 (8P+4E) Cores up to 5.0 GHz Unloc...

$242.99



Intel 6 Core i5-8600 3.1GHZ Desktop Processor SR3X0 picture

Intel 6 Core i5-8600 3.1GHZ Desktop Processor SR3X0

$50.00



Intel - Core i9-14900K 14th Gen 24-Core 32-Thread - 4.4GHz (6.0GHz Turbo) Soc... picture

Intel - Core i9-14900K 14th Gen 24-Core 32-Thread - 4.4GHz (6.0GHz Turbo) Soc...

$539.99



Intel Core i5-6500 Quad-Core Processor 3.2 GHz 6MB LGA1151 picture

Intel Core i5-6500 Quad-Core Processor 3.2 GHz 6MB LGA1151

$23.99



Intel - Core i7-14700K 14th Gen 20-Core 28-Thread - 4.3GHz (5.6GHz Turbo) Soc... picture

Intel - Core i7-14700K 14th Gen 20-Core 28-Thread - 4.3GHz (5.6GHz Turbo) Soc...

$399.99



Intel - Core i9-13900K 13th Gen 24 cores 8 P-cores + 16 E-cores 36M Cache, 3 ... picture

Intel - Core i9-13900K 13th Gen 24 cores 8 P-cores + 16 E-cores 36M Cache, 3 ...

$519.99



AMD EPYC 7282 cpu processor 16 cores 32 threads 2.8GHZ up to 3.2GHZ 120w picture

AMD EPYC 7282 cpu processor 16 cores 32 threads 2.8GHZ up to 3.2GHZ 120w

$78.00



Intel Core i3-12100F Processor (4.3 GHz, 4 Cores, LGA 1700) Box - BX8071512100F picture

Intel Core i3-12100F Processor (4.3 GHz, 4 Cores, LGA 1700) Box - BX8071512100F

$83.50