Moderator: Forum moderators
Yes I thought something was missing. I kept running across a missing patch file while attempting to compile a 5.10.1 real time kernel with full virtualization support enabled. Though worth a mention is the real time patches encountered errors and did not complete either.
Only tried using the kernel kit.
Given the "Subject" of this topic, I decided to reply.
Can we have an overlayfs based Puppy instead of an aufs based Puppy?
Yes,
I've been running such a beast for a couple of years now.
My current daily workhorse is XenialPup 7.5 from 'mio22u_up_xenialpup_7.5.sfs', i.e. using overlayfs for it's stack.
BUT,
there are significant differences between overlayfs and aufs, these mean some things have to change.
1. Once an overlayfs stack has been mounted, it's structure can't be changed.
Accordinng to the kernel documentation, the result is undetermined.
(This is the most annoying, because I seem to end up rebooting a lot, but maybe that's due to the stuff I do,
if you spend all your time running ordinay applications, maybe it wouldn't matter so much.)
'sfs_load' can't append an extra layer to the stack, or remove a layer from the stack.
'sfs-load' is reduced to simply managing the list of extra sfs's that get built into the stack at boot.
(remounting the stack with a differrent set of layers changes nothing.)
'snapmergepuppy' cannot work at all, so the current "odd" pupmodes can't work.
'init' can't add layers one by one, the stack has to be created in one go,
although you can have sub-stacks, so my current overlayfs puppy has a read-only stack containing only the sfs files,
the running stack has only 2 layers, the RW layer and the sfs stack.
So the 'init' script has to be significantly rewritten as a minimum.
2. An overlayfs RW layer requires 2 directories "on the same filesystem". The directory containing the layer, and a "work" directory.
An aufs RW layer requires only the directory containing the layer.
The current 'savefile' mechanism uses the mount-point of the savefile as the single directory to add to the stack.
There remains an issue as to where to create the "work" directory when using a savefile as an RW layer for an overlayfs stack.
I never found a solution that would reliably shutdown cleanly.
But of course there's more than 1 way to skin a cat.
For instance, in my overlayfs Puppy, I can run my pupmode=12 in a "save query" way, i.e. on shutdown it will ask if I want to save or not, and won't if I select "no".
When running this way, the 'init' script creates an archive of the RW layer directory if there is no archive;
If there is an archive it clobbers the RW directory, with the archive contents;
At shutdown, if I ask for a save the archive is deleted, if I ask for no save, the archive is not touched and all changes to the RW directory are clobbered at the next boot.
(From ny browsing of the forum, some folk run pupmode=13 so they can have "save query", but pupmode=13 going doesn't mean "save query" has to go.)
So, we should stick with aufs as long as we can.
But, the end of aufs, does not have to mean the end of Puppy, an overlayfs based Puppy is doable.
gyrog
If we are to have a Puppy without "aufs", then it's a Puppy without 'sfs_load' as we know it, i.e. being able to dynamically add a large application to Puppy, inclduing integration into the Puppy menu, try it, and then keep it, or remove it from Puppy and it's menu.
I have established 1 possible way of doing the same thing without 'sfs_load', i.e. use "portable" applications, e.g. ".AppImage" files,
plus a utility like my "PortableActivate" to add the "portable" applications to the Puppy menu, (and as a CLI program in the $PATH).
And it does this with a very minimal footprint on the Puppy "save".
Oh, it works just as well in my "overlays" Puppy, as it does in a "normal" "aufs" Puppy.
o news
- linux-v5.13 is released, and aufs-5.13 follows it.
no new commits
J. R. Okajima
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- for linux-v5.14-rc1, replace kmalloc_index() by __kmalloc_index()
aufs5.x-rcN branch supports linux-v5.14-rcN, and it simply follows the
changes in mainline.
My current development base version is linux-v5.4 which is marked as
"longterm" on wwe.kernel.org. When linux-v5.14 is released, I will move
my development base version to linux-v5.10 which is also longterm.
In other words, aufs-5.4..aufs5.9 will end.
J. R. Okajima
----------------------------------------
- aufs5-linux.git#aufs5.4..aufs5.13
nothing
- aufs5-linux.git#aufs5.x-rcN
aufs: for linux-v5.14-rc1, replace kmalloc_index() by __kmalloc_index()
- aufs5-standalone.git
ditto
- aufs-util.git
nothing
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
I assume he means development/updates will end, as K 5.0 - 5.3 aufs is currently still available. Could then still build 5.4, although I'm now using 5.10.50.
o news
- linux-v5.14 is released, and new branch "aufs5.14" tooo misc.
- minor, update the copyright year
I just simply forgot it.As I announced on 19 Jul, aufs5.4..aufs5.9 end. They are not supported
anymore. My new development base version 5.10.J. R. Okajima
----------------------------------------
- aufs5-linux.git
aufs: minor, update the copyright year- aufs5-standalone.git
ditto- aufs-util.git
nothing
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
I just built a huge 5.14.1. Have not tested it yet. Perhaps I will patch it for and re compile for a full real time kernel
@linuxunix
it is here: https"//rockedge.org/kernels , under Kernels->64bit->5.14.1_untested
or here directly for the huge kernel 5.14.1 -> http://rockedge.org/kernels/data/kernel ... 64.tar.bz2
I read that kernel 5.15 will have fast ntfs read/write driver built in (used to be a commercial-only solution but open-source released now) - no slow fuse-based ntfs-3g required thereafter.
https://www.tinylinux.info/
DOWNLOAD wd_multi for hundreds of 'distros' at your fingertips: viewtopic.php?p=99154#p99154
Αξίζει να μεταφραστεί;
rockedge wrote: ↑Sun Sep 12, 2021 12:57 am@linuxunix
it is here: https"//rockedge.org/kernels , under Kernels->64bit->5.14.1_untested
or here directly for the huge kernel 5.14.1 -> http://rockedge.org/kernels/data/kernel ... 64.tar.bz2
5.14 How to compile virtualbox without source code?
Very difficult to understand what you needed............ presuming........... kernel-sources.........
Don't usually upload............
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
I use FossaPup64 9.5, but it still prompts that the glibc version is too old to use yours
"it" ??
"yours" ??
No idea what you are referring to!
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
I use FossaPup64 9.5, but I can’t use your source code. It prompts that the glibc version is too old.
PLEASE TAKE TO DIFFERENT THREAD - THIS HAS NOTHING TO DO WITH AUFS Future!
Still no idea what your problem is - there are no binaries or libraries in kernel_sources........... again another "it" with no explanation of what "it" is!
You need to provide (in the other thread) much greater detail of what you are trying to do, what you are doing when the error occurs and exactly what error you are seeing - otherwise people cannot help you!
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- aufs began supporting v5.15 series.J. R. Okajima
----------------------------------------
- aufs5-linux.git#aufs5.10..aufs5.14
nothing- aufs5-linux.git#aufs5.x-rcN
aufs: for v5.15-rc1, no mand-lock anymore
aufs: for v5.15-rc1, new param 'rcu' for ->get_acl()
aufs: for v5.15-rc1, sync_inode() is gone- aufs5-standalone.git
ditto- aufs-util.git
nothing
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- linux-v5.15 is released and aufs5.15 follows.J. R. Okajima
----------------------------------------
- aufs5-linux.git
nothing except aufs5.15 branch- aufs5-standalone.git
ditto- aufs-util.git
nothing
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- linux-v5.17 is released and aufs5.17 follows it.J. R. Okajima
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
aufs5.15.36 branch is released.
aufs5.x-rcN is updated to follow linux-v5.18-rc5, but aufs code is unchangedJ. R. Okajima
----------------------------------------
- aufs5-linux.git
new branch aufs5.15.36
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- linux-v5.18 is released, and aufs5.18 follows it.
- new branch aufs5.15.41 is created to follow linux-v5.15.41.J. R. Okajima
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
- linux-v5.19 is released and aufs5.19 follows.J. R. Okajima
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
o news
When linux-v6.0 (not -rcN) is released, current GIT repos (aufs5-linux
and aufs5-standalone) will be replaced by aufs6-*, and I will stop
maintaining aufs5.10--aufs5.14 branches.Aufs5.x-rcN branches in this replease is for linux-v6.0-rc1. No new
features but some behaviours changed in the mainline.
- unlink(2) and rmdir(2) in NFS is broken, and they may result
NULL-pointer-access.
- access(2) in tmpfs changed its error code.J. R. Okajima
NOTE, this is the LAST 5.18.y stable release. This tree will be
end-of-life after this one. Please move to 5.19.y at this point in time
or let us know why that is not possible.
Builder of LxPups, SPups, UPup32s, VoidPups; LXDE, LXQt, Xfce addons; Chromium, Firefox etc. sfs; & Kernels
What a shame, the 5.10.x kernel series is maintained until the end of 2026. That's 4.5 years from now! If aufs for 5.10.x breaks before 2026 or gets hit by a critical bug that won't get fixed for 5.10.x, that's sad for Puppy. I just hate how aufs takes away the safety and stability of well-aged longterm kernels.
Longterm kernels are great for old computers, because they get more stable and secure over time and give users a 6+ year period without breaking changes like removal of deprecated drivers or big variations in resource consumption.
If this deprecation of aufs for 5.10.x breaks Vanilla Dpup 9.2.x, so be it. This is my last Puppy release series that uses aufs 