6.2.9 64bit PREEMPT Knl SUPERSEDED

[ozsouth]

Superseded

[Marv]

Briefly tested in both LxPupSc64 23.01 +2 (slackware version) and in jammypup64 D3 (path adjusted ubuntu version). Normal boot, clean dmesg, excellent idle resource use, and very good glxgears FPS in both.

Hardware is a non-UEFI Fujitsu S761 all intel laptop, 2nd gen i5 circa 2012, 6GB RAM, frugal installs to Samsung EVO 850 SSD.

In LxPupSc64, used OOTB with the existing savefile backed up and cleaned before boot. No issues noted, multimedia tests not done.

In upup-CE_D3 (jammypup64), two caveats.

First: The paths must be adjusted for the 'symlinked lib and bin/sbin structure'. I do it manually, just unsquashing the zdrv and moving the
contents of /lib and /sbin into /usr/lib and /usr/sbin, then deleting the /lib and /sbin directories and resquashing. In upup D3,
@jrb has a neat script in the boot directory, zdrv_cp2deb, that does the conversion when a zdrv is dragged onto it.

Second: Since this kernel defaults to AUFS, to run upup in overlayfs punionfs=overlay must be passed as a kernel parameter in the
grub4dos menu.lst, the grub.cfg, or the syslinux.cfg. jammypup64 will run in AUFS or overlayfs modes but the savefiles for the two have
completely different structures. I run jammypup64 without a savefile or folder but just to keep my wits somewhat about me always run it in
overlayfs.

Boot was clean in jammypup64 D3, as in LxPupSc64, clean dmesg, excellent idle resource use, and very good glxgears FPS. I also tested installing to and booting from a 4GB USB2 flashdrive using StickPup. No issues seen there either other than the need to manually add the punionfs=overlay kernel parameter to the grub.cfg file. Again, I only have non-UEFI hardware to test on.

Sorry for the length but I tried to be explicit. And

Thanks

[peebee]

WARNING:-
OLD-STYLE KERNELS & FDRVS SHOULD NOT BE USED WITH WOOF-CE PUPPIES CREATED AFTER 2022.
STRUCTURAL CHANGES WILL LIKELY CAUSE CORRUPTION.
EXCEPTIONS: s15pup64-22.12 +1 to +3 AND F96CE-3 seem OK.

For clarification..........

kernels which are not "usrmerge" are not "old-style" they're just not compatible with builds which are "usrmerge" - i.e. mainly Debian/Ubuntu

and not all Woof-CE pups are "usrmerge" - just a few - and those few don't need to be, its just that the developer has decided to build that way to make them "more compatible" with the donor distro.

For instance as well as S15Pup64, VoidPup64 is not "usrmerge" even though VoidLinux is (but not exactly in the same way that Debian/Ubuntu is).
BTW Slackware is relatively sane and is not "usrmerge".

It's one of the things that I think Linux has got wrong - the multitude of different 64-bit lib and bin schemes - 32-bit is much more consistent!

[Jasper]

@ozsouth

Thank you again for sharing this with us

It was only released on 30 March, so pleased to be able to try it out so soon.

[Marv]

It's one of the things that I think Linux has got wrong - the multitude of different 64-bit lib and bin schemes - 32-bit is much more consistent!

Amen! And to snitch a bit from Alexander Mccall Smith, perhaps "Traditionally built" instead of old style

[ozsouth]

I guess -'Old-Style' was a simple way for me to underline that my method isn't the latest.
It's based on Kernel-Kit Master 2018, to which I've applied only my essential-for-operation fixes, & I
use the aged ntfs-3g. Hence, in that sense, it is old.
I also feel 'usrmerge' is likely to get more pervasive, due mainly to upstream package compatibility.
Slackware remains systemd & usrmerge free, & peebee's derivatives remain my favourites.
Maybe 'Traditional' would be better name. I'll muse over that, as June is my next intended offering time.

[debianfan]

Very good, thanks for sharing

[ozsouth]

Old-Style was not accurate, so my kernels now will be called 2018-KIT, reflecting the fact that I use Kernel-Kit Master 2018 version, with only my essential-for-operation fixes. Have amended main posts referring to that.