Can we use Cannonical's prebuilt kernels?

[Jasper]

Hi all

Cannonical (Ubuntu) build's kernels and they can be accessed here:

https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

Personally, I do not know how to compile kernels, however if they could be used it might take away some of the "heavy lifting" ?

Or is this not advisable/possible?

[mikewalsh]

@Jasper :-

I'm guessing you're another who believes it's safer to use a step-wise series of kernel releases, i.e., every kernel build as it's released, yes? Because that's what Ubuntu do.

As to advisable? Umm; well, I too am no expert, but I think you'd have issues with the aufs stuff that most Puppies still use. I know overlayfs is now standard in the kernel, and there have been a number of experiments with it so far, but it's nowhere near ready for "prime-time" usage across the kennels. Not yet.

Full marks for thinking of it, certainly, but nothing is ever quite as simple as it first appears. Wait and see what those that DO know about such things have to say for themselves; their input will be far more useful than mine. Remember; many Puppies may be based on Ubuntu.......but Puppy is NOT Ubuntu, and does a lot of stuff in its own unique, inimicable way.

And Canonical constructs its packages to suit the way Ubuntu works.

(*shrug*)

Mike.

[pp4mnklinux]

Is it sure use a Beta versión of puppy?

Of course, but there will be errors.

The same for the kernel, I think.

[Jasper]

@mikewalsh

I only have used incremental kernel updates as I realised some hardware is not supported.

I know the latest builds of Mesa do not support my onboard graphics and is only available to me via their Amber branch of development.

I think @fredx181 in the KLV dev subsection had created a workaround for the aufs/overlay using Fuse. I do not use this build so do know of its usability/functionality, however it does make for interesting reading.

Also, got me to thinking if older Puppybuilds had VA-API activated/being used. It has been available since 2007 and shifts the workload onto the GPU. Which would be of good use for browsing online. Most modern browsers do include an option for hardware acceleration.

[mikewalsh]

@Jasper :-

Mm. Yeah. With regard to the VAAPI stuff, it's probably not a lot of use until you get to the point in time where integrated GPUs began to move onto the CPU die, creating what were known at the time as APUs (Accelerated Processing Units).

I say this because, in all honesty, prior to that point integrated graphics chips were pretty simple beasts, supporting relatively few rendering pipelines (these are where VAAPI will "offload" stuff to). After the arrival of APUs, on-die GPUs began to develop quite fast, to the point where most were getting to be comparable in performance with an "average" bread'n'butter discrete (separate) card.

Most folks still use on-die or integrated graphics......with these, VAAPI is hardly worth enabling. Discrete GPUs are still not THAT common outside of the enthusiast communities, and certain "niche" communities that some manufacturers have 'created' to try and 'showcase' their products.

--------------------------

I ended up with my own Nvidia card through circumstance. When I first got this HP desktop rig at the start of the pandemic, it only had 4 GB RAM.....and the on-die Intel GPU would claim a chunk of that. I'd just had several years of struggling with a mere 3 GB RAM, and no way was I going back to that. So the GT 710 was roughly equivalent to the Intel GPU in performance, but more importantly it had its own 2 GB of VRAM, so wouldn't 'poach' system RAM to use for its own devices.

As it happened, finances permitted me, during the course of that year, to upgrade the RAM to the point that, by year's end, 4 GB had 'morphed' into 32 GB (the max for this mobo).

I do use VAAPI with the Ungoogled Chromium portable build, because 'Marmaduke' has enabled it in his compile.....and the GT 710 has enough rendering engines to make it worthwhile.

Just my two-penn'orth, FWIW.

Mike.

[peebee]

https://github.com/puppylinux-woof-CE/w ... iffconfigs

117 kernel config differences

resulting builds:
https://github.com/puppylinux-woof-CE/w ... kernel.yml

note: overlayfs only and usrmerge

[Jasper]

@peebee

Thanks for sharing this information. To be honest, I am a little unclear in my understanding.

I see a reference to 20.4 (Fossa Focal) but the workflow is for Upup (Jammy Jellyfish).

There's no excuse for my ignorance. I should make the effort to understand this.

[dimkr]

Puppy kernels must be built with various drivers built-in, rather than loadable after the initrd.gz stage. Otherwise, the init script in initrd.gz can't see devices, can't see partitions or can't mount the file systems on the partitions.

However, I don't agree with this statement:

Puppy is NOT Ubuntu, and does a lot of stuff in its own unique, inimicable way.

Why? Because although Puppy can't just use prebuilt kernels from other distros and depends on some configuration options, the delta is small.

https://github.com/puppylinux-woof-CE/w ... .13-x86_64 is what @peebee's 6.1.x kernels are built with and contains 9625 lines (good luck maintaining this over time ), while https://github.com/puppylinux-woof-CE/w ... s/bookworm is only 125 lines that change the Debian defaults unsuitable for Puppy to what Puppy needs. Everything else is taken as-is from Debian, and the kernel is even built from the Debian kernel source without external patches like aufs: if Debian doesn't update from 6.1.x to 6.1.x+y because the latter introduces a regression, dpup stays on 6.1.x until the Debian update is out.

(And normally, Debian doesn't update from 6.1.x to 6.1.x+1; the kernel goes through QA and regression tests, hence the jump from 6.1.12 to 6.1.15 and then 6.1.20)

(And this delta-based approach is easy and future-proof, great fit for a volunteer-driven distro like Puppy - https://github.com/puppylinux-woof-CE/w ... 8bb62d70c1 is a two line change that fixes an issue reported in the jammy64 thread, and it will be super easy to ensure this issue doesn't return in the future)

Similar story with 5.15.x and jammy64. https://github.com/puppylinux-woof-CE/w ... 5.4-x86_64 is 10079 lines, while https://github.com/puppylinux-woof-CE/w ... figs/jammy is only 117 lines. If Ubuntu 22.04 doesn't receive the update from 5.15.x to 5.15.x+y, jammy64 stays with 5.15.x until this update reaches Ubuntu 22.04. However, Ubuntu 22.04 has the aufs patches applied but aufs is disabled (= not built) while this Puppy secret sauce enables aufs, so sticking with the Ubuntu 22.04 kernel sources does not guarantee extra stability, as aufs is a known source of instability and Canonical doesn't do any QA for a disabled feature.

Rebuilding the kernel from Ubuntu with minimal customization on top is the best we can do, with Puppy's architecture today.

If anyone makes Puppy's init script capable of loading kernel modules using mdev (or some other solution) and adapts woof-CE so it can unpack the Ubuntu kernel and put drivers for block devices, USB, file systems (...) inside initrd.gz, prebuilt kernels should work fine. To be honest, this is in my TODO list - I'm trying to reduce dpup's maintenance burden and constantly sharpen the project's focus.

[Jasper]

@peebee much kudos to you for all the hard work you do to maintain and create your Puppy builds. Wow, it sounds like a full-time job to me

@dimkr
Thank you so much for your informative explanation and the same applies to you.

I did see the Delta application in JammyPup and was unsure as to it's usage and then looking back again at Peebee's work, he too also provides Delta files.

For testing purposes previously, I had added the Upup DevX inside the boot files (where the other SFSes reside) and had expected that upon boot up it would load this automatically. I did check the SFS overlay tool (can't remember the name but within the menu), but this did not list the SFS as being available. Human error on my part I would believe as I am not sure/confident as to it's normal behaviour. Progress seems to involve a learning process hahahhaa

In regards to your offerings these include rolling updates (?) So, these have the option of whether or not they should be applied?

I still have my ChromeOS notebook stuck in the cupboard and I know that runs Debian 11 (?). Maybe it is time I took it out and familiarised myself with the OS.

Thanks to all

[mikewalsh]

Puppy kernels must be built with various drivers built-in, rather than loadable after the initrd.gz stage. Otherwise, the init script in initrd.gz can't see devices, can't see partitions or can't mount the file systems on the partitions.

However, I don't agree with this statement:

Puppy is NOT Ubuntu, and does a lot of stuff in its own unique, inimicable way.

Why? Because although Puppy can't just use prebuilt kernels from other distros and depends on some configuration options, the delta is small.

https://github.com/puppylinux-woof-CE/w ... .13-x86_64 is what @peebee's 6.1.x kernels are built with and contains 9625 lines (good luck maintaining this over time ), while https://github.com/puppylinux-woof-CE/w ... s/bookworm is only 125 lines that change the Debian defaults unsuitable for Puppy to what Puppy needs. Everything else is taken as-is from Debian, and the kernel is even built from the Debian kernel source without external patches like aufs: if Debian doesn't update from 6.1.x to 6.1.x+y because the latter introduces a regression, dpup stays on 6.1.x until the Debian update is out.

(And normally, Debian doesn't update from 6.1.x to 6.1.x+1; the kernel goes through QA and regression tests, hence the jump from 6.1.12 to 6.1.15 and then 6.1.20)

(And this delta-based approach is easy and future-proof, great fit for a volunteer-driven distro like Puppy...)

@dimkr :-

Fair comment, Dima. Appreciate the clarification. Like I said to Jasper, I'm no expert in such matters, and only have the average layman's grasp of what a kernel really does.

As I stated above, kernel-building is NOT on my radar - there are so many already-available Puppy kernels that I've got no need to try my hand at building my own - so my statement was almost guaranteed to be inaccurate. And, as with any community, the individual members between them contribute to the whole, each in their own way.......we can't all of us be good at everything.

(It's never even been on my "bucket-list"; I've never had the itch to compile my own kernel, so that I can cross it off and say, "Well, at least I tried it...")

Sorry an' all that!

Mike.

[mikewalsh]

@peebee
There's no excuse for my ignorance. I should make the effort to understand this.

@Jasper :-

Don't beat yourself up over it. Most of us have perhaps a basic understanding of the majority of what makes a Linux OS "tick". Relatively few have the interest and/or determination to try and master everything....

We all have our strong suits.....and we all of us have our "bête noir", too!

Hence the saying, "He was a 'jack-of-all-trades', yet a master of none". That probably describes better than 90% of the human race...and I guess it scales downwards to a small community like ours, as well.

Mike.

[dimkr]

I did see the Delta application in JammyPup and was unsure as to it's usage and then looking back again at Peebee's work, he too also provides Delta files.

When I used to the word "delta", I used it to describe https://github.com/dimkr/woof-CE/blob/b ... figs/jammy, and not delta updates.

This file is just the 117 configuration options Puppy needs, and not a complete kernel configuration file (hence the word "delta"). The jammy64 kernel is built by taking the Ubuntu 22.04 kernel source (with Canonical's patches, after Canonical's QA) and changing only 117 lines (out of thousands) in the Ubuntu configuration file, to suit Puppy. It's easier to maintain only 117 lines and not a complete configuration file.

[Marv]

This file is just the 117 configuration options Puppy needs, and not a complete kernel configuration file (hence the word "delta"). The jammy64 kernel is built by taking the Ubuntu 22.04 kernel source (with Canonical's patches, after Canonical's QA) and changing only 117 lines (out of thousands) in the Ubuntu configuration file, to suit Puppy. It's easier to maintain only 117 lines and not a complete configuration file.

Any chance of changing CONFIG_INPUT_EVBUG=m as it is in most of the Canonical kernels to # CONFIG_INPUT_EVBUG is not set as it is in 'most' puppy huge kernels I have used. In some of my hardware/software configurations evbug floods dmesg with error messages, making it pretty much unusable. This has been around for some time and simple blacklisting doesn't reliably take care of it. I just hide evbug.ko with a line in my rc.local when it happens.

Thanks,

[wiak]

Hi all

Cannonical (Ubuntu) build's kernels and they can be accessed here:

https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

Personally, I do not know how to compile kernels, however if they could be used it might take away some of the "heavy lifting" ?

Or is this not advisable/possible?

Both DebianDog and KL distros can use either type of kernel, being huge kernels that include boot media drivers all built into the kernel, and upstream kernels, which need modules included in the initrd. In the past DebianDogs, like Puppy Linux, relied on aufs so needed to patch the kernel anyway (though didn't tend to use huge kernels builds). Current KL distros use FirstRib initrd, which was designed (from the start in early 2019) with support for either huge kernels, or upstream mainstream kernels, and has always used overlayfs (either inbuilt or as a modules read by initrd) and never aufs. Nowadays, we tend also use a piece of code from (EDIT: Tomas) M of Slax to cut the modules down for inclusion in the initrd when huge kernel not being used. Huge kernels are nice though since makes distro building easy and allows use of a slim skeleton initrd that needs no modules included. Having said that, as you say, the heavy lifting has been done by well-resourced upstream kernel releases, which we generally can trust to be well maintained since big dev teams - so nice indeed to be able to use these. @rockedge has been using official Void Linux kernel often in his KLV-Airedale releases (with needed boot modules carefully inserted via build script into the skeleton FR initrd), but sometimes he's used huge kernels instead, built by himself or others. In my own FR distros I tend to use upstream official kernels, but for the KL variants I've contributed thus far I've included huge kernels originally made for Puppy Linux. Puppy initrd, thus far, relies on huge kernel though no reason a similar approach to KL/FR could not be adopted as an option.

In practice, it is perfectly fine to use official kernels with KL designs; the initrd is easy to make and ends up only swelling the iso size by around 10MB, but with the advantage of that upstream 'heavy lifting', and lots of big team testing. One of the only things upstream (main distros) don't do or do well is to produce an initrd that is designed to work great for frugal install facilities such as we are used to here. Some non-forum distros do that pretty well too (Porteus, Slax, AntiX to name but a few) but so-called 'live' isos from mainstread tend to be limited in flexibility/functionality because really just designed to allow quick mainstream distro test prior to full install.

Running multiple distros (and/or big apps) inside containers (docker, podman, kubernetes etc) is popular upstream nowadays (and can 'I think' include save on demand type versatility; I'm experimenting...) - and virtualisation using the likes of Vmware, Virtual box, and Qemu another way of running multiple different distros: containerised approach presumably more efficient than full virtualisation approach though. I don't think most home users maybe using containers much yet (though are using AppImages, Flatpaks, Snaps of course), but maybe because the technology remains a bit confusing to most of us - that's going to change though. EasyOS of course brings in its own unique containerised approach though as far as I understand that it can only run Puppy inside its containers, or individual apps like browsers, and not other distro types at the moment - nothing per se to do with whether we use huge kernels or not though, but may become an alternative to some of the flexibility frugal installs give us more generally.

[Jasper]

@wiak

Thank you too for providing such a clear understanding of the process of compiling and using kernels.

The different scenarios will make me look again at the developments being made across the board.

I realise that I have had some "tunnel vision" in regards to just focusing on my current build. In my defense it was the first Puppy chosen, downloaded and installed. If this had not worked, who knows where I would have ended up.

[dimkr]

Any chance of changing CONFIG_INPUT_EVBUG=m as it is in most of the Canonical kernels to # CONFIG_INPUT_EVBUG is not set

Done

https://github.com/puppylinux-woof-CE/w ... 85c8e56eff
https://github.com/puppylinux-woof-CE/w ... 4555568227