Moderators: kirk, jamesbond, p310don, JakeSFR, step, Forum moderators
Fatdog's official kernels are currently based on the longterm 6.1 line:
https://distro.ibiblio.org/fatdog/kernels/900/
On the official linux kernel website, I noticed that there is also a longterm 6.6 line and the current stable kernel is at 6.9.3:
Is there a specific technical reason why we are using the 6.1 line?
Would it be possible to upgrade the kernel to the 6.6 line or even create a recipe to compile always the latest stable kernel version for Fatdog?
Thanks for your feedback! 
Neo_78 wrote: Fri May 31, 2024 9:05 pmIs there a specific technical reason why we are using the 6.1 line?
Well, is there a reason why we should not? 
Would it be possible to upgrade the kernel to the 6.6 line
Yes. If you need it, you can ask someone to compile it for you, or you can compile it yourself (if I recall, you already asked for the instructions: viewtopic.php?t=7170). I didn't know what came out of that thread, though, since you never responded back. Did you attempt to build? Were you successful? Were you not successful? Or did you decide not to do it at all? Etc.
or even create a recipe to compile always the latest stable kernel version for Fatdog?
We don't have a recipe or an automated way to compile a kernel, latest, stable or otherwise. Every single kernel we release is hand-compiled with tender loving care
Puppy on the other hand, has an automated way to do it. It's called kernel-kit, and if you choose to build a "huge" kernel, the resulting kernel should be compatible with Fatdog as well. Just make sure you choose a kernel with aufs support.
Thanks @jamesbond. But there must have been a certain reason behind using the 6.1 line for FatDog 901 in terms of stability, available modules or other factors?
The thing is that I am always running FatDog in Ram-only mode and I am likely going to run out of space during the compilation process. Or could I simply connect an external USB pendrive to my system and have it compile to that larger storage location?
Thanks for your feedback!
@Neo_78 :-
Following Jim's comments, two in particular come to mind.......both of which fit your "requirements", and which I can confirm work well.
From @ozsouth :-
From @rockedge :-
I'm currently running the latter in a highly-modified/seriously-updated/heavily-customized Xenialpup64. Runs like a champion, and is a big step up from the original k4.9.58. It seems even smoother, too...
Jim can give better advice than I where renaming for FatDog's use is concerned.......so that FD's initrd will "see" the kernel and load it. That's FD-specific, and out of my ball-park.
~~~~~~~~~~~~~~~~~~~
There's no reason at all why you shouldn't give these two a try. Much as some of us try to pretend this forum consists of several small, isolated, self-contained communities who just happen to share server space, the truth of the matter is that all these "communities" in fact share much more than that; they also share a set of common practices & principles, and so often software compiled/built/packaged for one will function absolutely fine in another.
My own kennels is living, breathing proof of this. I source software from all over the place; .debs, .pets, .rpms, AppImages, occasionally FlatPaks, tarballs of all descriptions. Often, they'll work straight off, as they are.....sometimes they need a degree of modification, or re-packing.......but I will always attempt to test with 'vanilla' installs of our community Oses before I'll post about anything. With kernels, they're all interchangeable to a large degree; most used here on the forum get built with the WoofCE kernel-kit, and are thus packaged in the correct way for most of the related projects here.
And this is why, despite not running FatDog myself, I still occasionally post here.....because either something built for FD works well with many Puppies, or vice-versa turns out to be the case. At the end of the day, we're all here to either seek advice, dispense it, chat, converse or otherwise communicate with others who happen to have similar interests, and generally help each other......and I've always strongly believed that knowledge should be shared.
Mike. 
Neo_78 wrote: Sat Jun 01, 2024 8:34 pmThe thing is that I am always running FatDog in Ram-only mode and I am likely going to run out of space during the compilation process. Or could I simply connect an external USB pendrive to my system and have it compile to that larger storage location?
Yes you can, and in fact that's how most of us do it. Just make sure that the external USB is formatted as Linux filesystem (ext4 is fine).
mikewalsh wrote: Sun Jun 02, 2024 10:01 amMuch as some of us try to pretend this forum consists of several small, isolated, self-contained communities who just happen to share server space, the truth of the matter is that all these "communities" in fact share much more than that; they also share a set of common practices & principles, and so often software compiled/built/packaged for one will function absolutely fine in another.
Absolutely 
In addition, we also have "specialists" here who do or care for some particular functionalities, regardless of the underlying distros.
To mention a few: @rcrsn51 is the go-to guy for printing-related matters as well as boot guru (ref: ISOBooter), @Clarity is the expert on Ventoy and Samba related matters, while @ozsouth and @rockedge are prolific kernel builders. The list goes on and on.
mikewalsh wrote: Sun Jun 02, 2024 10:01 amFollowing Jim's comments, two in particular come to mind.......both of which fit your "requirements", and which I can confirm work well.
From @ozsouth :-
From @rockedge :-
This is an excellent suggestion.
I have tested this myself, and these two kernel work nicely with Fatdog
There is only one small hiccup: Puppies usually split kernel-modules.sfs into two parts:
- the "fdrv", containing the firmware blobs
- the kernel-modules proper
The rationale behind the split is that the firmware blobs are relatively big (about 100MB or so), and there is no point to carry the deadweight unless one really needs to use them.
Fatdog on the other hand combines both in its kernel-modules.sfs; as we are slightly less sensitive about size (that's why it is called Fatdog ).
Hence, to use Puppy kernels, all one needs to do is to combine the "fdrv" and the kernel modules together. This is very straightforward and can be done manually, but to make things even simpler, I will create a script to do this (this script will be included in the future release of Fatdog). there is a already tool to do it: mergelayers.
Download this tool, and then when you've downloaded the kernel-modules.sfs and the fdrv.sfs for the associated kernel that you want to use, simply run:
mergelayers kernel-modules.sfs fdrv.sfs new-kernel-modules.sfs
And the delete the original kernel-modules.sfs, replacing it the new-kernel-modules.sfs which you rename back to kernel-modules.sfs, and you're good to go!
And this is why, despite not running FatDog myself, I still occasionally post here.....because either something built for FD works well with many Puppies, or vice-versa turns out to be the case.
And I really appreciate those posts too, as I wouldn't pretend that I know everything. Especially with so many moving parts here in the forum, it's easy to miss the many details of progress that others have done. Why re-invent the wheel when we can re-use?
At the end of the day, we're all here to either seek advice, dispense it, chat, converse or otherwise communicate with others who happen to have similar interests, and generally help each other......and I've always strongly believed that knowledge should be shared.
And that, simply, is the reason for the existence for the forum; for were it not for that purposes, for what would the forum be?
Thanks for your input, guys! 
My idea was basically to learn how to compile a new FatDog-specific kernel that is as lean as possible. Will try to get this going and will report back if I encounter any problems.
Neo_78 wrote: Sun Jun 02, 2024 3:15 pmMy idea was basically to learn how to compile a new FatDog-specific kernel that is as lean as possible. Will try to get this going and will report back if I encounter any problems.
That sounds great, but if you have an itch or urge to use the other kernel branches __right now__, why don't you follow @mikewalsh's suggestion. As I said, I tested these two kernels myself, and they do work.
Ok, let me try rockedge's 6.9.1 kernel:
https://rockedge.org/kernels/data/Kerne ... -usrmerge/
I just downloaded the huge-6.9.1-fossapup64.tar.bz2 and as you mentioned it contains a vmlinuz and two sfs files.
So I would simply have to merge the fdrv and kernel-modules sfs files using mergelayers and I could then use the new sfs and vmlinuz during the remastering process as we discussed before, correct?
The sfs file is indeed quiet a bit bigger than the FatDog one...
Neo_78 wrote: Sun Jun 02, 2024 6:11 pmThe sfs file is indeed quiet a bit bigger than the FatDog one...
.....well, after all, that's why it's called a "huge kernel". Because it contains pretty much everything you could think of (and then some). I'd guess it's built with a much closer-to-bog-standard dot.config file.....in other words, far fewer items are filtered out at build time, thus giving a kernel that will work with many more machines without the need to "tinker".
And in all honesty, many more of us are using far more capable hardware than, say, a decade ago when I first joined this very friendly, helpful and surprisingly knowledgeable community. 8-16 GB of RAM is common-place now; quite a few of us are at the 32 GB mark - myself included - and I know of at least 2, if not 3 Puppians who are rocking 64 GB of RAM. And storage to match, an' all (for myself, this currently equates to some 5 TB+).
Space - at least for me - really isn't any longer the constraint (or "bottleneck") that it once was.....
I concur with Jim. The kernel-kit (or whatever you choose to use) will be quite happy running on an external drive, though it does of course help to have a decent amount of RAM for the process to function correctly.
Mike.
Hardware is getting more capable, but there are still many places in the world where supply is limited and you can be lucky to find a laptop with 8GB RAM. I am personally not a fan of this software growth trend and think that available resources should be utilized as efficiently as possible.
ozsouth's kernel seems to be smaller, but there appear to be different versions:
@jamesbond which version exactly have you tested with FatDog?
Neo_78 wrote: Sun Jun 02, 2024 10:05 pmHardware is getting more capable, but there are still many places in the world where supply is limited and you can be lucky to find a laptop with 8GB RAM. I am personally not a fan of this software growth trend and think that available resources should be utilized as efficiently as possible.
Oh, I'm with you there every step of the way. My current set-up is kind of a "knee-jerk" reaction to my previous machine; a hand-me-down from my sister, it was a very early, 64-bit single-core Compaq desktop machine with just 1 GB of DDR1 RAM. I upgraded the processor from a single-core (AMD Athlon64 3200+) to a dual-core, Athlon64 X2 3800+.....and maxed the RAM to 4 GB. But it was still pretty slow, and quite limited in what it could do.
That processor would have cost $1000 at launch, when it was brand new in 2003. I upgraded it for all of GBP £6.00 off eBay; when I bought it, it was already long past being scrap-heap material so far as most enthusiasts were concerned. Nobody wanted them, so I picked it up for a song. But; I was still limited by the DDR1 standard; slow, and no more than 4 GB (even with 4 slots, 'cos 1 GB was the maximum module size for that generation).
That was how I came to Puppy, because I needed something very lightweight which wouldn't tax it too hard.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fast-forward to today. The CPU in this HP Pavilion desktop rig was only $58 dollars at launch, yet it runs rings around that old Athlon; kicks dust in its face, and makes it look like a wimp (yet for all that, it was still very capable for its time, and showed Intel's Pentium 4 up for the heap of junk that it was).
And I'm talking as someone who had a P4 at one time, and thought way back then it was great! How times change.
(The current CPU is a Pentium G5400 dual-core w/Hyper-threading, so essentially a quad-core. This is a brilliant CPU. I'm not anti-Intel, nor specifically pro-AMD; in the early 2000s when the P4 was extant, Intel weren't in the best place they've ever been in.......since then, they've produced far better silicon.)
As for the 32 GB RAM, I was determined I was never going to be RAM-constrained ever again. This was the first year of COVID - the HP arrived in January, just before the global shenanigans kicked-off - and with all the "lockdowns", I had a fair old chunk of cash building up in the bank that wouldn't have normally been there. So I "splurged" a bit; 4 GB immediately became 8 GB, then a few months later I upgraded again to 16 GB, direct from Crucial. A few months later still, in November of 2020, I found a really good deal at Amazon; a 32 GB kit of Crucial RAM for less than half of what Crucial had charged me back in the summer for half the amount! I grabbed it, pronto.
I'm no longer a typical Puppy user, yet I stick with her because I like the way she does things; I'm very used to her, and know just what I'm doing......and I like the community spirit & enthusiasm. They're a good bunch here.
Mike.
@Neo_78 - There are some differences between my kernels & Fatdog's. The difference between my 2 variants is location of libau in the kernel sfs structure - slacko variant has this in /usr/lib64, ubuntu variant has it in /usr/lib. libau does not appear to be in Fatdog.
After downloading Fatdog 814 iso & examining it's structure, it mostly uses /usr/lib64, the slacko setup, so I assume that variant would the be best to use. A plain (not like bookwormpup) fdrv's /lib/firmware contents must be put in kernel sfs.
LATER: I made a 6.6.32 kernel, including a (hopefully) FatDog compatible version (slacko variant, with moderate amount of firmware inside kernel modules file). Update - now has all FD901's firmware +4 more files. See 5 posts down.
If you downloaded the prior one and are happy, no need for update.
Thanks @ozsouth! Appreciate it
Do you have sumcheck files for your kernel upload?
Could you explain a bit how you compiled the kernel specifically for FatDog?
The latest FatDog version is currently 901:
https://distro.ibiblio.org/fatdog/iso/
Thank you!
@Neo_78 - no checksum - haven't had any issues with bad downloads. As per previous post, I saw fatdog follows the slacko format, so made a generic slacko compile, using my updated 2018 kernel-kit (from which I've made nearly 100 kernels over the last 4 years), adjusted for fatdog by adding firmware. As jamesbond had previously said my kernels were compatible, all I wanted to do was assemble one in the right format, so as to be even more compatible & save you an extra step. If you're worried, make a separate install to trial it.
Thank you @ozsouth!
The earlier one that I test is from the link given by @mikewalsh, this is the 6.6.28, and I tested the Slacko version (at the time I test I didn't know the difference between the slacko and debian version, I guess it was lucky I chose the correct one). This one works well, boots in both qemu and real hardware (my laptop), and I'm typing this post under that kernel.
The latest 6.6.32 also boots up in qemu and real hardware, but on my laptop but I get a black screen, unless I blacklist "amdgpu" (I can still use Xorg by using the "fbdev" driver). My guess is that the reduction of the firmware accidentally removes the firmware needed for amdgpu to work, as the uncompressed size of the firmware in 6.6.28 is about 176MB vs 100MB in 6.6.32 (and I saw some amdgpu firmware are missing in 6.6.32).
But overall, very nice work, and very much appreciated
I remastered FatDog 901 both with rockedege's 6.9.1 kernel and ozsouth's new Slacko kernel for FatDog and loaded the remastered isos with Qemu from an external USB-drive:
qemu-system-x86_64 -enable-kvm -m 2048 -cdrom /mnt/sda/.../... .iso
Both kernels boot in Qemu without errors:
I have not been able to test them on real hardware though.
Thank you @jamesbond @ozsouth and @mikewalsh so far!
Will follow up on the related post on my progress to compile a kernel myself asap...
@jamesbond - I tried to keep my offering smaller, reasoning very few would use amd, so left that firmware out. I should have just used your FD901's firmware for consistency.
LATER: I updated 6.6.32 kernel, using all FD901's firmware (plus 2 more rtw89 & 2 more iwlwifi files). [Link Expired]
ozsouth wrote: Mon Jun 03, 2024 11:44 pm@jamesbond - I tried to keep my offering smaller, reasoning very few would use amd, so left that firmware out.
Understood.
I should have just used your FD901's firmware for consistency.
Actually this isn't necessary. I took your fdrv_03june24oz.sfs from your main release notes for 6.6.32, and then merged them with the (original/earlier) kernel modules that comes from your Fatdog kernel package. This combination boots off from the laptop now (typing this post with it). So no need for additional Fatdog-specific work other than merging the two.
But I see I posted this too late, because you have already done it anyway 
LATER: Updated 6.6.32 kernel, using all FD901's firmware (plus 2 more rtw89 & 2 more iwlwifi files) is here (92mb):
https://www.mediafire.com/file/iwupdnho ... r.bz2/file
I will test this too, but I'm quite sure it will work. Thanks again @ozsouth.
EDIT: This one still gives me blackscreen as soon as "amdgpu" is loaded.
In each of my QEMU stanza, they are structured such that upon distro desktop the distro sees a virtually real PC to match the varied PCs/laptops I test-use. Upon desktop, for all distro tests, I check for the following before posting results to the forum
desktop emergence (distros differ depending which -vga qemu parm in the stanza)
audio playback via the PCs speakers thru the Host OS
ability to see HOST shares to transfer files from the VM to the Host or access from the Host
internet navigation ability
session-management to save for reboot
These are essentials in my testing for forum reporting. Passing this, I have a good understanding of what to expect and look-for in bare-metal bootings.
James (or others), could you share your QEMU stanza when time permits. Mine are published across the forum.
Clarity wrote: Tue Jun 04, 2024 3:16 amcould you share your QEMU stanza when time permits. Mine are published across the forum.
I know what a grub stanza is, but what is a QEMU stanza?
Can you provide a link to the one that you published, as an example?
I think he is referring to the QEMU settings that are used to boot the VM @jamesbond.
From a kernel testing perspective it could be a good idea to use the same QEMU settings to compare results...
@jamesbond - FD901's firmware is missing 4 amdgpu files that are in my 3/6/24 fdrv. I made a .pet to install them, after which you would need to run xorgwizard & try amd driver. Or it may be that the my 6.6 kernel needs versions in my fdrv, in which case, copying my fdrv's amdgpu folder contents into FD901's /lib/firmware/amdgpu should work.
.
fdx-amdgpu.petHi @jamesbond
This is a stanza used for terminal launching a virtual PC. (IIRC you use a different VM product versus QEMU, "I think'). It is used in the VM example reports I provided in the past.
qemu-system-x86_64 -name "FD v901" -enable-kvm -smp 2 -m 2048 -vga std -device AC97 -net nic -net user -rtc base=localtime -boot order=d -cdrom /mnt/sdb1/BOOTISOS/Fatdog64-901.iso
The above stanza is used no matter which host I run it on. All of my current production hosts have QEMU version 7.2 installed while I have tested QEMU v8 & v9 in several test hosts using the same stanza for VM launch.
I find that if FD boots to desktop with this VM stanza, the FD ISO file will always boot, bare-metal, on ALL these aged PCs I have. This has been tested using the OOTB FD901 ISO as well as a FD901 remaster ISO, done few months back, to test.
I had asked as I was thinking you might have run a QEMU boot of a VM; and I wanted to compare your stanza with the one I use for FD tests.
Thank you @ozsouth, I will test that and get back to you.
@Clarity, I don't have such "stanza" as you call it. For casual tests, I just run qemu-system-x86_64 -enable-kvm -m 2048 with other parameters appropriately added depending on the situation (-hda, -hdb, -cdrom, -bios, -vga, etc).
For more serious testing, I have scripts that can run the ISO, or load the kernel+initrd+basesfs directly (skipping the lengthy part of the bootloader loading the OS). But again the parameters passed to qemu in these scripts are variable, depending on what I want to test. The scripts are called "runiso.sh" and "runsfs.sh" and you can find them in one of the Fatdog64 ISO builders package, from here: http://distro.ibiblio.org/fatdog/iso/builder/
These scripts are mainly meant for testing Fatdog ISOs and nothing else, though.
Thanks for sharing your QEMU that you use for your testing.
As a developer, I agree with you, entirely. As a 'testor', my needs are to determing media ability of the distros at their desktop and their ability to find and navigate a network. Further, and very important, IMHO, is the ability of session-management capability and former sessions being found+used upon reboots without issue. FDs in my past testing check ALL the boxes in VM tests mentioned.
My findings show that the FD ISO file(s) can be launched and booted correctly in either bare-metal, VMs, or PXE from all of the ISO Boot Launchers tested on the forum ... without FD desktop or operational issues.
Thanks for sharing!
From 1/6/24:
Is there a specific technical reason why we are using the 6.1 line?
Well, is there a reason why we should not?
Today (1/7/24):
- When linux-v6.10 is released, aufs6.1--aufs6.5 will get the end of life and will not be supported.
Aufs landscape is changing sooner than expected.
Clarity wrote: Wed Jun 05, 2024 4:13 am... All of my current production hosts have QEMU version 7.2 ...
a) What exactly is a 'production host' ... and
b) what are you producing? ... anything I can reproduce on my system? 
These are the PCs I use for testing the forum distros for ISO file boot behaviors.
Its just a personal name I call them. The hosts are sometimes FATDOG versions and sometimes BKWP64, of late. QEMU is the VM manager that run for booting test VMs.
