I'ld suggest to:
1. Upgrade to #Debian 13 #trixie. Should be almost stable. Release date will be 2025-08-09.
2. Then install the #Linux #kernel from Debian #experimental (6.15.6 right now).
This is supposed to work, TTBOMK.
It's looking like #linux #kernel 6.14+ will contain the driver I need for an intel AX201 on a #Debian 12, which doesn't work on my #thinkpad right now (no wifi! agh!).
I'm telling you all that for the context behind this question:
Is it bad/dangerous/unstable to run Debian 12 on kernel 6.14?
Further, should I use the Ubuntu kernel or get the "raw" kernel?
Edit: 6.14 might not be necessary after all. Sigh.
#Linux users who have #Secure Boot enabled on their systems knowingly or unknowingly rely on a key from #Microsoft that is set to expire in September. After that point, Microsoft will no longer use that key to sign the shim first-stage #UEFI #bootloader that is used by Linux distributions to boot the #kernel with Secure Boot.
But the replacement key, which has been available since 2023, may not be installed on many systems; worse yet, it may require the #hardware vendor to issue an update for the system #firmware, which may or may not happen. It seems that the vast majority of systems will not be lost in the shuffle, but it may require extra work from distributors and users.
@GabeMoralesVR
#IRC and #Mailinglists with their problems, [and they both have many] are at least #indexable and #searchable to the point that I could propable make a #supercut of #LKML folks shouting at each other...
I made lsiommu as I just wanted to get rid of the shitty combination of bash and python I had before:
~/work/staging/lsiommu master*
❯ build/lsiommu
IOMMU Group 0
00:07.1 Class 060400: Vendor 8086 Device 9a25 [8086:9a25] (rev 01)
IOMMU Group 1
00:07.0 Class 060400: Vendor 8086 Device 9a23 [8086:9a23] (rev 01)
IOMMU Group 2
00:02.0 Class 030000: Vendor 8086 Device 9a49 [8086:9a49] (rev 01)
IOMMU Group 3
00:00.0 Class 060000: Vendor 8086 Device 9a14 [8086:9a14] (rev 01)
IOMMU Group 4
00:04.0 Class 118000: Vendor 8086 Device 9a03 [8086:9a03] (rev 01)
IOMMU Group 5
00:0a.0 Class 118000: Vendor 8086 Device 9a0d [8086:9a0d] (rev 01)
IOMMU Group 6
00:0d.0 Class 0c0330: Vendor 8086 Device 9a13 [8086:9a13] (rev 01)
00:0d.2 Class 0c0340: Vendor 8086 Device 9a1b [8086:9a1b] (rev 01)
IOMMU Group 7
00:0e.0 Class 010400: Vendor 8086 Device 9a0b [8086:9a0b] (rev 00)
IOMMU Group 8
00:14.0 Class 0c0330: Vendor 8086 Device a0ed [8086:a0ed] (rev 20)
00:14.2 Class 050000: Vendor 8086 Device a0ef [8086:a0ef] (rev 20)
IOMMU Group 9
00:14.3 Class 028000: Vendor 8086 Device a0f0 [8086:a0f0] (rev 20)
IOMMU Group 10
00:15.0 Class 0c8000: Vendor 8086 Device a0e8 [8086:a0e8] (rev 20)
IOMMU Group 11
00:16.0 Class 078000: Vendor 8086 Device a0e0 [8086:a0e0] (rev 20)
IOMMU Group 12
00:1d.0 Class 060400: Vendor 8086 Device a0b0 [8086:a0b0] (rev 20)
IOMMU Group 13
00:1f.0 Class 060100: Vendor 8086 Device a082 [8086:a082] (rev 20)
00:1f.3 Class 040100: Vendor 8086 Device a0c8 [8086:a0c8] (rev 20)
00:1f.4 Class 0c0500: Vendor 8086 Device a0a3 [8086:a0a3] (rev 20)
00:1f.5 Class 0c8000: Vendor 8086 Device a0a4 [8086:a0a4] (rev 20)
IOMMU Group 14
55:00.0 Class 010802: Vendor 144d Device a808 [144d:a808] (rev 00)
Perhaps the most interesting implementation note is that it uses libudev for PCI discovery, instead of traversing sysfs (because the latter sucks).
Right and I made my own shitty teardown manager framwork:
/* SPDX-License-Identifier: GPL-3.0-or-later */
/*
* Copyright(c) Opinsys Oy 2025
*/
#ifndef TEARDOWN_H
#define TEARDOWN_H
#include <libudev.h>
#define teardown(func) __attribute__((cleanup(func)))
void teardown_udev(struct udev **udev);
void teardown_udev_device(struct udev_device **dev);
void teardown_udev_enumerate(struct udev_enumerate **enumerate);
#endif /* TEARDOWN_H */
Dependencies:
❯ ldd build/lsiommu
linux-vdso.so.1 (0x00007f083ccd5000)
libargtable2.so.0 => /lib/x86_64-linux-gnu/libargtable2.so.0 (0x00007f083cc8a000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f083cc5c000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f083cb8c000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f083c9ab000)
/lib64/ld-linux-x86-64.so.2 (0x00007f083ccd7000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f083c99f000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f083c856000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f083c827000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f083c76b000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f083c745000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f083c71d000)
I can throw this to some Git repository if anyone is interested any of this. It’s really just “by me for me”, but I neither mind sharing it.
The Debian community forums would love to see your bug. Good luck, however you search.
Linux Kernel 6.16 RC6 Released #Linux #Kernel #Opensource
https://ostechnix.com/linux-kernel-6-16-rc6-released/
""The latest alpha of the upcoming #Blender 5.0 release comes with High Dynamic Range (HDR) support for #Linux on #Wayland […]
It’s been a lot of personal blood, sweat and tears, paid for by #RedHat across the Linux graphics stack for the last few years to enable applications like Blender to add #HDR support. From #kernel work, like helping to get the HDR mode working on Intel laptops, and improving the Colorspace and HDR_OUTPUT_METADATA KMS properties, to creating a new library for EDID and DisplayID parsing, and helping with wiring things up in #vulkan.
I designed the active color management paradigm for Wayland compositors, figured out how to properly support HDR, created two wayland protocols to let clients and compositors communicate the necessary information for active color management, and created documentation around all things color in FOSS graphics. This would have also been impossible without @pq from Collabora and all the other people I can’t possibly list exhaustively. […] ""
https://blog.sebastianwick.net/posts/blender-hdr-reference-white/ (written by @swick)
From the Linux Update newsletter: @linuxnews looks at Linux 6.12 LTS, which makes real-time support an official part of the operating system kernel
https://www.linux-magazine.com/Issues/2025/295/Linux-6.12-LTS?utm_source=mlm
#Linux #kernel #support #LTS #FOSS #extensions #OpenSource
After a clash over some late fixes and disagreements between bcachefs's lead developer and Linus Torvalds, Linux kernel 6.17 may drop bachefs
https://www.linux-magazine.com/Online/News/Linux-Kernel-6.17-Drops-bcachefs?utm_source=mlm
#Linux #kernel #bachefs #patches
Linux Kernel 6.16 RC5 Released: Steady Progress with Key Fixes #linux #kernel #opensource
https://ostechnix.com/linux-kernel-6-16-rc5-released/
Remember #Linux' pktcdvd driver, which allowed direct mounts with UDF of cd-rw drives that required 32kb packets?
That driver is now in now scheduled to be removed with #kernel 6.17, as a patch doing this landed in linux-next today – because that use-case is uncommon these days, as "the world has moved on from those kinds of media. To make matters worse, it's actively breaking setups where it's not even required or useful."
New set of #Gentoo #Linux Distribution Kernels (6.1.143, 6.6.96, 6.12.36, 6.15.5) is out. This set brings some major changes:
• I've backported a bunch of changes from sys-kernel/gentoo-kernel to sys-kernel/vanilla-kernel that were missing — notably wider architecture support.
• I've added default #RISCV configs to 6.12 (in addition to 6.15), since Fedora had them.
• All three packages are based off the baseline kernel tarball + upstream patch (vanilla-kernel used to fetch patch-level tarball every time, and gentoo-kernel* used genpatches for patch versions). This should reduce disk space and bandwidth use.
• All three packages now support verify-sig. Rather than verifying the uncompressed tarball signature, we now use upstream `sha256sums.asc` file to verify the compressed tarball and patch.
• sys-kernel/gentoo-kernel* now repackages genpatches. This means patchset that's much leaner and faster to apply (since we just fetch and use the combined upstream patch rather than including point patches). This also means that we are able to release Distribution Kernels before gentoo-sources are done.
The changes still need to be done to 5.15 and 5.10 branches — we're going to do for the next upstream releases of these.
Tell me that you do not understand the problem space of supporting ARM SoC in the upstream #Linux #kernel at all (including #RaspberryPi support) without telling me that you do not understand that problem space.
No, I don't want to make fun of the one who posted that. I can fully understand the question.
I just found it a good example showing that some (a lot?) of users not even remotely understand the things many of us are dealing with every day – not even the basic "Raspberry Pi might run Linux[1], but Linux[2] only supports it partially – and new models often not a all when they are just a few months (sometimes years) old".
Or the aspect "ARM SoCs and boards build around them are a bit like a combination of a slightly or heavily modified x86_64 cpu with a special designed motherboard, which is why support for one ARM chip does not mean at all that others ARM chips with the same ISA are supported, too.
And there are more. Like non-redistributable firmware files, less standardization in areas like booting and hardware-introspection, ….
[1] here the word means a Linux distribution here that is using a patched Linux[2]
[2] here the word means the kernel called "Linux" distributed through kernel.org
A Higgs-bugson in the #Linux #Kernel
https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/
""We recently ran across a strange higgs-bugson that manifested itself in a critical system […] A higgs-bugson is a bug that is reported in practice but difficult to reproduce, […]
The Linux kernel does not actually implement this cache as suggested by the RFC, so I wrote a kernel patch to add this functionality and mailed it off upstream. I also learned that the FreeBSD kernel actually already implements this, so this is new-to-Linux but not new-to-NFS.
[…]
Both of these patches are now upstream and will be available in Linux 6.16.""
https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/
