dice.camp is one of the many independent Mastodon servers you can use to participate in the fediverse.
A Mastodon server for RPG folks to hang out and talk. Not owned by a billionaire.

Administered by:

Server stats:

1.5K
active users

#kernel

6 posts4 participants1 post today

Linux Weekly Releases (Week 30 – 7/26/2025)

Every week, new Linux versions that are under a supported version series get released to incorporate bug fixes and other general improvements that are pushed to the servicing branches. This ensures that your Linux user experience gets better when latest versions fix some of the bugs.

This week, the below Linux kernel versions are released:

SeriesVersionFull sourcePatchSignatureDatev6.1.xv6.1.147LinkLinkLink7/24/2025v6.6.xv6.6.100LinkLinkLink7/24/2025v6.12.xv6.12.40LinkLinkLink7/24/2025v6.15.xv6.15.8LinkLinkLink7/24/2025v6.16.xv6.16-rc7LinkLink7/21/2025

Please note that the downloads are in the source code form, so this means that you may have to compile from source in order to use one of the Linux versions shown above. Your distribution might not include the above Linux versions.

Replied in thread

@edboythinks personally I'm in the process of.migrating from #Ubuntu fonts to #B612 because they are superior yet more permissively licensed.

Continued thread

2/ Another article about a feature recently added to the #XFS filesystem that is not considered experimental any more since #Linux 6.16-rc1 (the text was also written by the responsible developers):

""In this blog post, we discuss a new XFS feature [with] the ability to exchange arbitrary file contents atomically. […]

What Problems Does This Solve?

The first problem is that the Linux file I/O interface does not specify that writes to multiple ranges of a file must be persisted in an all or nothing fashion, which means that file contents can be inconsistent after a crash. […]

The second problem is that some external readers of a structured file must never see an update in progress.

A third problem in this space concerns software defined storage. […]""

blogs.oracle.com/linux/post/xf

#XFS Directory Parent Pointers since #Linux 6.16-rc1 are not considered experimental in the #kernel any more[1]. They allow constructing a file path from a file descriptor or a file handle, which should result in better redundancy and reporting.

In case your want to know more about it, checkout the recently published text "#XFS - Directory Parent Pointers in UEK8"[2], which was written by Allison Henderson and Darrick Wong, who developed and upstreamed the feature.

[1] Just like online fsck and the exchange-range syscall: git.kernel.org/linus/ca43b74ac

[2] just ignoring the Oracle/UEK specific bits

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.

today, I had an issue with my Kubuntu system. during an attempted upgrade from 24.10 to 25.04, there was a power outage and after the power was restored, my system hung up on the Linux Kernel Panic.

i used this guide to help me fix my problem. basically,

- boot into a previous version of the kernel
- run sudo apt update && sudo apt upgrade

that did the trick without me having to specifically fix the initramfs directly.

dev.to/dm8ry/fixing-the-kernel

DEV CommunityFixing the "Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" Error After Upgrading UbuntuUpgrading Ubuntu to a new version can be a smooth experience, but occasionally, issues arise that...
Continued thread

2/ And to quote one bit from @corbet's[1] great #OSSNA25 talk:

""[…] there will be no core development conferences around #Linux and other things in the United States in the foreseeable future. […] this is a real problem […]""

Yes, this is not a formal announcement[2] – but it bears some weight, as Jonathan is well connected and among others sits in the Linux Foundation's Technical Advisory Board (TAB).

[1] youtube.com/watch?v=hNLBGiwfBS (for context starts a bit earlier; the quoted bit comes about a minute later)

[2] and kinda obvious for some of you

ICYMI: the recording of @corbet's recent #OSSNA25 talk "Three Decades in Kernelland" recently became available:

youtube.com/watch?v=hNLBGiwfBS

From the abstract[1]: The #Linux #kernel project has been going for well over 30 years. From its beginnings on floppy diskettes and beige boxes through to its current home in pockets and unseen data centers, the kernel project has been a constant exercise in rapid development and adaptation. I have been present for almost all of the kernel project's history as an observer, contributor, maintainer, and more; all that experience will be boiled down into a fast-moving tour of how the #LinuxKernel got to where it is, what makes it successful, and what may be coming next.

[1] ossna2025.sched.com/event/1zfi