6.12.6 64bit Kernel Non-Usrmerge Aufs/Overlayfs - modified Debian config

[ozsouth]

I made a 64bit 6.12.6 2018 KIT Non-Usrmerge Aufs/Overlayfs kernel, using a modified Debian config.
Like all 6.11 & 6.12 so far, this does NOT allow fallback for newer iwlwifi firmware versions.
(means you have to have the latest, so my fdrvs below ok for now).
This has the spectre v2 BPF fix.

This is for Fossapup64 or s15pup64 & similar. Is NOT for Jammypup64 & later (USRMERGE Pups) unless you
run ubuntu derivative through a converter like this one: viewtopic.php?p=116744#p116744
'aoed' means aufs/overlayfs; either non-usrmerge, or usrmerge if run through converter. d = Debian config.
To run it with Overlayfs, must have special initrd.gz (older pups) or specify punionfs=overlay in
grub.cfg/syslinux.cfg (newer pups).

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

Has no firmware - fdrvs linked at bottom of post have some rtw88, rtw89, b43 & mediatek wifi firmware.
Kernel has some rtw88, rtw89, b43 & mediatek wifi drivers. Has 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), BUT
if this kernel used for Bookwormpup64, use Bookwormpup fdrv at link below & add .no to end of kbuild.sfs.
Briefly tested, OK in s15pup64_22.12+4 (aufs & overlayfs).
For best results when using a savefile/savefolder, it is advisable to have that on an ext3 (or 4) partition.

wl wireless driver is in forum Drivers section. NOTE: many broadcom devices can use
in-kernel b43 drivers, but needs firmware (links below).

Once downloaded, expand in an empty folder with tar -jxvf, & rename kernel-modules.sfs-6.12.6-64oz-aoed to
zdrv ... (same as one to be replaced) & rename vmlinuz-6.12.6-64oz-aoed 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. dpupbw64initmodules.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.

For compiling, a separate install should be used, with no savefile/savefolder & devx in same folder as puppy...sfs.

Notes for Overlayfs: either kernel derivative below works on any system. Devx, if named in same convention as puppy sfs for that pup, will load on boot, if in the same folder as puppy sfs. If devx loaded on the fly, compiling will fail, so best to have a separate install just for compiling, with no savefile/savefolder, naming kernel sources as ydrv & rebooting.
Also, savefolders/files cannot be shared by aufs & overlayfs, due to different structures.

Ubuntu derivative Kernel: https://archive.org/download/Puppy_Linu ... ed.tar.bz2

Slacko derivative Kernel: https://archive.org/download/Puppy_Linu ... ed.tar.bz2

Sources: https://archive.org/download/Puppy_Linu ... z-aoed.sfs

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

A collection of my latest fdrvs is here (must rename fdrvs to suit puppy to be used):
viewtopic.php?p=121635#p121635

[nocsak]

Hi ozsouth!

I tried to interpret what you wrote, I'm not saying that I got it all right because there are a lot of things that I don't understand at first, but maybe it's just because I'm not that professional. I created an SF project not long ago, I can't decide whether it will be to my advantage or disadvantage in the future. I usually upload ucode.cpio files there, zen-patched HUGE kernels for puppy linux, and fdrv sfs packages that contain everything uncut. On my machines, dmesg doesn't show any errors, although I should add that I don't usually use iwlwifi because none of the kernels I have can really handle what I have. The reason I'm writing now is that if any information from there is helpful to you or anyone else, I hope it's useful, and I'll also test your kernel, to see if it can do a little more than the previous ones. You can see my kernel configurations in the /etc/modules directory. I usually turn on all mitigations and use the latest ucode.cpio, including fdrv. But I also have some questions:

what is TCP_SACK mitigation, and where can it be applied in menuconfig?

If you don't mind, I may have more questions in the future, but my goal would be to implement a well-functioning kernel+fdrv+ucode.cpio setup for anyone. In the meantime, I'll read your comment a few more times to get a clear picture of what you wrote. I'm still learning the way how to compile a good and suitable huge kernel, and I hope my ideas can help you all in the future as yours help me to learn also.

I've used Google Translate to faster writing this post. Excuse my English if I had some grammatical mistakes in that!

---Edit---2024-12-20-CEST-22:06---

Okay I show my screenshots to you about your kernel's dmesg output on my main Puppy PC:
(First I have no unique error line in complete dmesg output, firewall setup seems OK too, ucode.cpio has been applied with mine and with my custom fdrv.)

0001.gif (203.69 KiB) Viewed 226 times

0002.gif (76.68 KiB) Viewed 226 times

dmesg_.gif (45.83 KiB) Viewed 226 times

In the meantime, I'll study your kernel configuration.

Thanks and best wishes!

[ozsouth]

@nocsak -
tcp_sack mitigation is actually an in-kernel change from some years ago. I probably don't need to mention it now (removed).

Your microcode does not appear to be properly enabled, or is outdated, as your post shows many vulnerabilities.

The link below has a working early-loading ucode, a checker & method.

viewtopic.php?p=9658#p9658