6.10.14 64bit Kernel USRMERGE Hi-Freq Overlayfs-Only with Spectre v2 fix

[ozsouth]

I made a 64bit 6.10.14 2018 KIT USRMERGE Hi-Freq Overlayfs-Only kernel.
Has many input devices & more drivers set. Runs my new Ideapad Slim 1i well.
I made this as, unlike 6.11, this DOES allow rolling down of firmware versions.
(means you don't have to have the latest, only a recent version, so my fdrvs below ok).
This has the spectre v2 BPF fix.

This is for Jammypup64 & later (USRMERGE Pups) & CANNOT be used for Fossapup64 or S15pup64 & older.
'umovx' means usrmerge, overlayfs. x = extras.

Used gcc 11.2 & glibc 2.33. Has Voluntary Preemption & Frequency 1000Hz. Use at own risk.

Has no firmware - fdrv linked at bottom of post has some rtw88, rtw89, b43 & mediatek wifi firmware.
Kernel has some rtw88, rtw89, b43 & mediatek wifi drivers. Has older ntfs-3g, vmd & Blake2s builtin.

Missing firmware is a big issue these days. That will stop devices running, even if driver is present.
To see if any is missing, in a maximised terminal run: dmesg | grep irmware
A source of extra firmware is here: https://github.com/endlessm/linux-firmware
For usrmerge pups (jammypup64, bookwormpup64, noblepup64 etc), files go in /usr/lib/firmware.
For all other pups, files go in /lib/firmware.

Is mostly Spectre/Meltdown mitigated (needs microcode too - see viewtopic.php?p=9658#p9658).
If this kernel is used for Bookwormpup64, use it's fdrv - has microcode already & add .no to end of kbuild.sfs.
Is TCP_SACK mitigated. Briefly tested, OK in Noblepup64-low.
For best results when using a savefile/savefolder, it is advisable to have that on an ext3 (or 4) partition.

wl wireless driver in forum Drivers section. NOTE: many broadcom devices can use
in-kernel b43 drivers. fdrv below has newer broadcom firmware to work with that.

Once downloaded, expand in an empty folder with tar -jxvf, & rename kernel-modules.sfs-6.10.14-64oz-hf-umovx to
zdrv ... (same as one to be replaced) & rename vmlinuz-6.10.14-64oz-hf-umovx to vmlinuz & then substitute for originals. If kbuild... sfs exists, must be disabled before first bootup (I add .no to end of filename).

Important Note: when switching kernels, if you have an ...initmodules.txt file (i.e. fossapup64initmodules.txt or
similar, in same folder as puppy sfs), must delete it before first boot into new kernel. Otherwise it may try to load modules that don't exist, causing failure.

Kernel: https://archive.org/download/Puppy_Linu ... vx.tar.bz2

Sources: https://archive.org/download/Puppy_Linu ... -umovx.sfs

Headers: https://archive.org/download/Puppy_Linu ... x86_64.sfs

My 28oct24 med USRMERGE fdrv (65mb): https://www.mediafire.com/file/cxdv3gla ... m.sfs/file
My 28oct24 lowmed USRMERGE fdrv (36mb): https://www.mediafire.com/file/kk0m8ztv ... m.sfs/file

[mikolaj_q]

Thank You for the kernel

I have strange issue and do not know how to fix this. If I change kernel as You described my system starts completely new session (do not use save folder). If I undone changes - replace the kernel with original one everything come back to normal.
How to explain this behavior? Maybe the issue is that I am using f2fs for puppy files and save directory? Also new directory called "upper" appears in my main directory (/upper)
Any help would be appreciated

[ozsouth]

@mikolaj_q - which puppy are you using? This kernel is only for overlayfs. Upper means when you booted, overlayfs tried to start. An aufs puppy doesn't have this. You cannot have an aufs savefile/folder in the path when booting overlayfs.

[mikolaj_q]

This happens with BookwormPup and NoblePup. I did not change location of savefolder, it is in default place.

[ozsouth]

@mikolaj_q Bookworm64 & Noble64 work fine with this. I suggest you move your savefile/folder elsewhere, so the new kernel can't access it. Aufs & Overlay saves can't be shared. Also, references to the old kernel remain in them unless you move them.

[mikolaj_q]

Ok, I did a fresh NoblePup installation, didn't run it, replaced kernel with 6.10.14, then boot it and the new kernel works. So the first boot was with new kernel. But during next boot again I see "upper" directory. There are two filesystems instead of one, am I right? Is this normal desired behavior or something is wrong with my set up?

[rockedge]

If you are seeing the directories /upper and /work this means the overlayfs system is being used and not AUFS

[bigpup]

@ozsouth

I thank you for offering newer kernels to use!

However, you need to update firmware provided by your fdrv.sfs that could be used with them.

Most of what a newer kernel is providing is support for newer hardware.

For it to fully support the hardware, it also needs to have the firmware for the newer hardware.

I know it is a balancing act just what firmware to have in the fdrv.
So do understand if you do not have every possible one in it.
WIFI hardware, seems to be the firmware needed the most.

Example:
I used one of your 6 series kernels to get a very new WIFI adapter working.
The kernel had the driver for it already in the kernel.
But your fdrv (65mb) did not have the firmware needed.
I found the needed firmware and added it to the operating file system, which put it into the save.
WIFI adapter is now working.
But I would have liked it better for the firmware to be in the fdrv and not dependent on adding it to the OS by loading the save.

[ozsouth]

@bigpup - firmware is a huge issue now. A complication with 6.11 kernels is I found rolldown no longer worked - previously, if you had a firmware version (say) 5 below the requirement, it would eventually be found & used. 6.11 demanded exact file only, so every new piece of hardware would need a new firmware file. Makes generic fdrvs virtually redundant.
So many new, big files, it's hard to know what to include, so I'm adding the following to my latest kernel announcements, whilst keeping basic sets which I'll review periodically:
Missing firmware is a big issue these days. That will stop devices running, even if driver is present.
To see if any is missing, in a maximised terminal run: dmesg | grep irmware
A source of extra firmware is here: https://github.com/endlessm/linux-firmware
For usrmerge pups (jammypup64, bookwormpup64, noblepup64 etc), files go in /usr/lib/firmware.
For all other pups, files go in /lib/firmware.

[mikolaj_q]

@mikolaj_q Bookworm64 & Noble64 work fine with this. I suggest you move your savefile/folder elsewhere, so the new kernel can't access it. Aufs & Overlay saves can't be shared. Also, references to the old kernel remain in them unless you move them.

I thought Bookworm64 & Noble64 use only Overlay. Do not understand why You call Aufs.

My desired result is to use the new kernel with Bookworm64 or Noble64 with previous settings and changes from savefolder and I can not achieve this/do not know how. Replacing vmlinuz and zdrv is not enough because, as I described previously, it cause fresh session start with no savefolder changes.

[mikewalsh]

@mikolaj_q :-

The reason ozsouth has suggested you move your save-file/folder so it can't be found & used is quite simple. I understand your desire to use a newer kernel with your existing setup; for years this has been how we've always done it......but since the 'usrmerge' introduction, it's simply not possible anymore.

The file-system is now laid-out differently.....and the recent kernels are now built to expect this new type of layout. Anything in your old "save" will just be ignored, because the most critical component of any Linux OS build - the glibc, along with the associated "linkers" - will NOT be found in its expected location. So nothing will function.

With the new way of doing things, obviously safeguards have been put in place to detect & warn about this. It's a case of "sod's law", I know, but we just have to accept and work with the new system as best we can. Anybody choosing to stay with a pre-usrmerge system should have no problems. Anybody running a post-usrmerge Puppy & setting everything up again from scratch will have no problems.

It's only those wishing to use a post-usrmerge kernel with an existing pre-usrmerge file-system'n'stuff - like you - who will have MAJOR issues. Not to mention the aufs/overlay thing.....which is an entirely separate issue, though the two DO have to be combined & adjusted for in any NEW kernel build. And this is why there is such a complex and varied selection of kernel builds to choose from now.

Hope that "clarifies" thing a little bit further for you..?

Mike.