Kernel 5.0

[peebee]

Is out: https://www.kernel.org/

There is also some preparatory work on the aufs github pages (essential for a Puppy kernel unless we change to overlayfs)......

[rockedge]

I will try to compile a 5.0 once the aufs is set.....

[gyro]

Changing from aufs to overlayfs:

While we can still have Puppy with overlayfs (I use one as my daily workhorse) instead of aufs, a few things get lost.

The biggest difference is that the layers in the stack cannot be changed.
This means "sfs_load" cannot append extra sfs's to the stack, or unload sfs's that are in the stack.
It also means that "snapmergepuppy" is not supported, so all our odd pupmodes would need to be re-thought.

Also a writable stack needs 2 writeable Linux directories, not just 1 like aufs, so simply using the mountpoint of a savefile as the write layer won't work.
So current savefile methodology would need to be re-thought.

Fortunately for me the only one of those I would like to use is "sfs_load".

So, I suggest that we hope that aufs remains viable for some time to come.

gyro

[fredx181]

So, I suggest that we hope that aufs remains viable for some time to come.

Yes, let's hope so.
I know very little about overlayfs, but it looks to me that it has only disadvantages compared to aufs, do you see any advantages ?

Fred

[rufwoof]

So current savefile methodology would need to be re-thought.

IF it comes to that, then Barry's EasyOS model is one to keep in mind. Main sfs loaded as usual, but with continual saving of changes immediately as/when they occur ... plus snapshot/rollback options. If the continual save area is a folder then space is limited to free disk space. Snapshot are created by creating a sfs of that save folder tree. Snapshots are restored (rolled back) by clearing the save folder and unsquashing the snapshot sfs content in its place. That does mean however to 'not save' you have to first create a snapshot, then use as desired, then restore the snapshot.

[mikeslr]

I know this has been suggested before. And I appreciate the hard-work gyro put into overlay. But aufs still has the advantage over overlay already mention and the advantage of avoiding the complexity of the system used in EasyOS. Plus one other: if adrv is substituted for a SaveFile your system is easy to maintain AND always boots from pristine READ-ONLY compressed files -- rather difficult to infect with malware [or any component of malware if it requires more than one] beyond that which may exist in RAM during the current session.

Adopt (fork) aufs and keep it viable as long as possible.

Others have worked on the technique before, but I think nic007's thread, http://www.murga-linux.com/puppy/viewto ... 470#944470 made it easy enough for me to follow. I've spent the last couple days learning enough YAD so that a pet to could be employed under Slacko 5.7.2CE (and dealing with the resulting absence of a SaveFile/Folder). Expect to post it tomorrow after some tests. But someone who actually understands bash could generalize it so that it would work under any Puppy. [Improvements would also include GUI guided (a) selection of Linux work space if low RAM and/or Puppy on non-Linux partition; (b) rename existing adrv to ydrv, combining with existing ydrv if necessary; (c) after first conversion renaming adrv to adrv.bak or adrv.1 etc. before creating a new adrv. Maybe some others.

rufwoof had an interesting post in the last day or so (FatDog or EasyOS thread?) which went somewhere over my head. IIRC, it had to do with a 'False-root'. I should have book-marked it as I remember thinking it would provide significant security enhancements.

At any rate, as the computing world and Linux continues to change, and especially become a more dangerous place to operate, the questions we should all be considering are 'How to develop Puppy to operate in it and distinguish Puppy from other Linux operating systems?'

P.S. Also note the work ITSMERSH is doing, http://murga-linux.com/puppy/viewtopic. ... 273#810273 and http://murga-linux.com/puppy/viewtopic. ... 17#1020617

P.P.S. Ah, here's rufwoof's post and the part which caught my attention: http://murga-linux.com/puppy/viewtopic. ... 33#1019133

"Within the above settings, the chroot can read/write files etc. as usual, but whilst its root its a disabled root. Run ps within the chroot for instance and you only see a limited set of processes. Try and chown a file and ... not permitted. Try and chroot out of the chroot and ... not permitted. Try and mount sda3 (or whatever) and not permitted, but you can see sda3 files if they were already mounted by the 'real root'. Try and use tools to spy or enter keys into real root and ... not permitted. Run a browser and that's fine, or any other program (subject to not relying upon capabilities that have been dropped)."

Puppy -- a small but easily expandable system having control over of the user's entire computer, but always booting from and using pristine, hard (perhaps impossible) to corrupt components. You can destroy it. But you can't enslave it. And perhaps with rufwoof system, not destroy it.

[rufwoof]

@mikeslr

I've recently added some notes about adding cgroup as well into that Xephyr/chroot/capsh/unshare set Mike.

Xephyr in effect is another X server, so separates your main (real root) desktop from the duff-root's (as i've coined a name - fake root/false-root/whatever) desktop.

Unshare - unshares otherwise shared resources - for further separation/security

capsh - drop's capabilities, such as being able to chroot, run sys admin commands etc.

chroot - makes a sub-folder the apparent root folder, so anything outside of that isn't 'seen'

cgroup - enables things like maximum amount of ram allowed to be used, which cpu's/cores are allocated/available ...etc.

... that collectively form a duff-root i.e. looks and feels like root, but is more like a restricted userid. In retort to 'you run as root, are you mad' ... you can reply with 'ah, a restricted root, comparable to a restricted userid'.

I've set up my easyOS frugal HDD install so that it automatically rolls back to a clean main system save sfs content each time I boot. So for the intrusion detection script I run at startup I check mbr, grldr, vmlinux, initrd, easy.sfs, save sfs ... checksums (md5) and pretty much know that they're clean if that passes. For the duff-root (easy container) I also check its save sfs checksum, so I also know that the duff-root is 'clean' (I roll back to that save sfs before starting the easy container (duff root) - that I use as my main desktop (browsing etc), knowing that even if that is hacked, then the hacker can't get to my data drives, real root ..etc.).

For the parts that are shared between real root and duff root, in both being 'root' there's no need to change file ownership/permissions etc. It also means you don't have to enter passwords - that might otherwise be unwantedly captured.

[gyro]

I know very little about overlayfs, but it looks to me that it has only disadvantages compared to aufs, do you see any advantages ?

The obvious advantage is that it's part of the Linux kernel, so no kernel patching required.

It's also supposed to be fast, because it only handles directory processing, once a file is opened all I/O goes directly to the filesystem containing the file.

It has a neat feature of being able to create read-only stacks and being able to use a stack as a layer. So in my "overlay_init" all the sfs's are mounted into a read-only stack and the real stack consists of just the write directory and this read-only stack.

An overlayfs stack can easily be destroyed, by simply unmounting it. Which makes it easy to use in scripts to merge directories (or mounted sfs files), by simply mounting them in a read-only stack and then processing the files via the stack mount point.

To clarify my "recommendation":
While aufs is maintained for new kernels, we can avoid some pain by continuing using aufs.
But should maintenance of the aufs patches cease, then we should accept that pain and move on. Adding the maintainence of aufs to the Puppy workload, would not be worth it.

@peebee,
Sorry that my comment seems to have hijacked your topic about "Kernel 5.0"

gyro

[peebee]

Reminder - my kernel builds require separate firmware for instance in an fdrv

Kernel Release: 5.0.1-lxpup64
Build Date: Sun Mar 10 18:20:14 GMT 2019
Build GCC: 8.3.0
OS Support: GNU/Linux
Architecture: x86_64
SMP Enabled: Yes

From Here

[rockedge]

Hello peebee

good work....can you tell me which aufs5 and aufs-util you used to compile the kernel?

I keep running into an unable to compile aufs-util error attempting to compile kernel 5.0.1 with the aufs5.0 series.

[peebee]

Hello peebee

good work....can you tell me which aufs5 and aufs-util you used to compile the kernel?

I keep running into an unable to compile aufs-util error attempting to compile kernel 5.0.1 with the aufs5.0 series.

Had to hack build.sh to make it use aufs-util-4.9 - there is a change that needs to be done on github to remove the hack

[rockedge]

Thank you very much peabee!

I pulled the latest woof-CE and used the stock kernel-kit build.sh and no luck.
but your modified build.sh worked nicely. I was able to build a 64 and 32 bit version with the firmware built in. The script also was able to switch to the aufs5.0 branch. Both kernels will be made avialable for download

https://rockedge.org/kernels/