Is there an official binary package f/ mainline Linux kernel?

andret · 2026-08-23 12:43:37

I know this has probably been answered before, somewhere. I cannot find it though. Kernel 7.2 has been released almost 7 days ago, on th 16th. (Today is the 23rd.)
I'm very interested in 7.2 because it has hardware support for something I want to use.

I've found AUR (en) – linux-mainline, which is a user PKGBUILD. Nice, but I'd rather stick to the official stuff. Also I'd really prefer not to compile the kernel, but install a binary package.

Is there no official mainline kernel package, only stable? Why?

For reference:

The Arch Wiki Kernel article clearly states that Arch Linux is providing a package for the stable kernel.
According to kernel.org the current stable kernel is 5.1.9 (from the 19th), for which an update has just arrived (with a short delay).
Also according to kernel.org, kernel 7.2 is not stable, but mainline.

Thanks in advance!

Last edited by andret (2026-08-28 10:29:10)

mmy8x · 2026-08-23 13:03:38

The closest Arch package to the latest upstream release is "linux".

It's common that it takes from a few days to a week or two for it to be updated to a new upstream branch.
Not sure if it has anything to do with the "mainline" designation by upstream, or simply a matter of updating things, building and testing.

andret · 2026-08-23 13:09:43

Thanks. I know. I'm expecting delays not only due to stable vs. mainline, but also due to external dependencies. Imagine someone is using nvidia or openzfs, those people want their system to continue to work after a kernel update.

Only, I'm not using any of those external modules. I'd prefer the mainline kernel.

seth · 2026-08-23 14:34:19

This is NOT a recommendation but if it's only about the build, https://aur.chaotic.cx/stats/search?sea … x-mainline

https://wiki.archlinux.org/title/ZFS isn't officially supported and frequently requires to stall updates.
nvidia-open is rarely a problem itr.

andret · 2026-08-23 15:26:07

Thank you, seth! I've never heard of aur.chaotic.cx before. Is this safe?

With the weekend almost over now, I'll just wait for 7.2 to become stable, which it will be eventually. I had the time and was just wondering...

In general, an official mainline package, that clearly states that it is without support for external stuff (so users of nvidia-open and so forth wouldn't use it), would really be something! Just a suggestion. But I'm really hesitant installing something so central as the kernel from a third-party source. And I really don't want to compile it myself...

Also, thanks for the hint with ZFS. I'm not using it myself, it just came to my mind. Didn't know Arch doesn't officially support it.

Anyways, thanks for all the answers!
(The only thing remaining is the suggestion for "linux-mainline" in addition to "linux" and "linux-lts"...)

gromit · 2026-08-23 15:30:22

I compile a version of the mainline kernel: https://pkgbuild.com/~gromit/linux-bisection-kernels/

The maintainer of the AUR package also has a repository, see https://wiki.archlinux.org/title/Unoffi … ries#miffe (although I can't say anything about the repositories trustworthiness)

seth · 2026-08-23 15:50:58

Is this safe?

No, it pre-compiles the AUR.
There's some discrimination but at this point you're trusting the AUR and the chaotic-aur maintainers.
=> Remove the trust, check.

Despite his sinister looks, @gromit is a more trustworthy source.

andret · 2026-08-23 19:12:29

Thanks... I believe that you, gromit and seth, are trustworthy, but still... I'll wait. I just wish there would be an official linux-mainline...

loqs · 2026-08-23 20:09:13

andret wrote:

I just wish there would be an official linux-mainline...

If it did not carry release candidates it would be out of date relative to the linux package roughly 7 weeks out of 10 (assuming a 2 week merge window and 7 release canidates) and would constantly get flagged for security issues. If it did carry release candidates then it breaks Arch's policy only stable releases.

seth · 2026-08-23 20:14:14

Do you mean like weekly snapshots of the mainline kernel?
Distributing that under the label "mainline" is probably not a good idea…

It is otherwise only release bi-monthly, no bugfixes.
What exactly do you expect to get out of it as regular user?
(Leaving the rare cases where you're waiting for support of your brand new hardware)

Edit: F5ck!

Last edited by seth (2026-08-23 20:14:37)

cryptearth · 2026-08-23 20:48:26

as for ZFS specifically:
a) "not official supported" - that's because of licence stuff: the licence of ZFS is not compatible with Linux' ones - about as nvidia - so, in order to comply to the respective licences and thier incompatibility it's simply not allowed to ship zfs along with linux - so it has to be provided external; it's as simple as that and the same for every other package with an incompatible licence
b) there's https://github.com/archzfs/archzfs - from a quite lengthy discussion the maintainers have agreed upon some along the lines of "support latest versions of both with focus on linux lts" - that means: if zfs upstream https://github.com/openzfs/zfs already supports the latest kernel, with 2.4.4 was already successfully checked against 7.2, it will be built against it; if, however, upstream does NOT support latest kernel (happens from time to time for several reasons) the archzfs project will NOT try to come up with thier own workaround but focus on LTS only - with support for latest kernel restored when upstream zfs catches up
b.1) you're welcome to fork archzfs and build it yourself for your kernel, or just use dkms if compatible - over the years several workarounds came up for when upstream zfs lacked behind or made some mistake (bad artificat or similar); however: unless you run the full ZTS yourself (which can take up to several hours - see https://github.com/n0xena/archzfs/pull/ … 5382271397 as an example) it's up to you when something goes wrong

as for general type of this question: with the official statement being "when it's ready": instead of "demanding" the latest kernel being pushed in an unknown state participate yourself in checking and verifying it - as that's what's holding it back: testing and verifying - this isn't just true for arch but for linux itself
so, if the question comes up for you: "why isn't 7.2 pushed to stable yet one week after it's release?" - the answer is most likely: because it's not yet fully tested and verified to be stable - and instead of "demanding" like "c'mon guys, keep up" get yourself into it and contribute

just two examples:

1) quite some time ago the maintainer for something related to usb and audio pushed a "supposed to be just a clean up" - that resulted in several usb audio devices to misbeahve or no longer work at all - which, if i remember correctly, resulted in the patch to got first fully reverted and then re-worked to get pushed in some later update
2) was it early 2024 or 2025? can't remember anymore - the amdgpu driver had some issue: warm reboot with recent rx 5000/6000/7000 gpus caused them to not cleanly shutdown and hence cause issues to come back up properly on warm reboots - took about 3 months to figure out and get patched

why does this happen and why does it sometimes take so long? because not every dev contributing to the kernel has all the hardware thier code may affect - someone working on usb audio devices may have a couple different ones, but there're litterally thousands differnt devices out there, simply impossible for one dev or even a small team to have all of them for check pre-push; sames goes for GPUs: maybe "on paper" any rx 7000 is supposed to be identical to another one - but there's quite a lot more to it from subtle differences in each board partners own vbios code - and maybe there're several revisions out there - summing up several different versions of the "same model" quite quick - again: just impossible even for many devs to own all variants out there

it just takes time to validate that whatever new changes made it to the current release do what thier devs intent them to - and it takes even longer to validate that and to find issues and fixes for them
you can't just stand up in a crowd of thousand of people and yell "hey, but I AM the important one because i got a new piece of hardware - so hurry up!" - what you rather should do: try to figure out who's the maintainer of the code responsible for your new hardware and offer them to test thier code on your real hardware and report back the results - THIS way you can help to speed up that lengthly process by provide a proof "yeap, works on real hardware, model X, firmware Y"

the reason why linux is "free of charge" is because A LOT of people put thier own free time and money into providing it for free - you shouldn't take this as granted - and given your registry date of about 3 years ago you should've learned that by now

andret · 2026-08-23 21:38:11

No, this came across completely wrong... I'm not demanding.

Well... I'm new to Arch. I like it a lot. It's powering my gaming PC. I just bought a piece of hardware which has a driver in kernel 7.2.
I'm a long-term Gentoo user on my laptop (not my gaming PC). On Gentoo I use the mainline kernel, unknowingly. It's just that when Linus releases a new version, in this case it was 7.2 last Sunday.

On Gentoo Linux, on my laptop, I'm running the latest (what I believed to be) "stable" kernel when it is released, that is, when Gentoo releases an ebuild for the kernel (which is normally within a day or two). So I'm on 7.2 for almost a week now.

I've done this for the last two decades.

Also: I once read that Linus Torvalds was asking eager power users to test kernels. He was also referring to release candidates, naturally. To find bugs on the vast amount of possible hardware we need users, testes. I'm happy to do that on Gentoo, no problem. I always have the previous kernel version to step back, and big issues have been very rare in the past. (One of the most memorable ones was the pstore "incident" in 2013, which bricked a couple of laptops.)

On Arch, I felt that the stable kernel follows quite quickly, very often. Only sometimes it takes longer for the newly released kernel version to arrive on Arch. I noticed just now that this is due to the distinction between stable and mainline. This was under my radar until now.

Anyhow. Arch is progressive. Suppose Arch would also provide a -mainline variant of the kernel, for eager testers. This would come at a price: you'd naturally also have the stable linux kernel, and maybe also linux-lts, as a fallback. But otherwise this will ensure that people also test the newly released kernel, and report bugs.

About reporting bugs. This has been a rare event for me. But I did report one or two kernel bugs to the kernel bugzilla in the past, due to the fact that I'm running always the newly released kernel. This helps make Linux better.

So, I may not be eager to put in work for the Arch package (I help provide one in AUR, but this is something else...), but I'm helping kernel.org directly if I can, and everywhere I can.

So, I do understand the lecture, but I'm not demanding anything, not even "hurry up". The opposite: you have the "stable" policy, and you stick to it. I respect that very much. That's the reason for not having 7.2, because it's not "stable", but "mainline". I get that.

Instead I'm arguing that linux-mainline would be exactly what I would use. This would be the last release from kernel.org, with no guarantees. Progressive users could use it and report bugs, help develop both the kernel and Arch. This isn't anything like snapshots or unstable or release candidates, it's "mainline". Naturally, when there is no "mainline" from kernel.org, the linux-mainline package would (fallback and) be identical to "stable".

I'm proposing. I don't expect anything though. I wouldn't use external binaries. Wouldn't I be doing all that on Gentoo anyhow already, I'd probably have the time to compile my own kernel on Arch, test, and report.

Sorry that I asked.

loqs · 2026-08-23 21:54:06

From Gentoo you will be used to building the kernel from source and the reasoning for a prebuilt mainline would be to increase testing for upstream from other who are not used to building a kernel? I would worry that the normal first step after detecting a new kernel bug is bisecting the kernel to find it and then after reporting it applying patches from upstream both of which would require the reporter to build the kernel so if the reporter requires the kernel built for them how much use is the bug report?

andret · 2026-08-23 22:12:17

All true. I absolutely get your point.
And also not. My experience is that the bug report comes first: this doesn't work, this is the error message. On Gentoo I once or twice had to bisect the specific commit. Otherwise I was just reporting my exact hardware, the exact error message, or the exact behavior. It's better to start with a report "this worked in version x, but stopped working in version x+1" than no bug report at all. Bisecting can come after that.

In the end, on x86-64 at least, I'm mostly testing that the new kernel works well. (This was quite different on ppc and ppc64, believe me!)

The reason I'm not compiling my own kernel on Arch is that I'm busy doing all that stuff already on my Gentoo system. I installed Arch specifically because I wanted a binary distribution. I know, Gentoo does have binaries now as well, but I liked the idea of trying out something new. And Arch is marvelous. It is also very carefree for me, except for those .pacnew files from time to time. I love how fast I can update the whole thing, whereas on my Gentoo system this takes quite some time.
Long story short: yes, if I did find a bug, I would have to install the kernel sources, compile them, bisect the specific patch that is probably the culprit. Probably. But if this all does not happen, I'd stick to not compiling, which is why I've chosen Arch in the first place. It could also be the case that some software isn't compatible with the new kernel, and then the kernel is not at fault, and I'd have to report to the maintainer of the specific software. Had that in the past as well, and reported upstream, because sometimes this can also be device specific (e.g. to a laptop, which the developer(s) don't have access to).

Long story short: nevermind...

seth · 2026-08-23 23:28:40

So I'm on 7.2 for almost a week now.

And have you been using 7.1 for the prior two months?
Or 7.2rc's or snapshots?
Or have you been following the stable branch for a while and moved from 7.1.9 to 7.2 ?

For context: https://bbs.archlinux.org/viewtopic.php?id=313242

andret · 2026-08-24 04:57:43

On Arch I'm simply following the stable release from the default packages linux and linux-lts (as a fallback). I've had issues with the nvidia-open package in the past, which turned out to be a mirror issue. Just recently package nvidia-open failed for linux-lts but did not fail for linux, but this got fixed a day or so later.

This is a gaming PC. I don't care too much about which kernel it is running. I just noticed that it is mostly en-par with what I have on Gentoo Linux. This didn't really surprise me as I perceived Arch to be very progressive. It's even more progressive when it comes to stable KDE Plasma versions (Gentoo is always behind).

Sometimes though Gentoo is first, like with kernel 7.0 as mentioned in the linked discussion. I think Arch got the 7.0 branch with 7.0.3 or so, forgot which really. That's okay. As I said, I previously didn't really care for/wasn't aware of the distinction between "stable" and "mainline", as it is made on kernel.org with the kernel releases. I do read about the new kernels on Phoronix and other IT news outlets though, and sometimes I'm looking forward to those new kernel versions.

As mentioned, on Gentoo I'm with what is released by Linus on kernel.org. The news also reports that, like Linux 7.2 released on Phoronix. A day or two pass until I see the Gentoo ebuild for that kernel version. So I updated from 7.1.8 to 7.2.0.

So, yes, this was a genuine question above: stable, but not mainline – why?

I do understand the policy that you want to have your users receive a tested kernel and not see surprises. ZFS, which I don't use, was just an example. That it is an issue can be seen in light that even Phoronix publishes those news: OpenZFS 2.4.4 Released With Linux 7.2 Support. So, even if there wasn't the "stable" vs. "mainline" distinction on kernel.org, as a Linux distributor you'd have to consider those external dependencies. So "stable" for Arch could be even more delayed. (Edit: Since ZFS isn't officially supported, you'd have to check what is officially supported, whatever that is. So let's not discuss ZFS any more...)

This all makes perfectly sense, and I wouldn't want that in any other way.

My point was that I know what I'm doing. On Gentoo I've been using the kernels as they come along for almost two decades. I've worked out issues, reported bugs where necessary, or included my experience to already reported issues, be it to the Gentoo people or to the kernel developers directly, or to software that had issues with changed/progressed kernels.

My point being, if you had kernel-mainline (or whatever you'd call it), that's the one I'd be using right now.

I've just recently upgraded my hardware from nvidia to amdgpu. The external (closed-source) nvidia driver is just one of the reasons why I switched.

Please, don't get angry with me. I started my question with "I know this has probably been answered before" and if I would have found an explanation for why you're not providing mainline I wouldn't have asked. I was just wondering. It's your distribution, you can do it however you like. And I could compile my own kernel if it were sooo important to me. Or use the prebuild package by aur.chaotic.cx or gromit. But even before the AUR incidents I've always been very cautious about any additional external repositories... It's mostly not worth it, security-wise.

Long story short: yes, I follow stable when mainline isn't designated. Gentoo doesn't make this distinction. Gentoo has a completely different version marked as stable (edit: I just checked: 6.18.41 is current Gentoo stable, with 6.18.45 being available but like 7.1.9 and 7.2.0 marked untested), and I'm using the untested ebuilds for new kernels, and those are made as the kernels are released: so 7.0 to 7.0.12, followed by 7.1 to 7.1.8, then 7.2, which will likely be followed by 7.2.1 progessing up until 7.3 will be released.

Edit: the difference is, that on Gentoo I'm configuring and compiling my own kernels. Arch does that for me. If I wanted to compile my own kernels on Arch as well, I'd already have done that. I could also use the CachyOS repository and the modified kernel from it. I find it sufficient though to stick to your settings as they come with the binary packages "linux" and "linux-lts". If I had an issue with "linux", I'd try to help as well, also if it meant to manually compile and bisect the kernel. But I'd only compile the kernel when it is necessary, like for bug reporting, bug searching. The same is true for what kernel.org calls "mainline" – I wouldn't want to continuously compile kernels that work. I'd only compile when they otherwise don't work, and to assist the bug hunting.

Last edited by andret (2026-08-24 05:23:32)

seth · 2026-08-24 09:47:52

So I updated from 7.1.8 to 7.2.0.

Those are stable kernel version, mainline would have been 7.1 to 7.2

Please, don't get angry with me.

I don't think anybody does nor know why one would.

It's your distribution

This is generally a user to user forum, the only ones getting to end discussions with "because I say so" are the mods enforcing the forum rules.

Gentoo has a completely different version marked as stable

Arch generally just sticks to upstream, the terminology is explained on https://www.kernel.org/releases.html

I sense that you're probably just falling into the category of the other thread (which iirc because it got a bit testy), ie. you'd expect/prefer the kernel to follow major releases instead of staying with it to its EOL (typically skipping the .0-2 releases of the new stable kernel) and that's a fair opinion, but the package maintainer doesn't currently share that.

It's just important that we're all talking about the same thing and "mainline" here and upstream means Linus' tree with releases/updates only every other month what is typically not in the interest of end users.

mmy8x · 2026-08-24 11:13:37

Yes, you are talking to a user forum, which is mostly *not* the people building packages and deciding which releases to ship.

That being said, we can look at the package archive and quickly find that 6.17, for example, was available 5 days after Linus made the release, when the 6.16.y branch was still at 6.16.10 and it later continued to 6.16.12.

So there is no rule that you wait two weeks, or until the previous branch is EOL, or anything like that. It's ready when it's ready.

seth · 2026-08-24 14:02:35

There's certainly no nothing set in stone here but

linux-5.0.arch1-1-x86_64.pkg.tar.xz                04-Mar-2019 15:36     71M
linux-5.1.arch1-1-x86_64.pkg.tar.xz                07-May-2019 04:37     72M
linux-5.2.arch2-1-x86_64.pkg.tar.xz                09-Jul-2019 04:11     73M
linux-5.3.arch1-1-x86_64.pkg.tar.xz                16-Sep-2019 04:19     74M
linux-5.4.arch1-1-x86_64.pkg.tar.xz                26-Nov-2019 00:13     69M
linux-5.5.arch1-1-x86_64.pkg.tar.zst               27-Jan-2020 22:43     69M
linux-5.6.arch1-1-x86_64.pkg.tar.zst               31-Mar-2020 23:29     69M
linux-5.7.arch1-1-x86_64.pkg.tar.zst               02-Jun-2020 01:26     70M
linux-5.8.arch1-1-x86_64.pkg.tar.zst               03-Aug-2020 20:26     72M
linux-5.8.arch1-2-x86_64.pkg.tar.zst               09-Aug-2020 02:01     72M
linux-5.9.arch1-1-x86_64.pkg.tar.zst               12-Oct-2020 21:40     74M
linux-5.11.arch1-1-x86_64.pkg.tar.zst              15-Feb-2021 23:58     92M
linux-5.11.arch2-1-x86_64.pkg.tar.zst              19-Feb-2021 00:17     93M
linux-5.12.arch1-1-x86_64.pkg.tar.zst              26-Apr-2021 21:37     95M
linux-5.15.arch1-1-x86_64.pkg.tar.zst              03-Nov-2021 23:33    130M
linux-5.16.arch1-1-x86_64.pkg.tar.zst              10-Jan-2022 21:26    156M
linux-5.17.arch1-1-x86_64.pkg.tar.zst              23-Mar-2022 00:49    160M
linux-5.18.arch1-1-x86_64.pkg.tar.zst              24-May-2022 22:40    174M
linux-5.19.arch1-1-x86_64.pkg.tar.zst              06-Aug-2022 14:09    178M
linux-6.0.arch1-1-x86_64.pkg.tar.zst               04-Oct-2022 22:15    163M
linux-6.1.arch1-1-x86_64.pkg.tar.zst               12-Dec-2022 00:59    164M
linux-6.2.arch1-1-x86_64.pkg.tar.zst               20-Feb-2023 23:22    176M
linux-6.3.arch1-1-x86_64.pkg.tar.zst               29-Apr-2023 05:04    147M
linux-6.3.arch1-2-x86_64.pkg.tar.zst               30-Apr-2023 16:18    147M
linux-6.4.arch1-1-x86_64.pkg.tar.zst               27-Jun-2023 05:53    125M
linux-6.5.arch1-1-x86_64.pkg.tar.zst               29-Aug-2023 19:57    127M
linux-6.6.arch1-1-x86_64.pkg.tar.zst               31-Oct-2023 17:09    129M
linux-6.7.arch1-1-x86_64.pkg.tar.zst               09-Jan-2024 23:35    131M
linux-6.7.arch2-1-x86_64.pkg.tar.zst               12-Jan-2024 22:13    130M
linux-6.7.arch3-1-x86_64.pkg.tar.zst               13-Jan-2024 15:37    130M
linux-6.8.arch1-1-x86_64.pkg.tar.zst               11-Mar-2024 03:55    132M
linux-6.9.arch1-1-x86_64.pkg.tar.zst               15-May-2024 17:08    134M
linux-6.10.arch1-1-x86_64.pkg.tar.zst              18-Jul-2024 20:49    135M
linux-6.10.arch1-2-x86_64.pkg.tar.zst              22-Jul-2024 17:42    135M
linux-6.11.arch1-1-x86_64.pkg.tar.zst              15-Sep-2024 19:23    137M
linux-6.12.arch1-1-x86_64.pkg.tar.zst              19-Nov-2024 03:22    138M
linux-6.13.arch1-1-x86_64.pkg.tar.zst              23-Jan-2025 02:03    138M
linux-6.13.arch1-2-x86_64.pkg.tar.zst              30-Jan-2025 16:51    138M
linux-6.14.arch1-1-x86_64.pkg.tar.zst              25-Mar-2025 01:55    139M
linux-6.16.arch1-1-x86_64.pkg.tar.zst              03-Aug-2025 04:20    142M
linux-6.16.arch1-2-x86_64.pkg.tar.zst              13-Aug-2025 17:25    142M
linux-6.16.arch2-1-x86_64.pkg.tar.zst              14-Aug-2025 00:11    142M
linux-6.17.arch1-1-x86_64.pkg.tar.zst              03-Oct-2025 02:16    143M
linux-6.18.arch1-1-x86_64.pkg.tar.zst              01-Dec-2025 23:58    143M

the pattern stops there and

linux-6.19.5.arch1-1-x86_64.pkg.tar.zst            01-Mar-2026 09:47    145M
linux-7.0.2.arch1-1-x86_64.pkg.tar.zst             27-Apr-2026 19:18    146M
linux-7.1.2.arch1-1-x86_64.pkg.tar.zst             28-Jun-2026 02:59    147M

a new one emerges.

andret · 2026-08-24 15:14:57

Ok. In my head I made the connection "stable" from kernel.org and Kernel in the Arch Wiki as the one Arch would follow. Since 7.1.10 is marked "stable" on kernel.org, and Arch is still on 7.1, I though that that's what "stable" means. Also, I wrongly assumed that AUR (en) – linux-mainline would follow the bug fix releases, which looking now (too late) at the changes clearly it doesn't. My bad.

So, what is really going on, is testing compatibility and the dependencies then? Well, then I'm all for it.

Put bluntly, I would have expected the 7.2.0 release by now, within a week. Again, this isn't a "I want this" or "I demand" kind of statement.

andret · 2026-08-24 15:17:24

mmy8x wrote:

It's ready when it's ready.

Yes. Exactly that.

seth · 2026-08-24 15:32:48

Since 7.1.10 is marked "stable" on kernel.org, and Arch is still on 7.1

https://archlinux.org/packages/core-tes … _64/linux/ is currently at 7.1.10, core at 7.1.9 ?

andret · 2026-08-28 10:27:55

So core went up to 7.1.10. Sadly, the driver I'm looking for has not been backported. It's a first world problem. Never mind. Wanted to try out the new ARCTIC 10-Fan Controller driver introduced by ARCTIC in kernel 7.2, which I only have in my gaming PC, not on my laptop (which is powered by Gentoo Linux). It doesn't matter, even without the driver the fans are spinning, just not controlled.

I declare this discussion closed. Thanks everyone!

mmy8x · 2026-08-28 10:46:40

You could download the C file and compile it as an out-of-tree module.

No warranty, but this would work if it doesn't depend on things that changed in v7.2.

Last edited by mmy8x (2026-08-28 10:53:56)

WorMzy · 2026-08-28 11:08:30

Closing, on implied request.

Arch Linux

#1 2026-08-23 12:43:37

Is there an official binary package f/ mainline Linux kernel?

#2 2026-08-23 13:03:38

Re: Is there an official binary package f/ mainline Linux kernel?

#3 2026-08-23 13:09:43

Re: Is there an official binary package f/ mainline Linux kernel?

#4 2026-08-23 14:34:19

Re: Is there an official binary package f/ mainline Linux kernel?

#5 2026-08-23 15:26:07

Re: Is there an official binary package f/ mainline Linux kernel?

#6 2026-08-23 15:30:22

Re: Is there an official binary package f/ mainline Linux kernel?

#7 2026-08-23 15:50:58

Re: Is there an official binary package f/ mainline Linux kernel?

#8 2026-08-23 19:12:29

Re: Is there an official binary package f/ mainline Linux kernel?

#9 2026-08-23 20:09:13

Re: Is there an official binary package f/ mainline Linux kernel?

#10 2026-08-23 20:14:14

Re: Is there an official binary package f/ mainline Linux kernel?

#11 2026-08-23 20:48:26

Re: Is there an official binary package f/ mainline Linux kernel?

#12 2026-08-23 21:38:11

Re: Is there an official binary package f/ mainline Linux kernel?

#13 2026-08-23 21:54:06

Re: Is there an official binary package f/ mainline Linux kernel?

#14 2026-08-23 22:12:17

Re: Is there an official binary package f/ mainline Linux kernel?

#15 2026-08-23 23:28:40

Re: Is there an official binary package f/ mainline Linux kernel?

#16 2026-08-24 04:57:43

Re: Is there an official binary package f/ mainline Linux kernel?

#17 2026-08-24 09:47:52

Re: Is there an official binary package f/ mainline Linux kernel?

#18 2026-08-24 11:13:37

Re: Is there an official binary package f/ mainline Linux kernel?

#19 2026-08-24 14:02:35

Re: Is there an official binary package f/ mainline Linux kernel?

#20 2026-08-24 15:14:57

Re: Is there an official binary package f/ mainline Linux kernel?

#21 2026-08-24 15:17:24

Re: Is there an official binary package f/ mainline Linux kernel?

#22 2026-08-24 15:32:48

Re: Is there an official binary package f/ mainline Linux kernel?

#23 2026-08-28 10:27:55

Re: Is there an official binary package f/ mainline Linux kernel?

#24 2026-08-28 10:46:40

Re: Is there an official binary package f/ mainline Linux kernel?

#25 2026-08-28 11:08:30

Re: Is there an official binary package f/ mainline Linux kernel?

Board footer