Upstream kernel?

Post#1 by **fu11m00n** » 07 Nov 2025, 14:33

Is it possible to use the official identical Slackware upstream kernel with Porteus?

Based on what I see in the Slackware ARM project... the upstream kernel appears to be the first step towards transitioning to ARM.
Neko has extensively explored the subject of kernels. But primarily for x86_64 and Porteus. Currently my skill set is not kernels.

I could be mistaken but I'm not sure if I took the identical upstream kernel (as is) and put it in Porteus that it would end well.

I not sure if it is possible to adapt the upstream kernel for use in Porteus.

I know it's a big ask but if anyone has a link to download a Slackware upstream official...
"overlay" 5.15.19 (stable) and 6.12.57 (current) kernel I might be able to advance my fu11m00n/OS project.

If I manage to aquire a kernel I will post it to my Sourceforge project page repo.

Thanks in advance.

Post#2 by **beny** » 07 Nov 2025, 17:25

hi, porteus kernel and also the others versions are patched with the aufs patch,the only way to use the 6.12.57 kernel is the overlay module but only Neko have done a try to use with Aporteus

Post#3 by **fu11m00n** » 08 Nov 2025, 04:53

@ beny... thanks.

Sounds complicated.

So the Aporteus kernel is the closest kernel (using overlay) to upstream official 6.12.57 (current)?
Is the Neko kernel generic or huge? Is there also a 5.15.19 (stable) version?

If there is a 5.15.19 (stable) version I can test it on baremetal with my project (fu11m00n/OS).

Post#4 by **roadie** » 08 Nov 2025, 05:08

fu11m00n wrote: ↑
07 Nov 2025, 14:33
Is it possible to use the official identical Slackware upstream kernel with Porteus?

Based on what I see in the Slackware ARM project... the upstream kernel appears to be the first step towards transitioning to ARM.
Neko has extensively explored the subject of kernels. But primarily for x86_64 and Porteus. Currently my skill set is not kernels.

I could be mistaken but I'm not sure if I took the identical upstream kernel (as is) and put it in Porteus that it would end well.

I not sure if it is possible to adapt the upstream kernel for use in Porteus.

As beny posted, Porteus/PorteuX/Nemesis kernels use the aufs patches, I see that the aufs patches are still available up to 6.12.29.....whether or not it would patch well with the 6.12.57, I can't say. As beny also posted, the kernel can be compiled for the overlay filesystem without the need for patching as overlay was added to the kernel sources quite a while ago.

Both aufs and overlay give much the same experience, though activating .xzm modules can be a problem with overlay. All modules are still activated on booting. Using a script provided by neko has usually worked for me for activation of modules after booting. That script is contained in the 001-overlayAct.xzm, I believe it can be found in the Aporteus .iso.

As far as being complicated, compiling a kernel is not as daunting as I once thought it was. There are programs available, neko's Kernel Builder for one. I recall that fulalas posted a kernel compiling script some time ago. I "borrowed" some code from it to make my own compiling script, as well as code by fanthom and neko. Mine works for Porteus, PorteuX, and Nemesis. It checks to see which one is running and bases the build on that, custom names are applied to the resulting files.

Post#5 by **rych** » 08 Nov 2025, 05:58

roadie wrote: ↑
08 Nov 2025, 05:08
001-overlayAct.xzm

roadie wrote: ↑
08 Nov 2025, 05:08
activating .xzm modules can be a problem with overlay. All modules are still activated on booting.

The "problem" is that it simply cannot be done, we have to reboot if we want to deactivate a module for example? Or has there been a progress with overlayfs?

Good news that the 001-overlayAct.xzm even exists. Is there any noticeable performance difference between OverlayFS vs AUFS kernel patch though?

Post#6 by **fu11m00n** » 08 Nov 2025, 10:56

@ roadie... thanks.

It seems upstream official 5.15.19 (stable) and 6.12.57 (current) might be doable (w/ overlay).

Post#7 by **fu11m00n** » 08 Nov 2025, 11:08

@ rych... thanks.

Is there a link to 001-overlayAct.xzm?
And can I merge it into 000-kernel?

Would that allow me to grab either upstream kernel (stable or current) merge the 001-overlayAct.xzm into a upstream 000-kernel module and be good to go?

Thanks in advance.

Post#8 by **roadie** » 08 Nov 2025, 16:30

rych wrote: ↑
08 Nov 2025, 05:58

roadie wrote: ↑
08 Nov 2025, 05:08
001-overlayAct.xzm

roadie wrote: ↑
08 Nov 2025, 05:08
activating .xzm modules can be a problem with overlay. All modules are still activated on booting.
The "problem" is that it simply cannot be done, we have to reboot if we want to deactivate a module for example? Or has there been a progress with overlayfs?

Good news that the 001-overlayAct.xzm even exists. Is there any noticeable performance difference between OverlayFS vs AUFS kernel patch though?

rych,

It's not accurate to say it simply cannot be done. I just booted Porteus v5.1 alpha3 into overlay, then attempted to activate modules from the /porteus/optional folder, 4 in all.

A Firefox module failed to activate to completion, by that I mean some files and folders were created, but it had issues with creating symlinks in my home directory. The other 3 modules all activated, opened properly, and deactivated without complaints or issues. The Firefox module also deactivated and removed the files it had created. The 001-overlayAct.xzm is in the base folder, so is activated on booting.

It worked the same in Porteus v5.01 and has for some years, so I don't believe anything has changed regarding progress to OverlayFS. As far as the running system, I really see no difference between Aufs and OverlayFS, just a difference in how changes are handled. I'll admit to not having a lot of experience with overlay, I've only used it as a fallback when aufs hasn't been available for whatever shiny new kernel I have an imagined need for. But were Aufs no longer available, I would have no issues whatsoever in using OverlayFS as a daily runner.

I build all my kernels to include OverlayFS as well as Aufs, then use a modified initrd to choose between them. I believe I liberated the code from one of neko's initrds, possibly in Aporteus. I think the Porteus community owes a lot to neko, whose work is outstanding.

EDIT:
It's entirely possible that I've tinkered with 001-overlayAct.xzm files, I am known to do such things. I don't recall though if I did, nor what I may have edited. I believe the original issue was in the clean unmounting of the modules. There is a thread in the Kernel Builder forum in which neko discusses it, I believe it has "Overlay" in the title.

Post#9 by **fu11m00n** » 08 Nov 2025, 16:50

@ roadie... thanks.

Can I use this for "overlayfs"...

https://slackware.uk/slackdce/packages/ ... ackdce.txz

Post#10 by **roadie** » 08 Nov 2025, 17:16

fu11m00n wrote: ↑
08 Nov 2025, 16:50
@ roadie... thanks.

Can I use this for "overlayfs"...

https://slackware.uk/slackdce/packages/ ... ackdce.txz

I really can't say, though I don't see why it would be needed as fuse can be included along with OverlayFS in the kernel on compiling. I've never had to use fuse-overlayfs. I was wrong about the location of 001-overlayAct.xzm, it's actually found in neko's Kernel Builder under /usr/local/share/mkKernel/lib/upkernel/base.

Post#11 by **fu11m00n** » 08 Nov 2025, 17:25

@ roadie... thanks.

I use SlackDCE as my primary source for 3rd party .txz packages so I thought it might be a good fit.
Like most of the 3rd party packages in my project it is a Sbo build.

My thinking is to use the Slackware official upstream kernel packages @...
https://slackware.nl/slakfinder/index.p ... e=#results

Then add the SlackDCE "overlay" package.

Post#12 by **roadie** » 08 Nov 2025, 17:36

fu11m00n,

I found an Aporteus .iso at this link:

https://www.mediafire.com/file/tlnub91y ... x86_64.iso

It contains an initrd which is setup to include OverlayFS booting. It's more "involved" than the initrd I use, mine is added to the linuxrc script.

Post#13 by **fu11m00n** » 08 Nov 2025, 17:37

@ roadie... thanks.

I will review this iso. I think it will reveal a lot of information.

Post#14 by **fu11m00n** » 08 Nov 2025, 18:35

@ roadie... thanks.

I checked out the iso. It seems based on Slackware current.
In 000-kernel it uses... /usr/lib/modules/6.14.0-rc-17-porteus.

Is there a Slackware stable version?

Post#15 by **roadie** » 08 Nov 2025, 18:53

fu11m00n wrote: ↑
08 Nov 2025, 18:35
@ roadie... thanks.

I checked out the iso. It seems based on Slackware current.
In 000-kernel it uses... /usr/lib/modules/6.14.0-rc-17-porteus.

Is there a Slackware stable version?

I can't say if a Slackware stable version is available as I use only source from kernel.org to build kernels. The 6.14 source is available there. I don't know if OverlayFS is configured into Slackware kernels and it seems doubtful that slackware would maintain an rc version.

I tend to avoid rc releases as issues can occur, such as the one that destroyed swap partitions some time ago, I don't recall the version. I emerged unscathed as I don't use a swap partition......I stopped using them then, as I'm fully able to create my own disasters, I need no help from anything else..