Linux on KnightLi Blog

pci=nomsi and pcie_aspm=off explained: troubleshooting SATA expansion cards not detected, dropping disks, or freezing on Linux

Sun, 24 May 2026 00:41:23 +0800

When using PCIe SATA expansion cards on Linux or Ubuntu, users often run into disks not being detected, disks dropping after some runtime, system freezes, or boot problems around PCIe link training. Common examples include JMB585 and ASM1166 SATA cards, especially in NAS boxes, mini PCs, industrial PCs, modified motherboards, or cheap adapter setups.

pci=nomsi and pcie_aspm=off are two Linux kernel parameters often used when troubleshooting this class of problem. They both involve PCIe, but they address different layers:

pci=nomsi mainly targets interrupt signaling problems, meaning the way the device notifies the CPU is unreliable.
pcie_aspm=off mainly targets PCIe power management problems, meaning the link fails to wake reliably after entering a low-power state.

If you treat these two options as the same kind of fix, troubleshooting becomes guesswork. A better approach is to look at the symptoms and decide whether interrupts, link power management, or the hardware itself is the more likely suspect.

pci=nomsi: disable message-signaled interrupts

pci=nomsi can be read as:

PCI: PCI-related devices.
no: disable.
MSI: Message Signaled Interrupts.

It tells the Linux kernel not to use MSI / MSI-X interrupt mechanisms for PCI devices, and to fall back to the older INTx interrupt mode.

What is MSI?

Traditionally, hardware devices notify the CPU through physical interrupt pins, known as legacy IRQs. This works, but sharing and scaling are limited.

MSI / MSI-X came later. Instead of pulling a physical interrupt pin, the device writes a message to a specific memory address. When the CPU receives that message, it knows which device raised the interrupt. On modern systems, MSI / MSI-X is usually more flexible and better suited for high-concurrency devices.

The problem is that not every PCIe expansion card implements MSI reliably. Some cheap cards, retired enterprise cards, bridge-chip designs, or SATA controllers with poor firmware may produce abnormal MSI messages, lost interrupts, or interrupt storms under Linux drivers.

Common symptoms include:

The machine hangs while detecting the PCIe expansion card during boot.
The SATA expansion card does not detect disks at all.
Random system freezes.
dmesg shows errors such as irq xx: nobody cared.
The card appears to work under Windows but is unstable under Linux.

The core problem is not the hard disk or filesystem. It is the interrupt communication path between the device and CPU.

What happens after adding pci=nomsi?

Enable:

`1`	`pci=nomsi`

This tells the Linux kernel not to let PCI devices use advanced MSI message interrupts, and to fall back to legacy INTx interrupts.

This may slightly reduce performance and interrupt handling efficiency, especially on high-throughput or high-interrupt devices. For home NAS setups, SATA expansion cards, and ordinary hard-drive arrays, the practical impact is usually small. The value is that it bypasses MSI compatibility bugs in some device firmware or bridge chips, allowing the system to identify the device and handle I/O reliably.

In short, pci=nomsi addresses “the device’s way of notifying the CPU is unreliable.”

pcie_aspm=off: disable PCIe Active State Power Management

pcie_aspm=off can be read as:

PCIe: PCI Express.
ASPM: Active State Power Management.
off: disable.

It disables PCIe link power-saving mechanisms, preventing PCIe links from entering low-power states.

What is ASPM?

ASPM is a PCIe power-saving mechanism. When the system sees that a PCIe link is idle, it can move the link into a lower-power state such as L0s or L1. When the device needs to transfer data again, the link wakes back up to normal operation.

On well-designed hardware, this saves power and is almost invisible to users. On some consumer motherboards, mini PCs, industrial systems, cheap SATA cards, adapters, or systems with weaker signal quality, the problem is “it goes to sleep and does not wake cleanly.”

A typical case is a JMB585 or ASM1166 PCIe SATA card entering a low-power state after being idle. The next disk access requires the link to wake from L1. If the controller, motherboard, riser, power, or firmware quality is not good enough, wake-up may be too slow or the physical signal may glitch. The Linux kernel may then think the device briefly disappeared.

Typical dmesg messages include:

1
2
3

pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
ata1: link is slow to respond, please be patient
ata1: COMRESET failed (errno=-16)

This may be followed by:

Disk dropout.
Degraded arrays.
Filesystem remounted read-only.
NAS services failing.
System I/O hangs.
Disk temporarily returns after reboot.

The frustrating part is that the problem may not appear at boot. It often happens after the system has been running, after an idle period, or during a load transition.

What happens after adding pcie_aspm=off?

Enable:

`1`	`pcie_aspm=off`

This tells the kernel to disable system-wide PCIe ASPM. PCIe links should remain in normal connected states as much as possible, whether idle or busy, instead of entering low-power sleep.

The side effect is slightly higher power use. For desktops, NAS boxes, and mini PCs, this is often only hundreds of milliwatts to one or two watts. For laptops, it may affect battery life. The benefit is fewer disk drops, link-training errors, and physical-layer errors caused by PCIe link sleep and wake.

In short, pcie_aspm=off addresses “the PCIe link does not wake reliably after sleeping.”

The difference between the two parameters

They solve two different classes of problems:

Parameter	Core problem	Common symptoms	Main side effect
`pci=nomsi`	Interrupt signaling conflicts, poor MSI / MSI-X compatibility	Boot hangs, no disk detection, `irq xx: nobody cared`, system freeze	Slightly lower interrupt efficiency under very high concurrency
`pcie_aspm=off`	PCIe power-save wake failure, unstable link signal	Works at boot, drops disks later, `PCIe Bus Error`, `COMRESET failed`	Slightly higher power use, slightly lower laptop battery life

They do not replace each other. One controls interrupts, the other controls link power management.

If the system hangs during boot or the device is never detected, suspect pci=nomsi first. If it boots normally but drops disks later, or dmesg shows Physical Layer, COMRESET, or “link is slow to respond” messages, suspect pcie_aspm=off first.

Should you add both?

Many NAS users add both at once:

`1`	`pci=nomsi pcie_aspm=off`

This is a quick troubleshooting method, especially with JMB585, ASM1166, mini PCs, adapter cards, uncertain power, and uncertain cabling. It can bypass MSI compatibility issues and ASPM wake problems at the same time.

From a troubleshooting perspective, it is better to record symptoms and logs first:

If you see interrupt errors or boot hangs, try pci=nomsi first.
If you see disk drops, PCIe Bus Error, or COMRESET after runtime, try pcie_aspm=off first.
If the system is unstable and you need to restore service quickly, add both, then test them separately later.

This helps you identify the actual class of problem, which is useful when changing cards, slots, motherboards, or BIOS settings later.

How to make it permanent on Ubuntu / Debian

Edit the Grub configuration file:

`1`	`sudo nano /etc/default/grub`

Find this line:

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"`

Append the parameters inside the quotes, separated by spaces. For example:

`1`	`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash pci=nomsi pcie_aspm=off"`

Save and exit. In Nano, press Ctrl+O, confirm with Enter, then press Ctrl+X.

Update Grub and reboot:

1
2

sudo update-grub
sudo reboot

After reboot, check whether the kernel command line is active:

`1`	`cat /proc/cmdline`

If the output contains pci=nomsi and pcie_aspm=off, the parameters are active for the current boot.

What else should you check?

These two parameters are useful, but they are not universal fixes for every disk-drop problem. When troubleshooting SATA expansion cards and NAS disk drops, also check:

Loose or poor-quality SATA data cables.
Stable disk power, especially when many disks spin up at once.
Poor PCIe slot contact.
Expansion card overheating.
BIOS options related to PCIe ASPM, Above 4G Decoding, and PCIe speed.
Known firmware issues in the SATA expansion card.
Disk SMART warnings, bad sectors, or I/O errors in system logs.

If disk SMART is already reporting errors, or power delivery is unstable, kernel parameters alone will not solve the underlying problem.

Summary

pci=nomsi and pcie_aspm=off are both common troubleshooting parameters for unstable PCIe SATA expansion cards on Linux, but they work at different layers:

pci=nomsi: disables MSI / MSI-X to bypass interrupt compatibility issues.
pcie_aspm=off: disables PCIe ASPM to avoid wake failures after link power saving.

For JMB585, ASM1166, NAS systems, mini PCs, and cheap PCIe cards, these two parameters often help. The safer approach is to inspect dmesg, decide whether the problem looks like interrupts or link power management, then choose one or both.

They are troubleshooting tools, not a replacement for good hardware. If the system becomes stable after adding them, the problem is likely in interrupt compatibility or PCIe power management. If disks still drop, continue checking power, cables, cooling, disk health, and the expansion card itself.

CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

Fri, 22 May 2026 15:16:59 +0800

CVE-2026-43494 is a Linux kernel local privilege escalation risk. The related exploitation chain is also known publicly as PinTheft. The key point is not a remote entry point, but whether a low-privilege local user can line up RDS zerocopy, io_uring fixed buffers, a readable SUID-root program, and a suitable kernel version.

One naming detail is worth clarifying first: the Unclecheng-li/poc-lab repository directory is named CVE-2026-43494 PinTheft, while the README title also mentions QVD-2026-27616 - PinTheft. Based on public CVE entries and third-party advisories, CVE-2026-43494 points to a Linux kernel RDS zerocopy issue where op_nents is not reset correctly, leading to a double-free / reference-counting anomaly. QVD-2026-27616 appears more like a Qianxin risk advisory identifier. In real triage, record both identifiers, but treat distribution security advisories and kernel patch status as the source of truth.

What Is the Core Bug?

The issue appears in the zerocopy send path of Linux RDS, Reliable Datagram Sockets. Public descriptions point to these key functions:

1
2

rds_message_zcopy_from_user()
rds_message_purge()

When iov_iter_get_pages2() fails inside rds_message_zcopy_from_user(), pages that have already been pinned can be released by the error path, but the related op_nents state is not cleared correctly. Later, rds_message_purge() may still release the residual entries again. The result is that the same batch of page references can be decremented too many times, creating an exploitable reference-counting error.

Viewed alone, the RDS bug is an error-path memory-management issue inside the kernel. PinTheft becomes dangerous because the exploitation chain connects it with the io_uring fixed-buffer mechanism: io_uring still keeps an old struct page *, while the page itself has already been freed and reallocated for another purpose. The public PoC then steers this state toward overwriting the page cache of a SUID-root program, eventually reaching local privilege escalation.

Why It Is Called PinTheft

io_uring REGISTER_BUFFERS pins user pages. For normal pages, FOLL_PIN is not just a simple reference increment; it raises the page refcount through a larger bias. The public PoC uses the concept of GUP_PIN_COUNTING_BIAS = 1024.

The name PinTheft means the attack chain repeatedly “steals” those pin references through the RDS zerocopy failure path. After the references are drained, io_uring still believes it holds a valid page, but that physical page can now be freed and reused by the page cache.

This class of vulnerability is easy to misread as “directly modifying /usr/bin/su on disk.” A more accurate description is that the exploitation chain tries to overwrite the in-memory page cache. The file itself may not be written back to disk, but when the kernel executes the SUID program, it may fetch instructions from the contaminated page cache and run the attack payload.

The Trigger Conditions Are Not Broad

This is not a vulnerability where “any Linux server can be remotely hit.” Public information indicates that the exploitation chain depends on at least these conditions:

The kernel has CONFIG_RDS and CONFIG_RDS_TCP enabled.
The system has CONFIG_IO_URING enabled, and kernel.io_uring_disabled=0.
The rds / rds_tcp modules are already loaded, or a low-privilege user can trigger autoloading.
A readable SUID-root binary exists locally, such as /usr/bin/su, /usr/bin/passwd, or /usr/bin/pkexec.
The public PoC also depends on the newer IORING_REGISTER_CLONE_BUFFERS API. CloudLinux analysis notes that the public PoC is more aligned with kernel 6.13 and later.

If any one of these links is missing, the public exploitation path breaks. For example, many RHEL-family distributions do not compile RDS by default, older Ubuntu kernels may lack the io_uring clone-buffer API needed by the PoC, and some environments restrict automatic RDS module loading by unprivileged users.

One-Minute Self-Check

First, check the kernel configuration:

1
2

zgrep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /proc/config.gz 2>/dev/null \
  || grep -E "CONFIG_(RDS|RDS_TCP|IO_URING)" /boot/config-$(uname -r)

Then check whether io_uring is disabled:

`1`	`cat /proc/sys/kernel/io_uring_disabled 2>/dev/null`

Interpret the common values like this:

0: allowed, giving the largest exposure.
1: restricted for unprivileged users; exact behavior depends on kernel version and distribution policy.
2: io_uring disabled.

Check whether the RDS modules exist and can be loaded:

1
2

lsmod | grep -E "^rds|^rds_tcp"
modprobe -n -v rds_tcp 2>&1 | head -3

If CONFIG_RDS is not set, or the system has no rds_tcp module at all, this bug usually cannot be reached. Conversely, if RDS is available, io_uring is not disabled, and the system uses a relatively new general-purpose kernel, continue checking distribution fix status with higher priority.

Which Machines Deserve Priority

Prioritize these environments:

Multi-user Linux hosts, teaching machines, jump hosts, and shared development machines.
Container hosts, especially environments that allow untrusted local users or have a loose container escape surface.
Desktops or servers running newer mainline / rolling kernels, such as Arch-like rolling distributions.
HPC, Oracle RAC, or other scenarios that may genuinely use RDS.
CI workers, build machines, and lab environments that allow unprivileged users to run large amounts of local code.

For an ordinary web server where only controlled service accounts run applications and RDS is not enabled, the practical risk is much lower. But “much lower” does not mean “ignore it”: the typical impact of a kernel local privilege escalation is that an attacker first gains low-privilege access through Web, SSH, CI, containers, or an application bug, then uses the local bug to expand control.

Temporary Mitigation Ideas

The proper fix should still come from the distribution kernel update. Patch status, backported versions, and affected ranges must be checked against advisories from Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, Arch, cloud vendors, or container base-image providers. Do not judge only by the upstream version number.

While waiting for patches, or when an immediate kernel reboot is not possible, choose temporary measures according to the environment:

# If the business does not depend on RDS, block related module loading
sudo sh -c "printf 'install rds /bin/false\ninstall rds_tcp /bin/false\ninstall rds_rdma /bin/false\n' > /etc/modprobe.d/pintheft.conf"
sudo rmmod rds_tcp 2>/dev/null
sudo rmmod rds_rdma 2>/dev/null
sudo rmmod rds 2>/dev/null

If the business does not depend on io_uring, consider disabling or restricting it:

`1`	`sudo sysctl -w kernel.io_uring_disabled=2`

Persistent configuration needs to be written into the appropriate /etc/sysctl.d/*.conf file. Be careful with this step: modern databases, proxies, runtimes, or high-performance I/O programs may use io_uring. Confirm business dependencies before changing production systems.

How to Verify After Fixing

After upgrading the kernel, do not rely only on package-manager success output. Confirm three things:

1
2
3

uname -a
cat /proc/sys/kernel/io_uring_disabled 2>/dev/null
modprobe -n -v rds_tcp 2>&1 | head -3

If a distribution advisory explicitly says CVE-2026-43494 is fixed, the kernel may still be protected even when uname -r does not look like the newest upstream release, because the stable distribution kernel may have received a backported patch. Conversely, if the kernel comes from a self-built tree, third-party repository, cloud marketplace image, or container host template, continue checking the patch commit and build time.

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

Wed, 20 May 2026 23:00:37 +0800

Several high-profile local security issues have appeared in the Linux ecosystem recently. Individually, they involve different areas: crypto interfaces, network and IPsec paths, page cache handling, and ptrace access checks. Together, they point to the same operational lesson: once an attacker has a low-privilege local execution point, the risk to Linux hosts, container nodes, CI machines, and multi-user servers increases sharply.

This article does not repeat all technical details of each vulnerability. Instead, it summarizes their practical impact and links to four separate articles on this site for deeper reading.

What the Four Events Affect

The four risks worth tracking are:

Copy Fail (CVE-2026-31431): a low-privilege local user may affect the page cache through kernel crypto-related paths and expand privileges.
Dirty Frag (related to CVE-2026-43284 / CVE-2026-43500): risk centers on xfrm/ESP, RxRPC, and related network and kernel data paths, making it dangerous in post-compromise scenarios.
Fragnesia (CVE-2026-46300): close to Dirty Frag, involving XFRM ESP-in-TCP, shared fragments, and page-cache write risk.
ssh-keysign-pwn (CVE-2026-46333): not a direct root-shell bug, but a local information disclosure risk that may expose SSH host private keys, /etc/shadow, and other sensitive files.

The entry points differ, and so do the mitigations. Fixing Copy Fail does not automatically cover Dirty Frag or Fragnesia. Disabling some network modules does not automatically remove the information disclosure risk around ssh-keysign-pwn.

Copy Fail: High Priority for Containers and CI Nodes

The key impact of Copy Fail is not an application crash. It is that low-privilege execution may be turned into root privileges. It is especially sensitive in these environments:

CI/CD nodes that allow users to upload or run code.
Container hosts running untrusted workloads.
Development machines, jump hosts, and shared servers.
Cloud hosts running older kernels with slower patch cycles.

The danger is that Copy Fail has a relatively low exploitation threshold and combines easily with container scenarios. Many teams treat containers as a strong isolation boundary, but ordinary containers still share the host kernel by default. If an attacker gets a shell inside a container, a kernel LPE can turn a container issue into a host issue.

Detailed analysis: Copy Fail CVE-2026-31431: Container Escape Risk in a Linux Kernel File-Copy Path.

Dirty Frag: A Post-Compromise Amplifier

Dirty Frag is more like a privilege amplifier after an attacker has entered a system. It is not a typical remote unauthenticated vulnerability. The usual prerequisite is that the attacker already has local execution through a weak password, WebShell, low-privilege service account, container task, or another foothold.

Its practical impact appears in several places:

A compromised low-privilege account may become root.
A low-privilege execution point inside a container may threaten the host.
Systems using IPsec, ESP, RxRPC, or related kernel networking capabilities need careful patch and mitigation review.
Security teams should look beyond perimeter defense and include post-compromise privilege escalation chains.

Dirty Frag reminds operations teams that local privilege escalation may not be the first entry point, but it can decide how far an intrusion goes. Once a low-privilege foothold exists, attackers will look for kernel bugs to push privileges to the highest level.

Detailed analysis: Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide.

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

Fragnesia matters because it shows that the attack surface near Dirty Frag is not an isolated one-off issue. Even if one bug is fixed, neighboring paths, similar data structures, and related module combinations may still contain new exploitable points.

Its operational impact is mainly:

Do not handle only the vulnerability name once. Keep checking by attack surface.
esp4, esp6, rxrpc, XFRM, and ESP-in-TCP should be evaluated against actual business dependencies.
If a system does not depend on the related network capabilities, temporary disabling may be considered, but it must be tested first to avoid breaking VPN, IPsec, tunnels, or internal networking.
Page-cache pollution risks can create detection blind spots where files appear unchanged, but the execution path is affected.

For enterprises, the biggest lesson is that patch management should not look only at a single CVE. A safer approach is to build an inventory around subsystems and attack surfaces, then identify which machines expose the relevant capabilities and which services truly need those modules.

Detailed analysis: Fragnesia (CVE-2026-46300): Linux Kernel Local Privilege Escalation Impact and Mitigation.

ssh-keysign-pwn: Not Direct Root, Still Dangerous

ssh-keysign-pwn differs from the previous three. It is more of a local sensitive information disclosure issue than a direct root-shell vulnerability. But in real attacks, sensitive information disclosure can quickly become a larger incident.

The main impacts include:

Leaked SSH host private keys may damage host identity trust.
Access to files such as /etc/shadow can lead to offline cracking and account takeover.
Multi-user servers, jump hosts, build machines, and shared development machines carry higher risk.
Even without immediate privilege escalation, attackers may obtain credential material useful for lateral movement.

This type of issue is easy to underestimate because it does not look as dramatic as a direct root shell. In enterprise environments, however, key and password-hash exposure often means a longer cleanup cycle: rotating SSH host keys, reviewing trust relationships, checking account passwords, and auditing login logs.

Detailed analysis: ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk.

Shared Impact: Containers Are Not a Strong Boundary by Default

Taken together, these four events make one point clear: ordinary container isolation is not virtual-machine isolation.

Docker, containerd, and Kubernetes use namespaces, cgroups, capabilities, seccomp, AppArmor, and SELinux to reduce attack surface, but they usually still share the host kernel. If the vulnerability is in the shared kernel, a low-privilege execution point inside a container can become an entry point.

High-risk environments should check:

Whether untrusted code is allowed to run on shared hosts.
Whether containers run as root by default.
Whether unnecessary capabilities are granted.
Whether seccomp policies are too broad.
Whether multi-tenant workloads should move to gVisor, Kata Containers, Firecracker microVM, dedicated virtual machines, or dedicated nodes.

CI/CD platforms deserve special attention. Build jobs naturally run external code, dependency install scripts, test scripts, and temporary binaries. If these jobs share hosts with long-running services, one local privilege escalation can affect much larger infrastructure.

Shared Impact: Patches Must Reach the Running Kernel

A common Linux kernel patching mistake is assuming that an installed package means the machine is running the fixed kernel.

At minimum, operations teams should verify three things:

`1`	`uname -a`

Check the currently running kernel.

`1`	`dpkg -l \| grep linux-image`

Or on RHEL-family distributions:

`1`	`rpm -qa \| grep kernel`

Check installed kernel packages.

Finally, confirm that the machine has rebooted into the fixed kernel. For core services that cannot reboot immediately, evaluate livepatch, hot patching, or short-term isolation, but do not treat temporary mitigation as the final fix.

Shared Impact: Attack Surface Reduction Must Be Specific

These vulnerabilities remind us that Linux hardening cannot stop at “update the system” and “enable a firewall.”

More specific checks include:

Whether AF_ALG / algif_aead is used by business workloads.
Whether XFRM, ESP, ESP-in-TCP, and IPsec are required by VPNs, tunnels, or security gateways.
Whether RxRPC is needed.
Whether unprivileged user namespaces must be enabled.
Whether containers can create overly broad socket types.
Whether ptrace access policies are too loose.

If the business does not need certain capabilities, evaluate disabling modules, adjusting sysctl settings, tightening seccomp, and reducing capabilities. Do not blindly copy commands into production. Inventory dependencies first, then roll out changes gradually.

Suggested Response Order

First, prioritize machines where local code execution is exposed:

Container hosts.
CI/CD runners.
Jump hosts.
Multi-user servers.
Hosts running external-facing services.
Systems running untrusted plugins, scripts, or extensions.

Second, confirm distribution advisories and the actual running kernel. Do not rely only on upstream version numbers. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, SUSE, openEuler, and other distributions may backport security fixes.

Third, tighten container runtime policies. Prefer non-root users, minimal capabilities, no-new-privileges, read-only filesystems, and explicit seccomp plus AppArmor or SELinux policies.

Fourth, review key and credential exposure. Especially for environments affected by ssh-keysign-pwn, evaluate whether SSH host keys, /etc/shadow, jump-host credentials, and CI secrets need rotation.

Fifth, improve monitoring. Watch for abnormal root shells, suspicious local LPE PoCs, critical file changes, abnormal ptrace behavior, container processes accessing host paths, and unusual network connections from CI nodes.

Conclusion

The point of these four events is not “Linux is insecure.” The point is that default trust is no longer enough.

Linux remains transparent, fixable, configurable, and hardenable. But in environments where containers, CI, multi-tenancy, and AI-driven code execution are increasingly common, a low-privilege execution point can no longer be treated as a minor issue. If the kernel contains exploitable local privilege escalation or sensitive information disclosure bugs, a partial intrusion can become host control, credential exposure, or lateral movement.

A more realistic approach is to treat these four events as a reminder: patch quickly, confirm rebooted kernels, enable modules only when needed, tighten containers, make key rotation possible, and reassess isolation levels for multi-tenant workloads.

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn refers to a set of exploitation paths around a logic flaw in Linux kernel __ptrace_may_access(), assigned CVE-2026-46333. It is not a remote unauthenticated flaw and it does not directly hand out a root shell, but the risk is still high: a low-privileged local user may read root-owned sensitive files that should be inaccessible, such as SSH host private keys or /etc/shadow.

For operations teams, the priority is not reproducing a PoC. The priority is to identify affected machines, upgrade the kernel, reboot into the fixed kernel, and rotate SSH host keys or reset passwords when necessary.

Bottom line

This vulnerability deserves high handling priority for four reasons:

It can be triggered by a low-privileged local user and does not require root.
Public PoC code is available, lowering the exploitation barrier.
The potential targets are not ordinary files, but SSH host private keys and /etc/shadow.
The fix requires a kernel patch and reboot; installing packages without rebooting is not enough.

If your servers have multiple users, local shell access, shared hosting, CI runners, container hosts, student lab machines, bastion hosts, or any local users you do not fully trust, handle this first.

What the vulnerability is

Qualys disclosed details on oss-security on May 15, 2026. They had previously reported a Linux kernel __ptrace_may_access() logic issue to security@kernel.org, and the upstream fix had already been merged by Linus. Public exploit code then appeared, so Qualys posted the details to oss-security.

The Linux kernel CVE team later assigned CVE-2026-46333. The NVD page lists kernel.org as the source, and the description maps to the kernel commit ptrace: slightly saner 'get_dumpable()' logic.

In simple terms, the bug sits in a process exit path. When some privileged processes are exiting, ptrace-related access-check logic in the kernel may bypass a dumpable check that should have applied because the target task no longer has an mm. An attacker can race a very narrow timing window and obtain file descriptors that the exiting privileged process still has open.

That is why the issue is called ssh-keysign-pwn: one public exploitation path uses ssh-keysign to read SSH host private keys.

Why SSH host private keys and /etc/shadow may be exposed

At its core, this is a local information disclosure issue. It abuses a window during privileged process exit where the memory descriptor is gone, but file descriptors have not yet been closed.

The AlmaLinux advisory explains the risk clearly: if a privileged program opened sensitive files before dropping privileges, and an attacker successfully grabs the corresponding file descriptor during the exit window, those sensitive files may become readable.

Two commonly discussed targets are:

ssh-keysign: may involve SSH host private keys such as /etc/ssh/ssh_host_*_key.
chage: may involve /etc/shadow.

If SSH host private keys leak, an attacker may impersonate the host and undermine SSH host identity trust. If /etc/shadow leaks, an attacker can crack password hashes offline and expand the compromise later.

That is why this should be treated as high priority even though it is not a “direct root shell” bug.

How to assess exposure

From the upstream perspective, this is a Linux kernel vulnerability. NVD records show the issue entered the NVD dataset on May 15, 2026, with no CVSS score assigned at that time.

Distribution status should be checked against each vendor’s own advisory:

AlmaLinux 8, 9, and 10 published guidance and updated it on May 16, 2026 to say patched kernels had reached production repositories.
Debian Security Tracker lists vulnerable and fixed states, plus fixed versions, for bullseye, bookworm, trixie, sid, and other branches.
For other distributions, check the official security pages or repositories for Ubuntu, Red Hat, SUSE, Arch, Alpine, and so on.

Do not judge safety only by the upstream kernel version. Distributions backport fixes, so the same upstream-looking version number may mean different patch states across distributions.

Which machines to prioritize

Prioritize remediation in this order:

Multi-user servers and shared hosts.
Bastion hosts, teaching machines, development machines, and other systems with normal shell accounts.
CI runners, build machines, and hosting platform nodes.
Container and virtualization hosts, especially where not-fully-trusted workloads coexist.
Public service machines. The vulnerability needs local access, but the risk compounds once a web bug, RCE, weak password, or similar path gives an attacker a low-privileged foothold.

Pure single-user desktop systems are lower risk, but they should still be updated. Local low-privileged code execution is common on desktops through browsers, developer tools, scripts, and third-party software.

Remediation guidance

The preferred fix is to install the fixed kernel supplied by your distribution and reboot.

Commands differ by distribution, but the principle is the same:

Refresh package metadata.
Install the kernel package containing the CVE-2026-46333 fix.
Reboot into the new kernel.
Use uname -r and the distribution security advisory to verify the running kernel is fixed.

The AlmaLinux advisory says fixed kernels are available in production repositories and users can run the usual dnf upgrade and reboot. The Debian tracker also lists fixed versions for multiple branches.

Important: if you only install a new kernel package but do not reboot, the old vulnerable kernel is still running.

Temporary mitigation: tighten ptrace_scope

If you cannot reboot immediately, tighten Yama ptrace_scope first.

Qualys confirmed in a follow-up oss-security reply that setting /proc/sys/kernel/yama/ptrace_scope to 2 (admin-only attach) or 3 (no attach) blocks the public exploitation paths they know about. They also noted that other theoretical exploitation paths may exist, so this is only a mitigation, not a fix.

Temporary setting:

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

Persistent setting:

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 disables ptrace attach and may affect debugging workflows such as gdb and strace -p. If production debugging is required, evaluate 2. Either way, schedule the kernel upgrade and reboot as soon as possible.

Should SSH host keys be rotated?

Use a conservative approach if the machine had any of the following conditions around the disclosure window:

Untrusted local users.
Shared hosting or container/CI multi-tenant environments.
Web vulnerabilities, weak passwords, supply-chain scripts, or other paths that could give an attacker a local foothold.
Suspicious local processes, unusual debugging behavior, or public PoC files in logs.
Long exposure before patching.

Conservative handling includes:

Rotate SSH host keys after patching and rebooting.
Update known-host fingerprint management systems.
Notify automation that depends on the host fingerprint.
Review SSH connection alerts so legitimate fingerprint changes are not mistaken for man-in-the-middle attacks, and real risks are not ignored.

If /etc/shadow may have leaked, also evaluate password resets, weak-password bans, and whether old hashes could be cracked offline.

What to monitor

The exploitation window is short, so traditional logs may not capture everything. Still, watch for:

Files such as ssh-keysign-pwn, chage_pwn, or similar PoC artifacts in normal user directories.
Suspicious compilation activity, such as unfamiliar C programs compiled in a short window.
Signs of abnormal access to /etc/ssh/ssh_host_*_key or /etc/shadow.
Unusual pidfd_getfd, ptrace, or debugger-related activity.
External reports of unexpected SSH host fingerprint changes.

These signals cannot prove exploitation occurred, and their absence cannot prove it did not. The real priorities remain patching, rebooting, credential rotation, and risk isolation.

Common misconceptions

First: this is not an OpenSSH remote vulnerability. The name includes ssh-keysign, but the root cause is Linux kernel ptrace access-check logic, not the remote authentication path in sshd.

Second: no local users does not mean no risk. The bug does require local execution, but real attack chains often obtain a low-privileged local foothold first through web services, CI, scripts, weak passwords, or container escape paths.

Third: setting ptrace_scope is not enough. It is a temporary mitigation, not the root fix. Kernel update and reboot are still required.

Fourth: “no root shell” does not mean “no incident.” Exposure of SSH host private keys or /etc/shadow can be enough to enable lateral movement, host impersonation, and offline password cracking.

Response checklist

Suggested order:

Inventory affected Linux hosts, especially multi-user and shared environments.
Check distribution security advisories and identify the fixed kernel version.
Install the fixed kernel and reboot.
For machines that cannot reboot immediately, set kernel.yama.ptrace_scope=2 or 3.
After remediation, verify the running kernel version.
Rotate SSH host keys on high-risk machines.
If /etc/shadow exposure is suspected, evaluate password resets and account audits.
Check for public PoCs, unusual compilation, and suspicious local debugging behavior.

Summary

ssh-keysign-pwn (CVE-2026-46333) is a local information disclosure vulnerability rooted in Linux kernel __ptrace_may_access() logic. It does not allow a remote attacker to break in directly and it does not directly grant a root shell, but it may let a low-privileged local user read high-value sensitive files, making it especially important in multi-user, shared hosting, CI, and container-host environments.

The reliable fix is to upgrade to a distribution-provided fixed kernel and reboot. ptrace_scope=2/3 can be used as a temporary mitigation, but it does not replace patching. Critical hosts exposed during the risk window should also be evaluated for SSH host key rotation and password risk.

References:

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

Fri, 15 May 2026 13:24:04 +0800

Several high-profile Linux kernel local privilege escalation vulnerabilities have appeared recently: Dirty Frag, Copy Fail, and Fragnesia. They look like a single family of events because the end result is similar: a low-privilege local user may be able to become root.

But from an operations perspective, they should not be treated as one vulnerability. Their entry modules, trigger paths, mitigation options, and patch timelines differ. A better way to understand them is this: they expose a shared risk around the complex boundary between the Linux page cache, splice, socket buffers, and crypto paths.

This post only covers risk and response analysis. It does not include reproducible exploitation steps.

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Dirty Frag mainly points to a page-cache write issue in the Linux kernel networking path. Public write-ups usually discuss it together with two issues: the xfrm-ESP side, CVE-2026-43284, and the rxrpc side, CVE-2026-43500.

CVE-2026-43284 is related to in-place decryption when ESP handles shared skb fragments. The key point is not that an attacker directly modifies a disk file, but that the kernel can write to shared pages it should not modify, affecting file contents in the page cache.

Operationally, remember that Dirty Frag reaches esp4, esp6, and rxrpc, a set of kernel modules and networking subsystem paths. It is tied to IPsec, ESP, and RxRPC, so temporary mitigation also focuses on those modules.

Copy Fail: CVE-2026-31431

Copy Fail is a Linux kernel local privilege escalation vulnerability disclosed by Theori / Xint Code. Its entry point is not the IPsec networking path, but the kernel userspace crypto API around algif_aead / AF_ALG.

Public explanations describe it as originating from an in-place optimization introduced in 2017. In some cases, the kernel failed to copy data as expected and instead placed page-cache pages into a writable destination path. An attacker can combine AF_ALG with splice() to perform a small controlled write to page-cache-backed pages.

Its risk comes from strong exploitability and broad impact across mainstream distributions. Unlike Dirty Frag, Copy Fail’s temporary mitigation focuses on restricting or disabling algif_aead, and on limiting AF_ALG socket creation in container and CI environments.

Fragnesia: CVE-2026-46300

Fragnesia is another Linux kernel local privilege escalation vulnerability disclosed by V12 Security, and it belongs to a similar attack surface as Dirty Frag. It is not the same bug as Dirty Frag, but it still revolves around IPsec ESP / rxrpc related modules and page-cache write effects.

AlmaLinux describes it as the third local-root issue in the same broad code area. The key problem is that skb_try_coalesce() did not preserve the shared-fragment marker when coalescing socket buffer fragments, which could later let the XFRM ESP-in-TCP receive path decrypt in place over external page-cache pages.

In short, Fragnesia is closer to Dirty Frag. Both revolve around esp4, esp6, rxrpc, skb fragments, and ESP decryption paths. Their temporary mitigations also overlap heavily.

Similarities: Why They Are Dangerous

The common thread is not that the exact code locations are identical, but that the attack outcome and risk model are very similar.

First, all three are local privilege escalation issues. Attackers usually need ordinary local code execution first, then they can attempt to become root. For a single-user desktop this is not remote one-click compromise; for multi-user servers, CI runners, container hosts, shared development machines, and VPS instances with exposed SSH, low-privilege entry points are not rare.

Second, all three involve page-cache writes. Attackers may not permanently modify the file on disk; instead, they affect the in-memory page-cache copy. This makes traditional integrity checks less reliable: the disk hash can remain normal while the execution path reads polluted page-cache content.

Third, they are closer to deterministic logic bugs than timing-sensitive race conditions. Public material repeatedly notes that these issues do not require winning a race condition. Defenders should not underestimate exploit reliability based on older assumptions.

Fourth, they amplify the risk of container and automation environments. Low-privilege code inside containers, CI jobs, build scripts, or third-party plugins can turn a “local issue” into a platform-level issue if it can reach the relevant host kernel interfaces.

Differences: One Mitigation Does Not Cover All

The biggest difference is the entry module.

Copy Fail’s critical entry point is algif_aead / AF_ALG, part of the kernel userspace crypto API. Its temporary defense focuses on disabling or restricting algif_aead, and using seccomp to block containers from creating AF_ALG sockets.

Dirty Frag’s critical entry point is xfrm-ESP and rxrpc. It is closer to protocol and socket buffer handling paths. Temporary defense typically considers disabling esp4, esp6, and rxrpc, but that can affect IPsec, VPNs, tunnels, or related networking capabilities.

Fragnesia sits in a similar region to Dirty Frag, but the concrete issue is that skb_try_coalesce() did not preserve the shared-fragment marker. It is more like another branch of the Dirty Frag risk surface than a Copy Fail crypto API issue.

So, fixing Copy Fail does not mean Dirty Frag and Fragnesia are covered. Likewise, disabling esp4 / esp6 does not automatically remove Copy Fail. Their patch state and mitigation strategy must be checked separately.

How to Judge Exposure

For these vulnerabilities, do not judge only by distribution name or kernel major version. Distributions backport fixes, cloud vendors maintain their own kernel branches, and enterprise distributions may carry additional patches.

A safer sequence is:

Check the distribution security advisory and kernel package changelog.
Verify whether the current kernel package fixes the relevant CVE.
For cloud servers, container hosts, and CI nodes, also check cloud or platform advisories.
For temporary mitigations, confirm whether the business depends on the affected module.
After a kernel update, schedule a reboot and confirm the running kernel has changed.

The most common trap is “the package is updated, but the machine has not rebooted.” Kernel vulnerabilities are not like ordinary userspace service updates. Until the system boots into the new kernel, the old kernel may still be running.

Operational Priority

The systems that deserve the highest priority are not all Linux machines equally. Start where low-privilege code execution is most likely.

Highest-priority environments include:

Multi-user login servers
CI / CD runners
Build and artifact packaging machines
Container hosts and Kubernetes nodes
Shared development machines
Cloud servers and VPS instances exposing SSH
Platforms running third-party scripts, plugins, or job queues
Machines with web vulnerabilities, weak passwords, or historical compromise signals

Closed, single-user machines with no external code execution entry point are still at risk if vulnerable, but they can usually be handled later.

How to Treat Temporary Mitigation

Temporary mitigation is not a replacement for a patch. Its value is reducing exposure when you cannot immediately reboot or are waiting for distribution packages.

For Copy Fail, focus on algif_aead and AF_ALG. If the business does not use the kernel AF_ALG crypto interface, evaluate disabling the related module. In container environments, check seccomp policies first so untrusted workloads cannot freely create the relevant socket.

For Dirty Frag and Fragnesia, focus on esp4, esp6, and rxrpc. If the system does not depend on IPsec ESP, related VPNs, tunnels, or RxRPC, consider temporary disabling. Do not do this blindly in production because these modules may support real networking workloads.

The final path is still a kernel update. Temporary mitigation can reduce attack surface, but it cannot prove the system is fully safe.

What These Three Flaws Tell Us

The important warning is not just the number of CVEs. These flaws all cluster around high-complexity kernel paths: zero-copy, splice, socket buffers, the page cache, crypto interfaces, and protocol-stack optimizations.

These paths deliver performance, but their ownership boundaries are hard to maintain. Whether a fragment is shared, whether a page may be written in place, and whether an optimization truly only reduces copying all become security boundaries.

For security and operations teams, the takeaways are practical:

Treat local privilege escalation as an amplifier for existing low-privilege entry points.
Containers are not a natural isolation boundary for kernel vulnerabilities.
File integrity checks cannot look only at disk contents.
CI, build machines, and plugin platforms are high-priority assets.
Kernel patching requires verifying both “installed” and “running” states.

Summary

Dirty Frag, Copy Fail, and Fragnesia are all high-priority recent Linux local privilege escalation events, but they are not three names for one vulnerability.

Copy Fail goes through the algif_aead / AF_ALG crypto API path. Dirty Frag goes through xfrm-ESP and rxrpc. Fragnesia, in a nearby Dirty Frag attack surface, again triggers page-cache write risk through skb fragment marker handling.

Operationally, the safest response is to update the kernel according to distribution advisories and reboot. For systems that cannot be updated immediately, evaluate temporary module disabling or tighter seccomp rules based on the actual vulnerability entry point. Prioritize multi-tenant systems, CI, container hosts, and shared development environments.

References:

Theori Copy Fail notes: https://github.com/theori-io/copy-fail-CVE-2026-31431
CERT-EU Copy Fail advisory: https://cert.europa.eu/publications/security-advisories/2026-005/
AlmaLinux Dirty Frag notes: https://almalinux.org/blog/2026-05-07-dirty-frag/
AlmaLinux Fragnesia notes: https://almalinux.org/blog/2026-05-13-fragnesia-cve-2026-46300/
V12 Security Fragnesia PoC notes: https://github.com/v12-security/pocs/tree/main/fragnesia

Fragnesia (CVE-2026-46300): Impact and Mitigation for a Linux Kernel Local Privilege Escalation Flaw

Fri, 15 May 2026 13:18:01 +0800

The Linux kernel has another local privilege escalation issue in the same broad attack surface as Dirty Frag: Fragnesia (CVE-2026-46300).

According to V12 Security, Fragnesia is a Linux local privilege escalation vulnerability. An attacker does not need existing high privileges on the host. If they can execute local code, they may be able to abuse a logic flaw in the kernel’s XFRM ESP-in-TCP subsystem to modify read-only file contents through the page cache and eventually trigger a root shell.

Source:

V12 Security PoC notes: https://github.com/v12-security/pocs/blob/main/fragnesia/README.md

This post does not cover reproducible exploitation steps. It focuses on the operational risk and response path.

How It Relates to Dirty Frag

V12 Security classifies Fragnesia as part of the Dirty Frag vulnerability class. It is not the same bug as Dirty Frag, but it lives in a related attack surface: Linux kernel XFRM ESP-in-TCP.

XFRM is the Linux kernel framework for IPsec processing. ESP-in-TCP is related to carrying ESP encrypted traffic over TCP. Fragnesia comes from logic around shared page fragments and socket buffer coalescing: in some cases, the kernel can lose track of the fact that a fragment is still shared, leaving room for controlled writes.

This resembles the broader Dirty Pipe / Dirty Frag family of page-cache write issues. The concrete code paths differ, but the effect again lands on the page-cache copy of a read-only file.

Why the Risk Is High

Fragnesia is dangerous for three reasons.

First, it is a local privilege escalation. Once an attacker can run ordinary user-level code on a system, they may be able to become root. That matters especially on multi-user servers, container hosts, CI runners, shared development machines, VPS instances, and systems exposing shell access.

Second, it does not rely on a traditional race condition. V12’s notes describe a path that drives ESP-in-TCP processing over file-backed pages already spliced into a socket buffer, allowing byte-level influence over page-cache contents. That makes the issue more practical than a purely theoretical bug.

Third, it changes the page cache, not the on-disk file. The public notes use /usr/bin/su as an example target. After successful exploitation, the file on disk is not permanently modified; the modified copy lives in memory. Integrity checks that only compare disk hashes may miss this.

That is the awkward part for administrators: the file can look unchanged, but executing the polluted page-cache copy of a target binary may still trigger privilege escalation.

Known Affected Scope

V12 Security states that kernels affected by Dirty Frag and missing the relevant May 13, 2026 patches are also affected by Fragnesia. Publicly tested environments include Ubuntu 22.04, Ubuntu 24.04, and kernels such as 6.8.0-111-generic.

There are two important caveats.

First, do not judge only by the distribution major version. Whether Ubuntu 22.04 or 24.04 is affected depends on the actual kernel patch state, not just the distribution name.

Second, do not rely only on default AppArmor restrictions for unprivileged user namespaces. Ubuntu’s AppArmor restrictions can raise the bar, but the disclosure treats that as an additional bypass problem, not as a fix for the vulnerability itself.

The reliable path is still to check distribution security advisories and kernel package updates.

Temporary Mitigation

If a system cannot be upgraded immediately, first check whether it depends on the relevant protocol modules.

V12 gives the same mitigation direction as Dirty Frag: if the system does not depend on IPsec ESP or RxRPC, administrators can consider disabling modules such as esp4, esp6, and rxrpc. This can affect networking features, so production systems should not do it blindly. Confirm whether the environment uses IPsec, VPNs, tunnels, or related kernel functionality.

A safer response order is:

Check whether the distribution has published a kernel security update.
Install the kernel patch and schedule a reboot first.
If immediate upgrade is impossible, evaluate temporary module disabling.
Prioritize multi-user systems and CI / build environments.
Review unnecessary local accounts, shell access, container escape surface, and low-privilege execution entry points.

Disabling modules should not be treated as the final fix. It is only a way to reduce exposure while moving toward a patched kernel.

If Exploitation Is Suspected

One key feature of Fragnesia is page-cache pollution. V12 notes that after exploitation, the target file’s page-cache copy may contain injected content, and later execution can still behave abnormally until the page is evicted or the system is rebooted.

If exploitation is suspected, do at least the following:

Preserve logs and audit records as soon as possible.
Check recent abnormal local logins, low-privilege user activity, suspicious processes, and root shell traces.
Clear the relevant page cache or reboot directly.
Upgrade to a fixed kernel.
Verify key binaries, but do not rely only on disk hashes.
Rotate potentially exposed credentials and keys.

For production servers, it is better to treat this as a potential local privilege escalation incident, not merely as a routine patch event.

Which Machines Should Come First

The highest priority is not every Linux machine equally. Start with systems where attackers are most likely to obtain low-privilege code execution.

High-priority environments include:

Multi-user login servers
CI / CD runners
Build machines
Shared development machines
Container hosts
VPS and cloud servers
Edge nodes exposing SSH
Platforms running third-party scripts or plugins

Closed, single-user machines with no external code execution entry point are still affected if vulnerable, but their urgency is lower.

Summary

Fragnesia matters not because it has a new name, but because it again pulls Linux local privilege escalation back into the difficult boundary between the page cache and kernel networking subsystems.

For administrators, the important work is to confirm kernel patch status, understand whether ESP / RxRPC is in use, prioritize highly exposed machines, and remember that “the disk file is unchanged” does not mean “the system was unaffected.”

If a system is affected, the final answer is still to install the distribution’s kernel update as soon as possible. Temporary module disabling is only a bridge, not a replacement for the patch.

Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide

Sat, 09 May 2026 07:25:55 +0800

Dirty Frag is a set of Linux kernel local privilege escalation vulnerabilities disclosed in May 2026 with signs of active exploitation. Microsoft describes it as a post-compromise risk: after an attacker gains low-privileged code execution, the bug may be used to escalate to root. Ubuntu has also marked CVE-2026-43284 as High.

The danger is not “remote one-click compromise”. The danger is that once an attacker gets in, they can expand control quickly. If they gain local execution through weak SSH credentials, a web shell, container escape, a low-privileged service account, or phishing-enabled remote access, Dirty Frag may let them obtain root and then disable security tools, read credentials, tamper with logs, move laterally, or persist.

Which CVEs are involved

Public information currently associates Dirty Frag mainly with two IDs:

CVE-2026-43284: related to the Linux kernel xfrm/ESP path. Microsoft’s esp4 and esp6 references belong to this risk area.
CVE-2026-43500: Microsoft says this is related to rxrpc, but as of May 8, 2026, the CVE had not yet been published in NVD and patch status was still evolving.

So do not check only one CVE. A safer approach is to review whether esp4, esp6, rxrpc, and related xfrm/IPsec functions are enabled, needed, and patched by your distribution.

Technical overview

According to Microsoft and Ubuntu, CVE-2026-43284 involves Linux kernel networking and memory-fragment handling, especially how shared page fragments are handled in the ESP/IPsec path.

In simplified terms, data pages can be attached to network buffers through mechanisms such as splice. If later kernel paths treat those fragments as privately owned and safe to modify in place, in-place decryption or modification can happen where it should not. An attacker may manipulate page cache behavior and eventually achieve local privilege escalation.

This has similarities to CopyFail (CVE-2026-31431): both involve Linux page cache behavior, kernel data paths, and local privilege escalation. Dirty Frag is dangerous because it adds more attack paths and may be more reliable than traditional LPE exploits that depend on tight race windows.

Environments to prioritize

Dirty Frag is a local privilege escalation vulnerability, so the attacker must already be able to execute code locally. Prioritize:

Linux servers with exposed SSH.
Web servers where a web shell could be written.
Multi-user login hosts, bastions, developer machines, and CI/CD runners.
Container hosts, Kubernetes nodes, and OpenShift nodes.
Systems using IPsec, VPN, xfrm, or RxRPC-related functionality.
Servers running Ubuntu, RHEL, CentOS Stream, AlmaLinux, Fedora, openSUSE, and other mainstream distributions.

If a server has no local multi-user access, no containers, and no exposed application path, risk is lower. But any system where an attacker might obtain a low-privileged shell should treat this as a high-priority kernel issue.

Patch first

The safest fix is to install the kernel security update from your distribution and reboot into the new kernel.

Ubuntu’s CVE page shows CVE-2026-43284 was published on May 8, 2026 and is rated High. Microsoft also says the Linux Kernel Organization has released fixes for CVE-2026-43284 and urges customers to apply patches promptly.

Start by checking the system:

1
2

uname -a
cat /etc/os-release

Then update the kernel using your distribution’s package manager:

`1`	`sudo apt update && sudo apt full-upgrade`

Or:

`1`	`sudo dnf update`

After updating, confirm that the system has rebooted into the new kernel:

`1`	`uname -r`

Installing kernel packages without rebooting leaves the old kernel running, so the vulnerability may still be present.

If patches are not yet available, or production cannot reboot immediately, evaluate whether you can temporarily disable the related modules. Ubuntu’s mitigation blocks esp4, esp6, and rxrpc from loading and unloads them if already loaded.

Create modprobe blocking rules:

1
2
3

echo "install esp4 /bin/false" | sudo tee /etc/modprobe.d/dirty-frag.conf
echo "install esp6 /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf
echo "install rxrpc /bin/false" | sudo tee -a /etc/modprobe.d/dirty-frag.conf

Update initramfs so the modules are not loaded during early boot:

`1`	`sudo update-initramfs -u -k all`

Unload currently loaded modules:

`1`	`sudo rmmod esp4 esp6 rxrpc 2>/dev/null`

Check whether the modules are still loaded:

`1`	`grep -qE '^(esp4\|esp6\|rxrpc) ' /proc/modules && echo "Affected modules are loaded" \|\| echo "Affected modules are NOT loaded"`

If a module is in use, unloading may fail. In that case, the block rule may only take effect after reboot.

Evaluate business impact before disabling

Do not paste the mitigation blindly. esp4, esp6, and xfrm/IPsec functionality may be used by VPNs, tunnels, encrypted networking, Kubernetes/container networking, or enterprise network configurations. rxrpc may also affect workloads that depend on that protocol.

Before using the mitigation in production, check at least:

1
2
3

lsmod | grep -E '^(esp4|esp6|rxrpc|xfrm)'
ip xfrm state
ip xfrm policy

If you depend on IPsec VPN or related kernel networking, disabling modules may break connectivity. In that case, schedule kernel patching and a maintenance reboot rather than relying on module blocking for long.

Do not skip post-compromise checks

Microsoft specifically notes that mitigation does not necessarily undo changes already made by successful exploitation. If an attacker already gained root, they may have left persistence, modified files, altered logs, or accessed session data.

At minimum, check:

journalctl -k --since "24 hours ago" | grep -Ei "dirty|frag|exploit|segfault|xfrm|rxrpc|esp"
last -a
lastlog
sudo find /tmp /var/tmp /dev/shm -type f -mtime -3 -ls
sudo find / -perm -4000 -type f -mtime -7 -ls 2>/dev/null

Also review:

Abnormal su, sudo, or SUID/SGID process launches.
Newly created ELF executables.
Suspicious PHP, JSP, or ASP files in web directories.
Changes to SSH authorized_keys.
New persistence in systemd services, cron, or rc.local.
Suspicious privileged containers or host mounts.

If exploitation is suspected, isolate the host, preserve evidence, rotate credentials, and then clean up. Do not assume that unloading modules or clearing caches makes the system safe.

About drop_caches

Microsoft mentions that in some post-exploitation integrity verification scenarios, cache clearing may be evaluated:

`1`	`echo 3 \| sudo tee /proc/sys/vm/drop_caches`

This is not a vulnerability fix and not an incident cleanup command. Dropping caches can increase disk I/O and affect production performance. Use it only as an auxiliary step after understanding the impact. The real fix remains patching, rebooting, verifying integrity, and checking persistence.

Recommended response order

For production environments, a reasonable response sequence is:

Inventory Linux assets and kernel versions.
Prioritize systems with exposed SSH, web workloads, container hosts, and multi-user access.
Patch and reboot systems that can be restarted quickly.
For systems that cannot yet patch or reboot, evaluate disabling esp4, esp6, and rxrpc.
Increase monitoring for su, SUID/SGID activity, suspicious ELF files, web shells, and container escape indicators.
Run post-compromise checks and rotate credentials on hosts that may already have been exploited.

Summary

Dirty Frag is not a “remote one-click” vulnerability, but it significantly increases post-compromise risk. If an attacker can run code locally with low privileges, CVE-2026-43284 and the related rxrpc attack surface may allow escalation to root.

For administrators, the priority is not studying PoCs. The priority is to confirm kernel exposure, install distribution security updates and reboot, evaluate module-blocking mitigations before the patch window, and inspect exposed or suspicious systems for integrity and persistence issues.

References:

Btrfs Scrub Guide: Data Verification, Auto-Repair, and Regular Maintenance

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub is one of the most important and most misunderstood Btrfs maintenance features. It is not fsck in the traditional sense. It is an online validation pass that reads filesystem data and metadata, verifies checksums, superblocks, metadata block headers, and disk read errors, and tries to repair damage when a known good replica exists.

If you use Btrfs on a NAS, home server, backup disk, or multi-device array, scrub should be part of regular maintenance. Its value is not “run it after disaster”. Its value is finding silent corruption early, while disks are still readable and good replicas still exist.

What scrub checks

According to the official Btrfs documentation, scrub scans filesystem data and metadata and mainly checks:

Data block checksum errors.
Basic super block errors.
Basic metadata block header errors.
Disk read errors.

On filesystems using replicated block group profiles such as RAID1, scrub on a read-write mount can automatically repair some damage. The repair is not magic recovery. Btrfs copies verified good data from another replica.

This is the key point: scrub repair depends on having a known good copy. On a single disk with only one copy of the data, scrub can detect checksum errors, but it usually cannot restore the original content by itself.

Common commands

Start scrub on a mount point:

`1`	`sudo btrfs scrub start /`

Run it in the foreground, useful for manual observation:

`1`	`sudo btrfs scrub start -B /`

Check status:

`1`	`sudo btrfs scrub status /`

Cancel a running scrub:

`1`	`sudo btrfs scrub cancel /`

Resume an interrupted scrub:

`1`	`sudo btrfs scrub resume /`

If you specify a Btrfs mount path, Btrfs scrubs all devices in that filesystem in parallel. If you specify a device, only that device is scrubbed. But if the replica on the specified device cannot be read or verified, Btrfs still tries to read a good copy from another device.

Scrub is not fsck

This is the easiest mistake to make. Scrub is not btrfs check, nor a traditional filesystem checker.

Scrub can:

Use checksums to detect data or metadata corruption.
Auto-repair when another reliable replica exists.
Detect disk read errors and some basic structural errors.

Scrub cannot:

Rebuild data when no good replica exists.
Replace offline filesystem checking.
Repair all complex tree-structure corruption.
Guarantee that application-level file contents are correct.

If filesystem structures are badly damaged, tools such as btrfs check may be needed under expert guidance. Do not treat scrub as a universal repair command.

NOCOW file risks

The Btrfs documentation calls out an important caveat: setting the NOCOW attribute with chattr +C currently also enables NODATASUM. That means the file data itself has no checksum.

Scrub can still validate and repair metadata for these files, but it cannot validate their data contents. This is especially risky in multi-replica setups: if one copy of a NOCOW file is damaged, Btrfs has no data checksum to tell which replica is good, so it may return bad contents to user space.

Some applications use +C by default for performance. systemd journal and some libvirt storage pool scenarios are notable examples. For VM images, databases, and log directories, this can make sense for performance, but it also means you cannot expect scrub to protect their data contents the same way it protects normal COW files.

Read-only scrub can still write

Another counterintuitive point: running read-only scrub on a read-write mounted filesystem can still cause some writes.

The official documentation explains that this is due to a design limitation around avoiding races between marking block groups read-only and writing back block group items. In other words, if you want scrub to perform no writes at all, you need to run read-only scrub on a read-only mounted filesystem. Adding a read-only scrub option on a read-write mount is not enough.

For normal users, this means:

Routine online scrub can run on a read-write mount.
For forensics, failure analysis, or very conservative read-only checks, confirm the mount state first.
Do not interpret read-only scrub as absolutely zero-write.

Interruption and resume

On newer kernels, scrub may be interrupted by events such as suspend, hibernate, filesystem freezing, cgroup freezing, and pending signals. After such an interruption, the running scrub is cancelled, but it can be resumed with btrfs scrub resume.

Scrub status is recorded under:

`1`	`/var/lib/btrfs/`

File names usually look like:

1
2

scrub.status.UUID
scrub.progress.UUID

The status file is updated periodically. A resumed scrub continues from the last saved position instead of starting completely over.

How often to run it

The official recommendation is once per month. In practice, adjust based on data importance and disk condition.

Common schedules:

Home NAS: once per month.
Backup disks: after long attachment sessions or once per month.
Important multi-device arrays: once per month, or more often if needed.
New disk migration or suspected disk problems: run immediately after migration.

Scrub may use around 80% of device bandwidth on an idle filesystem, so do not run it during peak workload. On HDD arrays, latency can rise noticeably during scrub. On SSDs, it still adds read amplification and background pressure.

Limiting scrub bandwidth

In the past, ionice was often used to reduce scrub impact on foreground I/O. The official documentation warns that this is not supported equally by all I/O schedulers. CFQ is no longer generally available. BFQ supports the relevant priority behavior, but you should understand it before using it. For common schedulers such as mq-deadline, cgroup2 I/O controller or Btrfs-specific limits are usually better.

Example using systemd to limit read bandwidth:

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Since Linux 5.14, Btrfs can set per-device scrub limits through sysfs:

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

Show current limits:

`1`	`sudo btrfs scrub limit /`

This setting is not persistent and disappears when the filesystem is unmounted. Replace FSID and DEVID with the actual values for your system. You can start by checking:

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

Practical maintenance workflow

A reasonable Btrfs maintenance workflow can look like this:

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

If scrub reports corrected errors, Btrfs has repaired data from a good replica, but you should not ignore it. Continue checking disk SMART, cables, power, controllers, and Btrfs device stats.

If scrub reports uncorrectable errors, Btrfs could not find a good copy. Back up whatever can still be read, identify the affected files or device, and replace hardware or restore from backup as needed.

Summary

Btrfs scrub has a clear role: online data verification and replica repair. It is not fsck, and it is not backup.

It works best on Btrfs filesystems with checksums and redundant replicas, where it can regularly find silent corruption and restore from good copies. It cannot protect NOCOW file data without checksums, and it cannot recover damaged contents without a good replica.

If you store important data on Btrfs, run scrub monthly and use it together with SMART, device stats, backups, and alerting. Reliable data safety comes from checksums, redundancy, monitoring, and backups working together, not from a single command.

References:

Btrfs official documentation: Scrub

Does F2FS Freeze an HC620 SMR Drive? Linux SMR Disk Troubleshooting Guide

Fri, 08 May 2026 22:34:39 +0800

When an HC620 helium-filled SMR drive is used with F2FS, symptoms such as system freezes, unresponsive applications, and sustained high iowait are usually not caused by one bad option. They are the result of device behavior colliding with filesystem policy.

Western Digital Ultrastar DC HC620 is a Host-managed SMR drive. It is better suited to sequential writes, zoned-aware workloads, and software stacks that understand the device constraints. F2FS is a log-structured filesystem designed for flash storage. Although it can turn many random writes into sequential writes, heavy garbage collection, metadata updates, or low free space can still push a mechanical SMR drive into long internal maintenance cycles.

Confirm the problem first

Start with these checks:

1
2
3

iostat -x 1
iotop -oPa
dmesg -T | grep -Ei "f2fs|blk|zoned|reset|timeout|I/O error"

If disk %util stays close to 100%, await is high, and many processes are stuck in D state, the bottleneck is probably block I/O.

Then check whether the drive is exposed as a zoned device:

1
2

lsblk -o NAME,MODEL,SIZE,ROTA,ZONED,SCHED,MOUNTPOINTS
cat /sys/block/sdX/queue/zoned

If it is Host-managed SMR, ordinary filesystems and random-write workloads may perform poorly. Unlike consumer drive-managed SMR disks, this class depends more on host software understanding the write rules.

Why F2FS can amplify the stall

SMR cannot overwrite arbitrary locations as freely as CMR disks. Shingled tracks overlap to increase capacity. When writes become random, overwrites are frequent, or cache is exhausted, the drive must perform additional data movement and cleanup.

F2FS was built for NAND flash. It uses log-structured writes and reclaims space through segment cleaning and garbage collection. On SSDs this is natural because there is no mechanical seek. On mechanical disks, especially SMR disks, GC-related reads and writes can turn into severe tail latency.

When F2FS background GC, foreground writes, checkpoints, metadata updates, and the drive’s own SMR cleanup overlap, the I/O queue can stay saturated for a long time. From user space, copying files, deleting directories, downloading, extracting archives, or database writes may make the whole system feel frozen.

Start with conservative mount options

If you cannot migrate immediately, first adjust /etc/fstab:

`1`	`UUID=xxxx /data f2fs defaults,nodiscard,active_logs=2,gc_merge,flush_merge,lazytime 0 0`

What these options do:

nodiscard: disables real-time discard. Mechanical disks usually do not need frequent TRIM/discard behavior like SSDs.
active_logs=2: F2FS supports 2, 4, or 6 active logs, and the default is commonly 6. Reducing it to 2 can reduce seek pressure from concurrent logs.
gc_merge: lets the background GC thread handle some foreground GC requests, reducing stalls when a process triggers slow GC.
flush_merge: merges cache flush requests, which can help when the device handles flush slowly.
lazytime: reduces metadata writes caused by some access time updates.

Do not treat checkpoint=disable as a normal tuning switch. It may reduce checkpoint pressure, but it increases risk after crashes or power loss. Kernel documentation also notes that the filesystem still needs GC while checkpoint is disabled to ensure usable space. Unless you understand the tradeoff clearly, do not use it as a long-term performance fix.

Tune the I/O scheduler

Mechanical disks and SMR disks often benefit from request merging and latency control. Check the current scheduler:

`1`	`cat /sys/block/sdX/queue/scheduler`

Try switching to mq-deadline:

`1`	`echo mq-deadline \| sudo tee /sys/block/sdX/queue/scheduler`

For desktop interaction, bfq is also worth testing. Do not look only at sequential throughput. Watch whether freezes are reduced, await drops, and the system feels more responsive.

Limit F2FS background GC

The F2FS sysfs path depends on the actual device name. Check it first:

`1`	`ls /sys/fs/f2fs/`

Then adjust the GC interval for the matching device:

1
2

echo 60000 | sudo tee /sys/fs/f2fs/sdX/gc_min_sleep_time
echo 120000 | sudo tee /sys/fs/f2fs/sdX/gc_max_sleep_time

Here sdX is only an example. The actual name may be sda1, dm-0, or something else. Increasing GC sleep time reduces how often background GC competes for I/O, but space reclaim becomes slower. If the disk is nearly full, foreground GC may still be triggered, so keep enough free space.

Better long-term options

If the drive stores important data, the safest long-term answer is to back up and change the filesystem, or use a more suitable drive.

For large mechanical disks, consider:

XFS: good for large files, backup drives, media libraries, archives, and sequential-write workloads.
EXT4: stable behavior, broad compatibility, and abundant troubleshooting material.

If the drive is Host-managed SMR, also confirm that your kernel, controller, filesystem, and application stack truly support zoned block devices. Otherwise, using it like a normal random-write disk can lead to unpredictable long stalls.

Practical advice

This class of disk is better suited to cold data, archives, backups, media files, and sequential writes. It is a poor fit for download caches, container images, VM disks, databases, frequent archive extraction, and small-file random writes.

If you must keep using F2FS, at least do this:

Disable real-time discard.
Use active_logs=2 to reduce concurrent logs.
Enable gc_merge and flush_merge.
Keep plenty of free space.
Avoid placing downloads, databases, and VM images on this disk.
Watch iostat -x 1, not just average speed.

In short, HC620 + F2FS freezes are the result of SMR write constraints, F2FS GC, and mechanical disk tail latency stacking together. Short-term mitigation is mount-option tuning, scheduler tuning, and background GC limits. The long-term fix is to migrate to XFS/EXT4, or use the SMR drive only for workloads it actually suits.

References:

Canonical Ubuntu AI Roadmap: Local Inference First, No Forced Integration

Fri, 08 May 2026 22:23:46 +0800

Canonical’s recent Ubuntu AI roadmap is notable less for “putting AI everywhere” and more for trying a restrained path: AI features are layered, disabled by default, enabled only by explicit user choice, and designed to prefer local inference.

That stands apart from some of the controversy around system-level AI in Windows and macOS. Ubuntu is not trying to build an unavoidable global AI layer, nor is it promising one universal AI kill switch. Instead, the plan is to expose AI as separate tools, letting users decide whether to install them, enable them, choose a model, and allow data to leave the machine.

First, the timeline: not Ubuntu 26.04 LTS

The roadmap points mainly to Ubuntu 26.10 “Questing Quokka”, expected on October 9, 2026. Canonical plans to introduce some AI tooling as experimental previews, not as default features in Ubuntu 26.04 LTS.

That matters. LTS releases are meant for stability, enterprise deployment, and long-term maintenance. It would be unusual to place exploratory desktop AI features into an LTS default experience. A more reasonable path is to test them first in a regular release such as 26.10, gather feedback from developers and early users, and then decide what belongs in later long-term releases.

Local inference first, cloud only by choice

One core principle is local inference first. By default, inference should happen on the user’s machine. Requests should leave the machine only when the user explicitly configures a cloud provider, a self-hosted server, or an enterprise model service.

The reason is practical: system-level AI can easily touch command output, logs, file paths, errors, and system configuration. Sending that information to the cloud automatically, even to explain an error, creates obvious privacy and compliance risks.

So Ubuntu’s AI direction is not a cloud AI gateway. It is closer to a pluggable inference layer. Users may choose a local model, an internal company service, or a Canonical-managed service when needed. The important part is avoiding lock-in to one model vendor.

AI CLI: start with terminal assistance

One of the first practical features may be the AI Command Line Helper, often referred to as ai-cli.

It is not meant to replace the shell or automatically run risky commands. Its job is to help users understand commands, logs, systemd units, error output, and system state. For example, it could explain why a service failed to start, or clarify what a command-line flag means.

This fits Ubuntu’s audience well. Many Ubuntu desktop and server users already live in the terminal. Instead of starting with a flashy chat window, it makes sense to put AI into error analysis, command explanation, and operations assistance.

The safety boundary must be clear. Logs may contain tokens, internal hosts, usernames, file paths, key fragments, or business information. Even with local inference by default, tools should encourage redaction. If a user chooses a cloud backend, the UI must make clear what will be sent.

Settings Agent: natural-language system settings

Another direction is a Settings Agent that lets users query or change system settings in natural language.

This sounds simple but is easy to get wrong. A mature Settings Agent should not scrape the screen, guess buttons, and simulate clicks. It should use controlled internal APIs: what it can read, what it can change, when confirmation is required, and how failures are rolled back.

That makes it more likely to be a post-26.10 direction than a complete immediate feature. If done well, it could lower the barrier for normal users to configure desktop Linux. If done too aggressively, it becomes a new security risk.

Why not a universal AI kill switch?

Many users worry that once vendors add AI to an operating system, AI appears everywhere and becomes hard to disable. So the natural question is whether Ubuntu should provide a global AI kill switch.

Canonical’s position is that if AI features are opt-in, layered, and independently installable and configurable, a global kill switch is not the first priority. In other words, the design should avoid the pattern of “enabled by default, deeply embedded, then users have to disable it.”

Whether that is enough depends on implementation. If AI tools are not enabled by default, do not connect to remote services by default, do not collect data automatically, and each feature has clear controls, users should not need to hunt through hidden settings to turn AI off.

What it means for developers and enterprises

For developers, AI CLI tools can reduce the time spent reading documentation, parsing logs, and diagnosing system problems. They do not replace engineering judgment; they automate a lot of “help me understand this output” work.

For enterprises, local inference and pluggable backends matter more. Many companies cannot send source code, logs, customer data, or infrastructure details to public model services. If Ubuntu can connect system-level AI with local models, private inference services, and enterprise permissions, it may offer useful assistance in compliant environments.

This is also an opening for Linux desktops and workstations. Windows and macOS can more easily fold AI into vendor ecosystems. Ubuntu’s advantage is openness, auditability, replaceability, and self-hosting. If Canonical preserves those principles, AI could strengthen the professional Linux experience.

Do not overread it

It is too early to say that Ubuntu will preinstall a specific small model, that Ubuntu 26.04 will include an AI audit mode, or that there will be a fixed ubuntu-ai command. The clearer public information is about direction, not final product shape.

The safer reading is this: Canonical is preparing a system-level AI tooling framework for Ubuntu, starting with command-line help, settings assistance, local inference, and backend choice. The default posture is user choice, not vendor choice.

Summary

The important part of Ubuntu’s AI roadmap is not that Ubuntu is “joining the AI wave”. It is the attempt to define a more restrained model for AI in open source operating systems: intelligence can become infrastructure, but privacy, control, and user choice must come first.

If the experimental features in 26.10 live up to those principles, Ubuntu may take a different path from consumer operating systems: AI not as an unavoidable system ad slot, but as a selectable, replaceable, and auditable productivity layer.

References:

Choosing a Linux Desktop Distribution in 2026: Ubuntu, Deepin/UOS, Linux Mint, and Fedora Compared

Thu, 07 May 2026 21:17:11 +0800

When choosing a Linux desktop distribution in 2026, the key is not which one is the most “pure” or the most “advanced,” but which one you can comfortably use every day.

Desktop Linux is different from server Linux. Servers focus more on lifecycle, package stability, and operations standards. Desktops also depend on interface, drivers, app stores, input methods, office software, graphics cards, Bluetooth, audio, touchpads, external monitors, and small daily annoyances.

If you want less fuss, start with Ubuntu, Linux Mint, and Deepin/UOS. If you are a developer and are willing to use a newer software stack with a faster technology cadence, Fedora deserves attention.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Ubuntu 26.04 LTS	Beginners, developers, main desktop	Most documentation, complete ecosystem, strong hardware and software support	Default GNOME takes adjustment; not everyone likes the Snap strategy
Deepin / UOS	Chinese users, localization environments, users who value visual experience	Beautiful and easy to use, strong Chinese localization, good domestic software and enterprise compatibility	Community and commercial editions have different positioning; update strategy must be understood
Linux Mint	Windows-to-Linux migration, stability-first users	Familiar UI, extremely easy to use, stable Cinnamon desktop	Slower new-technology cadence; default stack is not aggressive
Fedora	Developers and Linux new-technology users	New kernel, new GNOME, fast adoption of new technologies	Frequent updates; less comfortable than LTS for conservative stability users

In one sentence:

Beginners and main desktop: Ubuntu 26.04 LTS.
Chinese and localization experience: Deepin / UOS.
Smooth Windows migration: Linux Mint.
Developers and new-technology exploration: Fedora.

Ubuntu 26.04 LTS: The All-Round Desktop

Ubuntu 26.04 LTS Resolute Raccoon was released in April 2026. As an LTS release, it is suitable as a long-term main desktop.

Ubuntu’s advantage is direct: it has the most documentation, the most tutorials, and the easiest answers to search for when something goes wrong. Whether you want VS Code, Docker, NVIDIA drivers, Steam, Chrome, Slack, JetBrains, CUDA, Python, or Node.js, Ubuntu is usually a primary target for vendors and the community.

Ubuntu 26.04 LTS is suitable for:

people seriously using Linux desktop for the first time;
users who want a long-term main system;
developers who need a stable Linux environment;
users who need lots of tutorials, drivers, and commercial software support;
users who want to connect desktop, server, and WSL ecosystems.

Its strengths:

long LTS lifecycle;
mature official images and documentation;
modern GNOME desktop, with good touchpad and multi-monitor experience;
complete driver, cloud, container, and development-tool ecosystem;
lowest search cost when problems appear.

The main note is that Ubuntu uses GNOME by default, which differs from the Windows desktop model. Beginners may need to adapt to the activities overview, Dock, workspaces, and app launcher. Ubuntu also continues to promote Snap, and some users dislike Snap’s launch speed, package-management model, and ecosystem strategy.

My take: if you do not know which desktop distribution to choose, Ubuntu 26.04 LTS remains the safest default answer. It is not the best in every single direction, but its overall score is the highest.

Deepin / UOS: Chinese Desktop Experience and Localization Compatibility

The strength of Deepin and UOS is that they better understand Chinese desktop users.

Deepin 25 was released in 2025 and continues to receive updates in 2026 through versions such as deepin 25.1. Official notes for deepin 25 emphasize DDE desktop improvements, UOS AI, the Solid immutable system, Linyaps application compatibility, Distrobox subsystem, and the Treeland window compositor preview.

These directions show that Deepin/UOS is not just making a pretty Linux skin. It is trying to solve long-running pain points for Chinese desktop users:

application installation and dependency conflicts;
domestic software compatibility;
desktop visual quality and ease of use;
rollback when system updates fail;
Chinese input, office work, and enterprise software ecosystem;
Windows application compatibility and transition.

Deepin / UOS is suitable for:

users who care more about Chinese UI, input methods, office work, and localization;
users who want an out-of-the-box and visually polished Linux desktop;
people working in localized hardware and software environments;
users who need enterprise office software, domestic software, domestic CPUs, or compatibility certification;
users who do not want to configure GNOME/KDE from scratch.

Deepin’s strengths:

unified and polished DDE interface;
better details for Chinese users;
app store and system settings closer to ordinary user habits;
Linyaps, Distrobox, and related approaches help reduce Linux application compatibility issues;
the commercial UOS edition has practical value in localization and enterprise scenarios.

The key caution is that Deepin community edition and UOS commercial edition do not have the same positioning. Deepin is better for personal experience and community users. UOS leans toward government and enterprise use, localization, commercial services, and certified environments. For production office environments, check hardware, software, and organizational requirements, not only the interface.

My take: if you are a Chinese user and especially care about appearance, input methods, domestic software, and office experience, Deepin/UOS is attractive. But if you are a heavy developer relying on the most standard upstream Linux ecosystem, Ubuntu or Fedora may feel smoother.

Linux Mint: Most Windows-Like and Most Comfortable

Linux Mint’s position has always been stable: make Linux easy for ordinary users.

As of 2026, the mainline Linux Mint series still revolves around 22.x and is based on Ubuntu 24.04 LTS. Linux Mint 22.3 Zena was released in early 2026. It is not a showcase for the newest technology, but a stable, familiar, low-learning-cost desktop system.

Linux Mint is especially suitable for Windows users moving to Linux, especially with the Cinnamon desktop:

bottom-left menu;
taskbar;
system tray;
minimize/maximize window logic;
settings panel;
file manager;
update manager.

These details make it feel like a traditional Windows desktop. For users who do not want to adapt to the GNOME workflow, Linux Mint is easier to start with than Ubuntu.

Linux Mint is suitable for:

users migrating from Windows to Linux;
installing Linux for parents, family, or non-technical users;
users who want a stable desktop without chasing new technologies;
browser, office, video, file management, and light development use;
people who dislike GNOME and do not want to tune KDE.

Its strengths:

intuitive Cinnamon desktop;
friendly update manager;
conservative and stable system;
friendlier to older computers;
large community knowledge base and relatively fewer surprises.

The key note is that Linux Mint does not prioritize new technologies. Wayland, PipeWire, the newest GNOME/KDE, the latest kernels, and the latest Mesa usually do not land first there. Its goal is “work reliably today,” not “use the newest Linux desktop technology immediately.”

My take: if you want to turn a Windows laptop into Linux without explaining too many concepts, Linux Mint is one of the safest choices. It does not have Ubuntu’s commercial ecosystem or Fedora’s freshness, but the daily experience is very solid.

Fedora: Developers and New Technologies First

Fedora is one of the front lines of desktop Linux technology.

As of May 2026, the current mainline Fedora release is Fedora Linux 44. Fedora Workstation has long been one of the distributions where GNOME, Wayland, PipeWire, Mesa, the kernel, systemd, and other technologies land early.

Fedora is suitable for:

Linux developers;
GNOME users;
users who want new kernels, new Mesa, new compilers, and new toolchains earlier;
users who want to experience modern Linux desktop stacks such as Wayland, PipeWire, and Flatpak;
users who are not afraid of upgrading every six months.

Fedora’s strengths:

fast new-technology adoption;
relatively clean default system;
GNOME experience close to upstream;
newer development toolchain;
tight integration with Flatpak and the open-source desktop ecosystem;
usually active support for modern hardware.

Its cautions are also clear:

shorter lifecycle and regular upgrades are required;
not suitable for people who do not want to maintain the system at all;
NVIDIA, proprietary codecs, and some commercial software require extra repositories;
if you want to “install it and leave it alone for five years,” Fedora is less suitable than LTS distributions.

My take: Fedora is excellent for developers, Linux enthusiasts, and new-technology users. It is not the most effortless desktop for ordinary users, but it lets you see earlier what the future Linux desktop may look like.

How to Choose

First Linux Install for Beginners

Choose Ubuntu 26.04 LTS or Linux Mint first.

Ubuntu’s strengths are documentation and ecosystem. Linux Mint’s strengths are Windows-like behavior and low learning cost. If you are willing to adapt to GNOME, choose Ubuntu. If you want it to feel as Windows-like as possible, choose Linux Mint.

Chinese Office and Localization Environments

Look at Deepin / UOS first.

If you need domestic office software, domestic browsers, government and enterprise systems, domestic CPUs, or organization-required compatibility environments, UOS has more practical value. Personal users who want a beautiful Chinese desktop can look at Deepin.

Developer Main Machine

Ubuntu 26.04 LTS and Fedora are both worth considering.

If you value stability, tutorials, and commercial software support, choose Ubuntu. If you want new kernels, new GNOME, new toolchains, and open-source technology frontiers, choose Fedora.

Old Computers or Home Computers

Linux Mint is more suitable.

Its traditional interface, relatively friendly resource use, and low maintenance pressure make it better for older computers, home browsing machines, and light office desktops than Fedora’s new-technology focus.

AI/GPU/Development Toolchains

Choose Ubuntu first.

NVIDIA drivers, CUDA, PyTorch, TensorFlow, Docker, VS Code, JetBrains, and similar tools still most commonly use Ubuntu in official guides and tutorials. Fedora can also work, but solving problems usually requires more Linux experience.

What to Check Before Choosing

Do not judge desktop Linux only by screenshots. The real experience depends on these details:

whether graphics drivers are stable, especially NVIDIA;
whether Wi-Fi, Bluetooth, fingerprint, and camera work correctly;
whether external monitors, scaling, and multi-monitor setup feel comfortable;
whether Chinese input methods work well;
whether common apps have official packages or Flatpak versions;
whether system updates are easy to understand;
whether solutions are easy to search for when problems occur;
whether you can accept the default desktop workflow.

Many people fail to switch to Linux not because the kernel is weak, but because input methods, scaling, WeChat, online banking, printers, and graphics drivers feel wrong in daily use.

My Recommendations

Scenario	Recommendation
Beginner main desktop	Ubuntu 26.04 LTS
Windows user migration	Linux Mint
Beautiful Chinese desktop	Deepin
Localization office / government and enterprise environment	UOS
Stable developer environment	Ubuntu 26.04 LTS
Linux new-technology experience	Fedora Linux 44
Older computer for light office work	Linux Mint
AI/GPU development	Ubuntu 26.04 LTS

Short Conclusion

Ubuntu 26.04 LTS is the safest all-round desktop choice in 2026, suitable for beginners, developers, and main machines.

Deepin/UOS is strong in Chinese experience, visual design, and localization compatibility, suitable for users who value local experience and government/enterprise environments.

Linux Mint is extremely easy to use and stable, especially for smooth Windows-to-Linux migration.

Fedora is strong in new technology and developer experience, suitable for users willing to follow the front edge of the Linux desktop.

The quality of a desktop system ultimately depends on whether you still want to use it every day after turning on the computer. A distribution you can live with comfortably matters more than one that looks best on paper.

Ubuntu 26.04 LTS: https://releases.ubuntu.com/26.04/
deepin 25 Release Note: https://www.deepin.org/en/deepin-25-release/
deepin 25.1.0 Release Note: https://www.deepin.org/en/deepin-25-1-release/
Linux Mint website: https://linuxmint.com/
Fedora Workstation: https://fedoraproject.org/workstation/
Fedora Release Notes: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/

Choosing a Linux Server Distribution in 2026: Debian, Rocky Linux, AlmaLinux, and Ubuntu Server Compared

Thu, 07 May 2026 21:03:12 +0800

When choosing a Linux server distribution in 2026, the key question is not “which one is best,” but “which one fits your operations model.”

If you need the most stable community distribution, Debian remains one of the best choices. If you need the RHEL-compatible ecosystem but do not want to buy RHEL directly, Rocky Linux and AlmaLinux are the most natural CentOS successors. If you care most about cloud images, documentation, fast deployment, and newer packages, Ubuntu Server is still the easiest path.

Below is a practical comparison from a server perspective.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Debian	Long-term stability, self-hosting, basic services	Stable, clean, strong community, deep free-software tradition	Default packages are conservative; enterprise commercial support is less explicit than RHEL/Ubuntu
Rocky Linux	RHEL-compatible production environments	Close to RHEL habits, suitable for enterprise CentOS migration	Conservative package cadence; desktop and new-tech experience are not the focus
AlmaLinux	RHEL-compatible production, cloud, enterprise replacement	RHEL compatible, active community, clear lifecycle	Still has some differences from RHEL; read release notes
Ubuntu Server	Cloud servers, containers, development deployment	Strong cloud support, rich docs, fast deployment, long LTS lifecycle	Snap, HWE kernels, and PPAs need team-wide rules

In one sentence:

Safest general-purpose choice: Debian.
Enterprise RHEL ecosystem replacement: Rocky Linux / AlmaLinux.
Cloud and development efficiency first: Ubuntu Server.

Debian: Rock-Solid Stability

As of May 2026, the current Debian stable release is Debian 13 trixie. Debian 12 bookworm has moved into oldstable and still receives security and LTS support, but new server deployments should generally start with Debian 13.

Debian’s characteristics have always been clear:

conservative default package selection;
clean system structure;
no strong commercial-vendor binding;
mature community governance;
well suited to long-running basic services.

Debian is comfortable if your servers mainly run:

Nginx / Apache;
PostgreSQL / MariaDB / Redis;
Docker / Podman;
WireGuard / Tailscale;
file services, backup services, monitoring services;
small self-hosted applications.

Debian’s advantage is not being “the newest,” but requiring less fuss. Many servers can run for years with normal security updates and minor maintenance.

Debian is suitable when:

you want the system to stay simple and not be too affected by vendor strategy;
you are familiar with apt, systemd, and Debian file layout;
you can accept software versions that are not the newest;
you care more about stability, security updates, and predictable upgrades.

Debian is less suitable when:

a vendor only certifies RHEL or Ubuntu;
you need enterprise commercial support with an SLA;
you depend on the newest kernel, GPU stack, or new hardware support;
your team has already built operations standards around the RHEL ecosystem.

My take: for personal servers, self-hosting, lightweight SaaS, and small-team infrastructure, Debian remains an excellent first choice.

Rocky Linux: A Steady CentOS Successor

Rocky Linux has a clear position: it serves users who need the RHEL-compatible ecosystem and continues the role that CentOS Linux played in enterprise production environments.

In 2026, both Rocky Linux 9 and Rocky Linux 10 are within their support periods. Rocky Linux 9 fits more conservative production environments, while Rocky Linux 10 is better for new projects, newer hardware, and a longer future runway.

Rocky Linux fits scenarios such as:

enterprise environments that previously ran CentOS 7 / CentOS 8;
RHEL-style directory structure, package names, and operations habits;
reliance on dnf, RPM, SELinux, and firewalld;
software vendors that explicitly support RHEL-compatible distributions;
internal automation scripts written around Enterprise Linux.

Its advantage is low migration friction. Many teams have years of CentOS-based Ansible playbooks, monitoring rules, audit scripts, and security baselines. Moving to Rocky Linux is mentally much easier than moving to Debian or Ubuntu.

Things to note about Rocky Linux:

packages are conservative by design; this is a feature of Enterprise Linux, not a flaw;
very new user-space components may require EPEL, third-party repositories, or containers;
RHEL compatibility does not mean every commercial software vendor automatically offers formal support, so check certification lists;
Rocky Linux 10 has new hardware baselines and ecosystem requirements, so validate before production.

My take: if your server environment is already CentOS / RHEL based, Rocky Linux is a very natural replacement, especially for stable production environments and internal enterprise services.

AlmaLinux: A More Proactive RHEL-Compatible Route

AlmaLinux is another important CentOS successor. It is also enterprise-grade, long-term supported, and RHEL compatible.

It shares many traits with Rocky Linux:

both target the RHEL-compatible ecosystem;
both fit server production environments;
both have long-term 8, 9, and 10 release lines;
both are suitable for CentOS migration;
both can use a large set of Enterprise Linux ecosystem tools.

The difference is that AlmaLinux is more proactive in documenting and handling upstream differences while remaining RHEL compatible. For example, AlmaLinux 10 provides an x86-64-v2 architecture option for older hardware and clearly documents differences from RHEL in release notes.

This is useful for some users: they want to stay in the RHEL ecosystem but also want a community distribution with more flexibility around hardware support, package builds, and EPEL compatibility.

AlmaLinux is suitable when:

you need RHEL compatibility but do not want to be fully constrained by RHEL release strategy;
you value community governance and transparent release notes;
you need a stable base system for cloud platforms, container images, and enterprise workloads;
you want a smooth migration from CentOS or older Enterprise Linux.

The key caution: AlmaLinux is not “identical to RHEL with your eyes closed.” For strict compliance, vendor certification, database certification, or hardware certification scenarios, check whether the software vendor explicitly supports AlmaLinux.

My take: both Rocky Linux and AlmaLinux can replace CentOS. If you prefer a more conservative and traditional CentOS-style story, look at Rocky. If you value community transparency and a more flexible compatibility route, look at AlmaLinux.

Ubuntu Server: Best Cloud Support and Deployment Efficiency

Ubuntu Server’s advantage is practical: cloud platforms, documentation, community tutorials, images, automation tools, and developer ecosystem are all strong.

For new server deployments in 2026, the main choice is still Ubuntu 24.04 LTS. Ubuntu LTS usually has 5 years of standard support and can be extended through ESM. For cloud servers, container hosts, development environments, and CI/CD nodes, Ubuntu Server is often the fastest to get working.

Ubuntu Server fits:

AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and other cloud servers;
Docker, Kubernetes, GitLab Runner, CI/CD;
AI / GPU / CUDA development environments;
teams that need abundant tutorials and community recipes;
environments where development and production should stay similar.

Ubuntu’s strengths:

high-quality cloud images;
lots of official and third-party documentation;
often more active new hardware support;
clear LTS cadence;
convenient developer toolchain updates;
many commercial software vendors provide Ubuntu installation instructions first.

Things to watch:

not every team likes Snap on servers, so decide your policy in advance;
PPAs are convenient, but overusing them in production increases maintenance risk;
choose clearly between HWE kernel, cloud kernel, and standard kernel;
for minimal-stability purists, Ubuntu’s default system feels busier than Debian.

My take: if you mainly run cloud servers, containers, development deployment, or AI toolchains, Ubuntu Server is usually the most efficient choice. It is not the most “pure” distribution, but it reduces lookup time and friction for many tasks.

How to Choose Among the Four

Personal VPS / Self-Hosting

Debian or Ubuntu Server first.

If you want stability, low maintenance, and less fuss, choose Debian. If you often follow tutorials to deploy new projects or need a newer software stack, choose Ubuntu Server.

Enterprise Production

Rocky Linux, AlmaLinux, or RHEL first.

If the company used CentOS before, migration to Rocky / Alma is the cheapest path. If commercial databases, hardware certification, security compliance, or vendor support are involved, check certification lists first.

Cloud Native and Container Hosts

Ubuntu Server, Debian, and Rocky / Alma can all work.

If the team values development efficiency, choose Ubuntu Server. If you want minimal stability, choose Debian. If the enterprise standard is RHEL-based, choose Rocky / Alma.

AI / GPU Servers

Look at Ubuntu Server first, then Rocky / Alma.

The reason is simple: NVIDIA, CUDA, PyTorch, TensorFlow, driver installation tutorials, and community experience are usually richest on Ubuntu. Enterprise GPU clusters built around the RHEL ecosystem can choose Rocky / Alma, but drivers, CUDA, container runtime, and monitoring tools should be validated in advance.

Traditional Business Systems

Rocky Linux / AlmaLinux first.

Traditional Java, databases, middleware, commercial software, auditing, and operations standards often lean toward the RHEL ecosystem. In that case, Rocky / Alma fits existing systems more easily than Debian / Ubuntu.

What to Check Before Choosing

Do not choose only by distribution name. For server selection, judge by these questions:

Lifecycle: until which year is this version maintained?
Upgrade path: is major-version upgrade mature? Is smooth migration supported?
Software sources: do you rely on third-party repositories? Who maintains them?
Security updates: are security advisories, patch cadence, and CVE handling clear?
Hardware support: have CPU, NIC, RAID, GPU, and storage controllers been validated?
Team experience: is the team more familiar with apt or dnf? Debian-style or RHEL-style systems?
Vendor certification: does the business software explicitly support this distribution?
Automation assets: can existing Ansible, Terraform, and image-building scripts be reused?

The real cost is often not the installation ISO. It is upgrades, audits, troubleshooting, and handover over the next five years.

My Default Recommendations

If I had to give a default 2026 server selection guide:

Scenario	Recommendation
Personal VPS, self-hosting	Debian 13
Cloud server, fast deployment	Ubuntu Server 24.04 LTS
CentOS migration	Rocky Linux 9 / AlmaLinux 9
New enterprise project	Rocky Linux 10 / AlmaLinux 10, after ecosystem validation
AI / GPU development	Ubuntu Server 24.04 LTS
Strict-compliance commercial production	RHEL, or Rocky / Alma after vendor support is confirmed

Short Conclusion

Debian’s keywords are stability, simplicity, community, and free-software tradition. It is suitable for long-running base servers.

Rocky Linux and AlmaLinux are about RHEL compatibility, enterprise production, and CentOS replacement. They fit teams that already have Enterprise Linux operations systems.

Ubuntu Server is about cloud, documentation, development efficiency, and ecosystem completeness. It fits fast deployment, containers, AI/GPU, and cloud servers.

There is no forever-correct distribution. There is only the distribution that best matches your team, business, hardware, and lifecycle. The best server choice is usually not the hottest one, but the one you will still be willing to maintain five years later.

Debian Releases: https://www.debian.org/releases/
Ubuntu Releases: https://releases.ubuntu.com/
Rocky Linux Release and Version Guide: https://wiki.rockylinux.org/rocky/version/
AlmaLinux Release Notes: https://wiki.almalinux.org/release-notes/

How to Control fdupes Deletion Order: Keep Duplicate Files by Directory Priority

Wed, 06 May 2026 09:23:09 +0800

When using fdupes to delete duplicate files across three directories, such as a, b, and c, and you want to keep a first, then b, and delete duplicates from c first, the key is not a complex rule. It is the order of directory arguments.

In non-interactive delete mode, fdupes keeps the first file it sees in each duplicate group and deletes later duplicates. Therefore, directory arguments should be arranged from highest retention priority to lowest.

In other words, to achieve “delete from c first, then b, and keep a as much as possible”, write the command like this:

`1`	`fdupes -rdN a b c`

The scan order is a -> b -> c. When the same file exists in all three directories, the file in a is found first and kept, while duplicates in b and c are deleted. If only b and c contain duplicates, b is kept and c is deleted.

Parameter Meaning

Common parameters are:

-r: recursively scan subdirectories.
-d: delete duplicate files.
-N: when used with -d, skip interactive confirmation, keep the first file in each duplicate group, and delete the rest.

Therefore, the basic format for automatic duplicate deletion is:

`1`	`fdupes -rdN 目录A 目录B 目录C`

The earlier a directory appears, the higher its retention priority. The later it appears, the more likely its duplicate files are to be deleted.

Preview Before Deleting

Using -dN deletes files directly, so it is better to preview duplicate groups first:

`1`	`fdupes -r a b c`

The output is grouped by duplicate files. In each group, the file shown earlier is the one more likely to be kept in non-interactive deletion mode.

You can also view summary information:

`1`	`fdupes -rm a b c`

If the data is important, save the result and inspect it manually:

`1`	`fdupes -r a b c > duplicates.txt`

After confirming that the order within each duplicate group matches your expectations, run:

`1`	`fdupes -rdN a b c`

How Subdirectories Are Handled

As long as -r is enabled, fdupes recursively scans all files under the directories you pass in. Retention priority is still determined by the order in which paths appear in the command.

For example:

`1`	`fdupes -rdN dir_a dir_b dir_c`

This means:

dir_a has the highest priority.
dir_b comes next.
dir_c has the lowest priority.

If dir_a/sub1/file.txt and dir_c/sub1/file.txt have identical content, the file under dir_a is kept. If dir_a/x/y/file.txt and dir_c/file.txt have identical content, the file under dir_a is still kept first. fdupes compares file content; filenames and directory depth do not need to match.

Precisely Controlling Subdirectory Priority

If you only pass parent directories, the scan order inside subdirectories is determined by fdupes traversal behavior. This is enough in most cases. But if you want a specific subdirectory to have higher priority, write it explicitly before its parent directory.

For example, suppose you want to keep dir_a first, then keep dir_b/special, then process the rest of dir_b, and finally process dir_c:

`1`	`fdupes -rdN dir_a dir_b/special dir_b dir_c`

This makes dir_b/special scan before dir_b. When dir_b is scanned later, files under special have already been recorded, so that subdirectory effectively has higher priority than the rest of dir_b.

This pattern is useful when:

a is the most important baseline directory.
A subdirectory inside b is more important than the rest of b.
c is mainly a low-priority backup directory.

The path order can be extended further:

`1`	`fdupes -rdN a b/important b c/keep-first c`

The rule is still the same: the earlier it appears, the more likely it is to be kept.

Use a List for Many Directories

If there are many directories and subdirectories, manually writing a long command is error-prone. You can write paths into a text file such as folders.txt, ordered by priority:

/path/to/dir_a
/path/to/dir_b/sub_important
/path/to/dir_b
/path/to/dir_c/sub_1
/path/to/dir_c

Then pass them to fdupes with xargs:

`1`	`cat folders.txt \| xargs fdupes -rdN`

If paths may contain spaces, use null-separated input for better safety:

`1`	`tr '\n' '\0' < folders.txt \| xargs -0 fdupes -rdN`

Important Boundaries

First, fdupes compares file content, not filenames. Two files with completely different names can still be treated as duplicates if their content is identical.

Second, if directory a contains duplicates internally, fdupes -rdN a b c may also delete later duplicates inside a. This command means “keep the first file according to the overall scan order”, not “never delete anything under a”.

Third, by default, fdupes does not follow symbolic links. If you need to handle files behind symlinks, confirm whether -s is needed and whether that matches your data-safety expectations.

Fourth, fdupes only deletes duplicate files. It does not clean up empty directories. After deletion, if b and c contain empty folders, you can run:

`1`	`find b c -type d -empty -delete`

Safer Operating Habit

If the directories contain important data, do not start with -rdN. A safer workflow is:

Run fdupes -r a b c first to view duplicate groups.
Confirm that the first file in each group is the one you want to keep.
Then run fdupes -rdN a b c for automatic deletion.
After deletion, check whether empty directories need cleanup.

If you are very worried about accidentally deleting files under a, first clean a smaller range of low-priority directories, or export the results and filter them manually. The directory order in fdupes is useful, but it is not an access-control rule. Once a path is included in the scan, duplicate files inside it may participate in deletion decisions.

Summary

To delete duplicate files with fdupes by priority, put the directories you want to keep earlier and the directories you want to delete from later.

To keep a, then b, and delete from c first:

`1`	`fdupes -rdN a b c`

To give a subdirectory higher priority, write it before its parent directory:

`1`	`fdupes -rdN a b/important b c`

The key sentence is simple: fdupes -dN keeps duplicate files that appear first and deletes duplicates that appear later. Directory order is your retention priority.

What Is the Difference Between Snap, Flatpak, and apt?

Sat, 02 May 2026 11:22:26 +0800

When installing software on Ubuntu, you often see three names: apt, Snap, and Flatpak. All of them can install apps, but they solve different problems.

In short:

Tool	Main role	Best fit
`apt`	Traditional Ubuntu/Debian package manager	System components, command-line tools, distro-maintained software
Snap	App packaging format promoted by Canonical	Ubuntu desktop apps, server tools, auto-updated software
Flatpak	Cross-distribution format focused on desktop apps	Graphical apps, sandboxed apps, Flathub ecosystem

apt: Part of the System

apt is the traditional package manager for Debian and Ubuntu systems. It installs .deb packages from distribution repositories, with dependencies maintained by the distribution.

Typical usage:

`1`	`sudo apt install firefox`

apt has these traits:

It integrates most deeply with the system.
Dependencies are managed centrally by the distribution.
Software versions usually follow the distribution release cycle.
It is well suited for system libraries, drivers, command-line tools, and server components.

Its downside is also clear: versions may be older. Distributions prioritize stability, so they do not always ship the latest upstream release immediately.

Snap: App and Dependencies in One Package

Snap is a packaging format promoted by Canonical. It bundles an app with many of its runtime dependencies, reducing reliance on the exact system library versions.

Installation looks similar:

`1`	`sudo snap install firefox`

Snap’s advantages:

The same package can more easily run across Ubuntu versions.
Apps can update independently of system updates.
There is some default isolation and permission control.
It works well for desktop apps that need fast updates and some server tools.

Common complaints include slower startup, larger disk usage, less natural theme integration, and an update model that gives users less control than apt.

Flatpak: More Desktop-App Oriented

Flatpak is also a cross-distribution app packaging format, but it is more focused on Linux desktop apps. Many Flatpak apps come from Flathub.

Typical installation:

`1`	`flatpak install flathub org.mozilla.firefox`

Flatpak has these traits:

Strong cross-distribution support.
Focus on desktop app distribution.
Uses runtimes to share base dependencies.
Clearer sandbox and permission model.
A large software selection on Flathub.

Flatpak also uses extra space, especially when installing a runtime for the first time. Once multiple apps share a runtime, the overhead becomes less wasteful.

The Biggest Difference: Dependencies

apt is more like assembling software into the system. Apps depend on libraries already in the system, and multiple packages share the same dependencies.

Snap and Flatpak are more like shipping an app with its own runtime environment. The app carries part of what it needs, reducing problems caused by different system versions.

That creates a tradeoff:

Approach	Pros	Cons
`apt` shares system dependencies	Saves space, integrates well, centrally maintained	Versions are tied to the distribution
Snap/Flatpak carry runtime pieces	Cross-version, cross-distribution, easier updates	Larger packages, possible slower startup, weaker integration

Isolation and Permissions

Software installed with apt usually runs directly in the system environment. It integrates naturally, but has less isolation.

Snap and Flatpak both use sandbox ideas. Apps cannot freely access all system resources by default; they need permission interfaces for files, camera, network, desktop notifications, and other resources.

This does not make them absolutely safe, but it gives a clearer permission boundary. For desktop apps from mixed sources, that matters.

Updates Work Differently

apt usually follows system updates:

1
2

sudo apt update
sudo apt upgrade

Snap updates automatically. That is convenient, but also controversial: users do not have to manage versions, but they also get less control.

Flatpak can be updated manually:

`1`	`flatpak update`

So if you care about when updates happen, apt and Flatpak usually feel more controllable. If you want apps to stay current automatically, Snap is more hands-off.

Which One Should You Use

Choose by scenario:

System tools, drivers, and server components: prefer apt.
Ubuntu-recommended desktop apps: Snap is fine.
Newer desktop apps, especially cross-distribution apps: Flatpak is often a good choice.
If the same app exists in all three formats: compare stability, startup speed, theme integration, and update needs.

A conservative approach is: use apt for the system layer, then choose Snap or Flatpak for desktop apps as needed.

Summary

apt, Snap, and Flatpak do not fully replace one another. They are different distribution models.

apt is better for maintaining the system. Snap emphasizes bundled dependencies and automatic updates. Flatpak is better for cross-distribution desktop apps and sandboxed delivery.

For everyday use, there is no need to obsess over which is best. Use apt for system software. For desktop apps, follow your distribution’s recommendation and your own experience: stable operation, controlled updates, and clear permissions are what matter.

Reference:

https://www.reddit.com/r/Ubuntu/comments/9awvip/eli5_snap_and_flatpak_how_are_they_differ_from_apt/

Linux 7.0 and 7.1 NTFS Driver Changes Explained

Sat, 02 May 2026 10:46:20 +0800

After Linux 7.0, Linux 7.1 entered the next feature merge window. One notable change is a new NTFS kernel driver.

“New” does not mean Linux is supporting NTFS for the first time, nor does it mean ntfs3 is being replaced. More precisely, Linux 7.1 adds a new optional in-kernel NTFS read-write driver. It is based on the old in-kernel ntfs driver, modernized and extended with more complete write support.

Quick Take

Linux now has three main NTFS paths:

Option	Location	Read-write support	Best fit
`ntfs-3g`	User-space FUSE	Read-write	Stability first; long-time distro default
`ntfs3`	Kernel-space	Read-write	More direct kernel integration and performance
New `ntfs`	Kernel-space	Read-write	Optional implementation added in Linux 7.1

This is not a forced migration. It simply adds another option. Most users can keep following their distribution defaults for now.

How 7.0 and 7.1 Relate

Linux 7.0 only marks the move into the 7.x kernel series. It does not mean NTFS support was suddenly rewritten in 7.0. The NTFS-related change appears in the Linux 7.1 feature cycle.

NTFS remains important for Linux desktop users because dual-boot systems, external drives, USB drives, and Windows data disks often use it. The hard part is writes: if a file-system driver has a bug, user data can be affected directly. That is why NTFS driver changes are treated carefully.

`ntfs-3g`, `ntfs3`, and the New `ntfs`

ntfs-3g is a user-space FUSE driver. It has long handled NTFS read-write support on Linux. It may not always be the fastest option, but it is mature, compatible, and well documented.

ntfs3 is the in-kernel NTFS driver contributed by Paragon Software and already merged into Linux. It has a shorter path, integrates more directly with VFS, and can offer better performance. But file-system drivers require strong maintenance discipline, and ntfs3 has seen discussion around maintenance pace and code quality after merging.

The new Linux 7.1 ntfs driver is maintained by Namjae Jeon. It is not written from scratch; it modernizes the old kernel ntfs driver, adds write support, and coexists with ntfs3 as another optional implementation.

In short:

ntfs-3g: conservative, mature, user-space.
ntfs3: existing in-kernel mainline option.
New ntfs: new in-kernel option in 7.1, still worth watching.

Which One to Use

There is no need to switch immediately. A conservative order is:

Keep using the distribution default for important data, usually ntfs-3g or a tested ntfs3.
Try ntfs3 when performance matters.
Test the new ntfs driver on temporary, test, or recoverable data first.
Back up important NTFS partitions before writing.

To mount with ntfs3 manually:

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

For temporary read-only access:

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

To check which driver is being used:

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

Dual-Boot Notes

If an NTFS partition comes from a Windows system disk, make sure Windows is fully shut down before writing to it. Fast Startup and hibernation can leave the NTFS volume in an unfinished state, and Linux writes may then cause consistency problems.

Check these first:

Disable Windows Fast Startup.
Make sure the partition is not hibernated.
Confirm BitLocker or other encryption is not blocking access.
Safely eject external drives from Windows.

These rules apply whether you use ntfs-3g, ntfs3, or the new ntfs driver.

Why Multiple NTFS Drivers Exist

Multiple implementations for the same file system are not unusual in Linux. Old, new, vendor, and community implementations can coexist until maintenance status and real-world feedback make the preferred path clear.

NTFS is especially suited to a conservative approach:

User data risk is high.
Compatibility cases are complex.
Implementations differ in performance and stability tradeoffs.
Distributions need time to validate defaults.

So the new Linux 7.1 ntfs driver does not immediately obsolete ntfs-3g or ntfs3. It gives the kernel community another maintainable option.

Summary

The new Linux 7.1 ntfs driver is an optional in-kernel NTFS read-write implementation. It coexists with ntfs-3g and ntfs3; it does not directly replace either.

Regular users can keep using distribution defaults. Users who want to test performance or kernel file-system changes can watch ntfs3 and the new ntfs, but important data should be backed up before switching drivers.

sudo vs sudo-rs: What the Rust Version of sudo Changes

Fri, 01 May 2026 19:27:08 +0800

sudo is one of the most familiar commands for Linux users. It allows a normal user to temporarily run commands with higher privileges within an authorized scope, such as installing software, changing system configuration, or restarting services.

Recently, sudo-rs has attracted more attention because Ubuntu 25.10 starts using the Rust implementation sudo-rs by default to replace classic sudo. For ordinary users, the command on the surface is still sudo. The real change is underneath: the implementation being executed may already be the Rust version of sudo.

This raises two natural questions:

Is something wrong with classic sudo?
Will sudo-rs affect daily use and server configuration?

The short answer is: ordinary desktop users basically do not need to worry; if you maintain servers, have written complex sudoers rules, or rely on special sudo behavior, you should test carefully.

What Is sudo-rs?

sudo-rs is an implementation of sudo / su written in Rust. Its goal is not to create a completely different new command, but to reimplement the main features of classic sudo while using Rust’s memory-safety properties to reduce common security risks.

Classic sudo is mainly written in C. It has a long history and a very complete feature set. That maturity brings stability, but it also brings maintenance burden. Much of the code comes from very early Unix/Linux use cases, with many compatibility paths, extensions, and edge-case handlers added over time.

sudo-rs chooses to reimplement it for several reasons:

reduce memory-safety issues with Rust;
use a more modern code structure to lower maintenance difficulty;
remove some historical features and risky default behaviors;
attract new contributors familiar with Rust;
provide a more auditable foundation for future privilege-elevation tools.

However, sudo-rs is not a 100% compatible replacement for classic sudo. It is still under development. Some traditional features have not been implemented yet, and others may never be implemented.

What Ordinary Users Will Notice

For ordinary users, very little changes.

You still use it like this:

`1`	`sudo apt update`

Or:

`1`	`sudo systemctl restart nginx`

In Ubuntu 25.10, sudo points to sudo-rs. Users do not need to change commands to sudo-rs, and common sudo calls in scripts will not immediately fail because of a command-name change.

The most visible change is password input feedback. sudo-rs shows asterisks by default when you type the password. Classic sudo can also be configured to behave this way, but many distributions default to showing no characters.

Some error and warning messages may also use different wording. For example, password failures, permission problems, and incompatible configuration may show prompts that are not exactly the same as before. This has little impact on human users, but scripts that parse sudo’s error output should be checked.

What Administrators Should Watch

System administrators and advanced users are the ones who need to pay attention.

The classic sudo ecosystem is large, and many servers have complex sudoers configurations. These configurations may include command-argument matching, environment-variable control, logging, email notifications, PAM behavior, and host-group policies.

sudo-rs currently has some differences from classic sudo. For example, the original article notes that sudo-rs does not include classic sudo’s sendmail support. Some environments used sendmail to send notifications about sudo usage, and those setups will need another approach when migrating.

For authentication, sudo-rs uses PAM. This means behaviors such as resource limits and umask should be configured more through PAM, rather than relying entirely on the sudoers file. If you previously handled many details in sudoers, verify that those rules still work before switching.

Another important change is wildcard support in command argument positions. sudo-rs does not support wildcards in command argument positions, in order to avoid common sudoers configuration mistakes. This is good for security, but it may affect existing rules.

How Ubuntu Handles sudo and sudo-rs

Starting with Ubuntu 25.10, the system uses sudo-rs by default. Users continue typing sudo, while the Rust implementation runs underneath.

Classic sudo has not disappeared immediately. During Ubuntu’s transition, classic sudo is still kept as sudo-ws. If you truly need the traditional implementation, you can use sudo-ws, or switch the default sudo through the alternatives system.

The switching command looks like this:

`1`	`sudo update-alternatives --config sudo`

That said, ordinary users should not actively switch back to classic sudo. If you have not customized sudoers and do not rely on special behavior, following the distribution default is simpler.

If you want to test on older Ubuntu versions, sudo-rs has been available from the universe repository since Ubuntu 24.04. Other distributions may also provide packages, but command names and integration methods may differ.

Why sudo-rs Uses Rust

sudo is a high-privilege tool. If this kind of tool has a vulnerability, the consequences can be much more serious than with ordinary commands. Historically, sudo has had several privilege-escalation vulnerabilities.

Rust’s advantage is memory safety. Through ownership, borrow checking, and the type system, it reduces common problems such as dangling pointers, out-of-bounds access, and use-after-free. This does not guarantee that the program is absolutely safe, but it can reduce a class of vulnerabilities common in C/C++ projects.

For a tool like sudo, which sits in a security-sensitive position for a long time, rewriting it in a safer language has practical meaning. It is not just “Rust for Rust’s sake”; it is an attempt to reduce maintenance and audit cost.

Of course, language cannot solve every security problem. Permission-check logic, configuration parsing, PAM interaction, environment-variable handling, logging, and user experience still require careful design and long-term testing.

sudo-rs Is Not the Only Alternative

There have always been other alternatives in the sudo ecosystem.

One common example is doas. It comes from OpenBSD and is designed to be simpler, with a smaller configuration surface. Some users prefer it because it is not as complex as sudo.

There are also some Rust or systemd-related alternatives, such as RootAsRole and systemd’s run0. However, these tools do not have exactly the same goals or target scenarios.

For most Linux distributions, sudo is still the default choice. The significance of sudo-rs is that it tries to keep user habits unchanged while replacing the underlying implementation with a more modern codebase.

What to Check Before Migrating

If you are just a personal desktop user, follow the distribution default.

If you maintain servers or workstations, check the following:

Whether there are complex /etc/sudoers or /etc/sudoers.d/ rules.
Whether command-argument wildcards are used.
Whether sudo email notifications are relied on.
Whether scripts parse sudo’s error output.
Whether sudoers controls umask, resource limits, or environment variables.
Whether LDAP, PAM, SSSD, or other authentication integrations are used.
Whether automation/deployment scripts assume classic sudo behavior.

You can first verify on a test machine:

sudo -l

Then run key maintenance commands and confirm that permissions, environment variables, and logging behavior match expectations.

Should You Switch to sudo-rs Manually?

If your distribution has already switched by default, ordinary users can accept it directly. If you are using a server or production environment, do not manually replace sudo just for experimentation.

A safer process is:

install sudo-rs in a test environment;
verify existing sudoers configuration item by item;
check PAM, logging, auditing, and automation scripts;
confirm the rollback path;
migrate after the distribution provides stable integration.

This kind of tool sits on the privilege chain, so it is not enough to judge it by whether a few commands can run. The real test is boundary conditions and failure cases.

Summary

sudo-rs is a Rust implementation of classic sudo, aiming to support sudo’s core features with a more modern and safer codebase. Ubuntu 25.10 enabling it by default shows that major distributions are starting to push this direction seriously.

For ordinary users, the change is small. You still type sudo; only the underlying implementation may have become sudo-rs. At most, you may notice password asterisks or slightly different error messages.

For system administrators, compatibility is the key issue. If the system has complex sudoers rules, sendmail notifications, PAM integration, argument wildcards, or scripts that depend on sudo output, test before upgrading.

Rewriting in Rust is not a magic cure, but for a security-sensitive tool like sudo, reducing memory-safety risk and maintenance complexity is a direction worth taking seriously.

References:

X11 vs Wayland: Differences, Pros, Cons, and When to Choose Each

Fri, 01 May 2026 19:23:01 +0800

On the Linux desktop, you often encounter two names: X11 and Wayland. Both are related to graphical display, but they come from different eras and follow very different architectural ideas and user-experience tradeoffs.

In simple terms, X11 is the older display protocol and ecosystem. It is feature-complete and highly compatible, but its architecture is complex and its security model is outdated. Wayland is the newer display protocol. Its goal is to reduce intermediate layers, improve security, and make the desktop feel smoother, but some software and workflows still need adaptation.

For everyday use, the short version is:

on a new Linux desktop installation, try Wayland first;
if you need old software, complex remote desktop workflows, special input devices, or certain professional tools, X11 may still be more reliable;
for gaming and ordinary office use, Wayland is increasingly usable;
if you hit compatibility problems, you can switch back to X11. This does not need to become a belief system.

What Is X11?

X11, also called the X Window System or Xorg, is the graphical system used by Linux and Unix desktops for many years. Its design came from an early network-computing world: a program could run on one machine while its window was displayed on another.

A typical X11 structure looks like this:

applications draw window content;
the X Server manages display, input, and basic window operations;
the window manager handles borders, movement, and stacking;
the compositor handles shadows, transparency, animation, tear control, and similar effects.

This architecture is flexible and gave X11 a large ecosystem of tools and extensions. But over time, its problems became clear: many components, long rendering paths, loose permission boundaries, and many modern desktop requirements maintained through extensions and patches.

What Is Wayland?

Wayland is not a complete traditional display server in the same sense. It is a more modern display protocol. Under Wayland, the compositor usually also acts as the display server. GNOME’s Mutter, KDE’s KWin, and wlroots-based compositors can all serve as Wayland compositors.

A typical Wayland structure is shorter:

applications render their own window content;
the compositor receives buffers submitted by applications;
the compositor centrally manages windows, input, display outputs, and composition;
the final frame is handed directly to the kernel graphics stack for display.

This design reduces the detours between the X Server, window manager, and compositor in traditional X11. It also makes permission control clearer: applications cannot freely read other window contents by default, nor can they casually listen to global keyboard input.

Architectural Differences

The core difference is responsibility.

In X11, the X Server sits at the center, and many applications can interact with it. Window managers, compositors, input methods, screenshot tools, and remote-control tools can all get a lot of information through X11’s open interfaces. This brings strong compatibility, but also security issues.

In Wayland, the compositor is the center. Applications cannot directly access other windows’ content, nor can they listen to all keyboard input by default. Capabilities such as screenshots, recording, screen sharing, global shortcuts, and remote control need to go through desktop portals, PipeWire, or controlled interfaces provided by the compositor.

You can think of it this way:

Item	X11	Wayland
Design era	Older	Newer
Central component	X Server	Compositor
Compositor role	Optional or additional component	Core component
Application isolation	Weaker	Stronger
Remote display	Stronger native concept	Depends on newer toolchains
Compatibility	Very strong	Still being completed
Modern desktop experience	Depends on extensions and patches	Designed closer to modern needs

Strengths of X11

X11’s biggest strength is maturity. It has been running for many years, and almost all Linux graphical applications work under X11. Older tools, professional software, special input methods, remote-control solutions, and automation scripts often support X11 first.

Another strength of X11 is operability. Many tools can directly read windows, simulate input, capture the screen, move windows, and listen to key presses. This is convenient for automation, remote assistance, window-management scripts, and special workflows.

If your needs include:

using old GUI software;
relying on xrandr, xinput, xdotool, or wmctrl;
using traditional remote desktop or window forwarding;
needing special screenshot, recording, or keyboard/mouse macro tools;
running an application that is still unstable under Wayland;

then X11 remains a very practical choice.

Weaknesses of X11

X11’s weaknesses mainly come from historical baggage.

First is the old security model. In a traditional X11 session, a normal application can often listen to other windows’ input, capture screen contents, and simulate keyboard and mouse operations. From a modern desktop-security perspective, this is hard to accept.

Second is the complex rendering path. X11 went through many extensions: Composite, GLX, DRI, RandR, Present, and more. These extensions allowed it to keep supporting modern desktops, but also made the graphics stack complex. In high-refresh-rate, multi-monitor, mixed-scaling, mixed-DPI, and low-latency input scenarios, X11 is more likely to show edge-case problems.

Also, X11 maintenance has gradually shifted toward compatibility. Mainstream desktop environments still support X11, but new features and optimizations usually land on Wayland first.

Strengths of Wayland

Wayland’s advantages are mainly about the modern desktop experience.

Its rendering path is more direct. Applications render buffers, and the compositor handles unified composition and display, reducing the detours in the traditional X11 architecture. For animation, window movement, high refresh rates, multi-monitor setups, touchpad gestures, and fractional scaling, Wayland is easier to implement cleanly.

Security is another major advantage of Wayland. Applications cannot freely capture other windows by default, nor can they unconditionally listen to global keyboard input. Screenshots, recording, and screen sharing require user authorization and are usually handled through desktop portals and PipeWire.

Wayland is also friendlier to modern hardware. Touchpad gestures, HiDPI, variable refresh rate, and different scaling factors per monitor are usually more natural under Wayland. GNOME and KDE have also put many desktop-experience improvements into their Wayland sessions in recent years.

Weaknesses of Wayland

Wayland’s issue is not that it “cannot be used”; it is that the ecosystem is still migrating.

Some tools historically relied on X11’s open capabilities, such as global key listening, window enumeration, automatic clicking, screen capture, and window movement. These cannot be copied directly to Wayland. They must be implemented through portals, compositor protocols, or desktop-environment APIs. As a result, some older tools stop working or only work under specific desktop environments.

Remote desktop is a typical example. X11 has a historical design around network transparency. Modern experience is not always perfect, but many tools have matured around it. Under Wayland, remote desktop requires PipeWire, RDP, VNC, desktop portals, or compositor support, and the experience depends on GNOME, KDE, Sway, or other environments.

Input methods were also once a pain point. Fcitx5 and IBus have improved significantly on mainstream Wayland desktops, but some Electron applications, old programs, or special combinations may still have issues with candidate-window position, focus, or shortcuts.

NVIDIA was also a long-standing obstacle for Wayland. In recent years, NVIDIA driver and desktop-environment support has improved a lot, but if you use an old GPU, old driver, or unusual multi-monitor setup, X11 may still be more stable.

What Xwayland Does

Many people think that after switching to Wayland, X11 applications cannot be used at all. That is not the case.

Wayland desktops usually use Xwayland to run old X11 applications. The application thinks it is running on X11, while its window content is handed to the Wayland compositor for display.

This makes migration much smoother:

native Wayland applications use Wayland;
old X11 applications use Xwayland;
users can run both kinds of programs in the same desktop session.

However, Xwayland is not magic. If a tool depends on global input listening, window-management scripts, or low-level X11 extensions, it may still be restricted.

Which One Performs Better?

You cannot simply say Wayland is always faster than X11, or that X11 is always more stable. Real performance depends on the desktop environment, graphics driver, application type, and use case.

In general:

for ordinary desktop animation and high-refresh-rate display, Wayland often feels smoother;
for mixed DPI and multi-monitor scaling, Wayland has an advantage;
for old applications and special tools, X11 is less likely to surprise you;
for gaming, Wayland is already quite mature through Xwayland and native support, but some games or capture tools may still prefer X11;
for professional graphics, remote control, and automation scripts, test the specific tools.

For most ordinary users, performance is not the main difference. The real experience is decided by compatibility, security boundaries, monitor configuration, and input-device support.

This is one of the most commonly misunderstood parts of Wayland.

Under X11, screenshot and recording tools can usually capture the screen directly. That is convenient, but it also means malicious programs can more easily spy on the screen.

Under Wayland, applications cannot capture the screen freely. Screenshots, recording, streaming, and meeting screen sharing usually need to go through desktop portals and PipeWire, with user authorization. This is safer, but it requires applications to support the newer interfaces.

So if a meeting app, recording tool, or screenshot tool does not work well under Wayland, it does not necessarily mean Wayland “does not support it”. More likely, the application has not adapted well to portals or PipeWire.

Which One Should Gamers Use?

Linux gaming is no longer X11-only. Steam, Proton, Mesa, KDE, GNOME, Gamescope, and Xwayland have made Wayland gaming much better.

If you use an AMD or Intel GPU, Wayland can usually serve as a daily gaming environment. If you use NVIDIA, newer drivers are also increasingly usable, but it is best to keep the driver and desktop environment up to date.

Gamers can choose like this:

ordinary Steam / Proton games: try Wayland first;
if recording, streaming, overlays, or input latency have issues: compare with X11;
if you use Gamescope: the Wayland ecosystem fits better;
if you use an old GPU or old driver: X11 may be easier.

Remote Desktop and Automation

If your workflow depends on remote desktop, window automation, or global keyboard/mouse control, be more cautious.

X11 has many tools and direct behavior in these scenarios. For example, controlling windows with scripts, simulating clicks, and capturing a specific window are usually easier under X11.

Wayland’s security design does not allow ordinary applications to control other windows freely. This means automation tools need to use interfaces provided by the desktop environment, or use dedicated remote-desktop implementations. GNOME and KDE are filling in these capabilities, but consistency across desktops is still not as good as X11.

If you are an ordinary desktop user, Wayland is fine. If you heavily depend on remote control, automated testing, or window-management scripts, X11 may still fit better.

How to Check Which One You Are Using

You can check the current session type with an environment variable:

`1`	`echo $XDG_SESSION_TYPE`

If the output is:

wayland

you are in a Wayland session.

If the output is:

x11

you are in an X11 session.

On GNOME, KDE, and similar desktops, you can usually switch between X11 and Wayland from the gear menu or session selector on the login screen.

Selection Advice

You can decide this way:

Scenario	Recommendation
New computer, mainstream distribution, ordinary office work	Prefer Wayland
Latest GNOME / KDE versions	Prefer Wayland
Multi-monitor, HiDPI, high refresh rate	Prefer Wayland
Old software, old GPU, old driver	Prefer X11
Remote desktop, window scripts, automated testing	Prefer X11 or test Wayland item by item
Gaming	Try Wayland first, switch to X11 if there are issues
Meeting screen sharing, recording	Depends on PipeWire / portal support in the software
Security-sensitive, multi-user desktop	Prefer Wayland

Wayland is the future direction, but X11 is not disappearing immediately. The two will continue to coexist for some time.

Summary

X11’s strengths are maturity, compatibility, and a large tool ecosystem. It suits old software, remote desktop, window automation, and special workflows. Its weaknesses are weak security boundaries, complex architecture, and a less clean fit for modern multi-monitor, high-refresh-rate, and mixed-scaling setups.

Wayland’s strengths are a more modern architecture, better security, a more direct display path, and better support for HiDPI, touchpad gestures, multi-monitor use, and modern desktop experience. Its weaknesses are adaptation costs for some old tools, remote control, screenshots/recording, and input-method scenarios.

Ordinary users can treat Wayland as the default choice. If a particular application or device behaves incorrectly, switch back to X11 and compare. For the Linux desktop, this is not about taking sides. It is about choosing the option that best fits your hardware, software, and workflow.

References:

Linux Kernel 7.0 Feature Update Overview

Fri, 01 May 2026 14:46:07 +0800

Linux kernel version numbers have never followed semantic versioning. A major version bump is more about the project’s rolling maintenance rhythm. In the release message, Linus Torvalds also described 7.0 as a normal release: the final week mostly contained small fixes across networking, architecture code, tools, selftests, and drivers.

What is really worth watching is the set of incremental changes itself. Linux 7.0 covers file systems, memory management, hardware support, security isolation, Rust support, and driver cleanup.

File Systems: XFS, EXT4, and NTFS3 All Changed

File systems are one of the most visible update areas in Linux 7.0.

XFS introduces self-healing-related capabilities. Together with a new generic file-system error reporting mechanism, file systems can report metadata corruption and I/O errors to user space in a more unified way. With suitable system service support, XFS can automatically handle some repair flows while the file system remains mounted. This does not mean every disk corruption problem can be fixed painlessly, but for servers and long-running systems, the detection and repair path is more complete.

EXT4 continues to improve concurrent direct I/O write performance. If a machine often runs backups, builds, downloads, databases, or log tasks that write to disk at the same time, these optimizations should make concurrent write paths steadier. It is not the kind of change every desktop user will immediately notice, but it matters for heavy I/O scenarios.

NTFS3 also receives a larger driver update, including delayed allocation, iomap-based file operations, and better readahead for large directory scans. If you often access Windows partitions or external NTFS disks from Linux, these updates are worth noting.

In addition, exFAT improves multi-cluster sequential reads, which can make sequential reading faster on some small-cluster devices.

Memory and Swap: Better Behavior Under Memory Pressure

Linux 7.0 continues the cleanup work around the swap subsystem from recent releases. One focus is improving the path for reading pages back from swap, especially when multiple processes share the same swapped-out pages. Throughput should be better in those cases.

For desktop users, this may not feel like the system suddenly becoming faster. But on memory-constrained systems, dense container hosts, Redis-like services with persistence enabled, or zram setups backed by disk, these changes can reduce jitter under memory pressure.

zram paths also receive optimizations. Previously, in some cases, the kernel needed to decompress zram pages before writing them to a backing device. The new path can write compressed data directly, reducing unnecessary processing.

CPU and Performance: Intel TSX auto, Faster Threads and File Operations

Linux 7.0 adjusts the default policy for Intel TSX. Because of past security issues, TSX was disabled by default on many processors. The kernel now uses a more precise auto policy: affected CPUs continue to keep it disabled, while unaffected or suitable CPUs can enable it automatically.

This can help some multithreaded workloads, especially applications that rely on transactional synchronization extensions. It is not a universal acceleration switch; the actual benefit still depends on the CPU model and whether the application uses the feature.

Linux 7.0 also includes optimizations for PID allocation, thread creation and destruction, and file open/close paths. These optimizations usually do not become headline features on their own, but they accumulate into small gains in system responsiveness and high-concurrency services.

Hardware Support: New Platform Enablement and Existing Device Improvements

Linux 7.0 continues a large amount of hardware enablement work. These updates usually fall into two groups: preparation for platforms that are not yet widely available, and improvements for devices already in users’ hands.

For new platforms, Linux 7.0 includes more preparation for Intel Nova Lake, Intel Crescent Island, new AMD graphics IP, and AMD Zen 6. These changes may not matter to ordinary users right away, but they determine whether new hardware can receive mainline kernel support more quickly after release.

On ARM64 and single-board computers, H.264/H.265 hardware video decoding for Rockchip RK3588/RK3576 enters the mainline support scope. This means devices such as Orange Pi 5 and Radxa ROCK 5 no longer need to rely entirely on vendor BSP kernels for hardware decoding.

There are also many detailed updates for laptops and peripherals:

ASUS WMI improves backlight, keyboard lighting, and fan hotkey support for ROG and TUF models.
HP WMI adds manual fan control for some Victus models and fixes audio indicator lights.
Lenovo WMI exposes more HWMON monitoring information for Legion devices.
The Intel Xe graphics driver exposes more temperature sensors.
Intel Arc B-series discrete GPUs can enter deeper PCIe power-saving states.
Rock Band 4 Bluetooth guitars and the Logitech K980 Bluetooth keyboard get better kernel support.

Each of these changes is small on its own, but for laptop, gaming device, development board, and peripheral users, more complete mainline support makes future distribution maintenance easier.

Security and Isolation: io_uring Can Use BPF Filtering

Linux 7.0 adds BPF filtering support to io_uring. This matters for containers, sandboxes, and environments with high security requirements.

In the past, some administrators disabled io_uring entirely to reduce attack surface. With BPF filtering, they can now restrict allowed operations more precisely instead of choosing only between fully enabled and fully disabled.

This does not make io_uring risks disappear automatically, but it gives system administrators and runtime frameworks a more controllable isolation tool.

Rust Support Is No Longer Just an Experimental Label

In Linux 7.0, the status of Rust for Linux becomes more stable. This does not mean the kernel will be rewritten in Rust at large scale, nor does it mean C is being replaced.

More precisely, the infrastructure for Rust in the kernel has entered a more formal stage. Future drivers, subsystems, or some security-sensitive code can choose Rust where it fits. This is a gradual path: stabilize the interfaces, build system, documentation, and maintenance process first, then let actual code grow over time.

Removing Old Functionality: laptop_mode Is Gone

Linux 7.0 removes laptop_mode. This was a long-standing power-saving feature mainly designed for the hard-disk laptop era, reducing disk wakeups to save power.

Modern laptops are mostly SSD-based, and the kernel’s memory reclaim, block device, and file-system paths have changed a lot. Keeping this old mechanism increases maintenance cost, and its test coverage was not ideal. Removing it reduces the impact of old code on modern paths.

Linux 7.0 adds several new HID keycodes for contextual AI interaction, such as acting on selected content, inserting context-generated content, and starting contextual queries.

This is not AI functionality built into the kernel. It is more like reserving input event definitions for future laptop keyboards and peripherals, so desktop environments, applications, or vendor tools can recognize those keys. What they actually do still depends on distribution, desktop environment, and application-level integration.

Should You Upgrade Immediately?

If you use a rolling distribution, Linux 7.0 will likely arrive naturally through system updates. If you use a newer distribution such as Ubuntu 26.04 LTS, 7.0 may also appear as the default or primary kernel version.

But if your machine is a production server, NAS, virtualization host, or depends on closed-source drivers and proprietary kernel modules, do not upgrade manually just because the version number became 7.0. A safer approach is to:

wait for the distribution to provide official kernel packages;
check compatibility for graphics cards, network cards, ZFS, VirtualBox, VMware, and DKMS modules;
test first on a test machine or snapshot environment;
watch the 7.0.x point releases.

As of the kernel.org v7.x directory, 7.0.1, 7.0.2, and 7.0.3 have already been released. If you plan to build or test manually, prefer the latest stable 7.0.x release instead of focusing only on the initial 7.0 tarball.

Summary

Linux Kernel 7.0 is not a release that rewrites everything just because the major version changed. It is closer to a broad regular kernel update: file systems are more reliable, swap and I/O paths continue to improve, new hardware support moves forward, and Rust, io_uring isolation, and HID input definitions fill in infrastructure needed for long-term evolution.

For ordinary desktop users, the most practical changes may come from hardware support, graphics drivers, power saving, and file-system repair. For servers and developers, XFS error reporting, self-healing, io_uring BPF filtering, swap optimization, and new platform support are more worth watching.

References:

Ubuntu 26.04 LTS GPU and Hardware Updates: CUDA, ROCm, DPC++, and More Platform Changes

Sun, 26 Apr 2026 19:35:57 +0800

If the previous article worked as a desktop-focused overview of Ubuntu 26.04 LTS, this one is better read as its hardware and compute-side follow-up. In this 26.04 cycle, Ubuntu pushed a number of AI, GPU computing, and platform compatibility changes into the main archive or formal support scope.

The short version is this: the most important part of this round is not just desktop and kernel upgrades, but that Ubuntu is bringing Intel, NVIDIA, and AMD GPU computing stacks into the distribution in a more systematic way.

Starting with 26.04, Intel’s open-source oneAPI DPC++ compiler is available directly from Ubuntu Archive for building SYCL code. Its runtime also includes adapters for Intel GPUs.

Two related components are also now available from Ubuntu repositories:

oneDPL, the DPC++ library, which provides higher-productivity developer APIs
oneDNN, built with dpclang-6, which can run on Intel GPUs

That means if you are already working with SYCL, heterogeneous computing, or AI workloads on Intel GPUs, Ubuntu now offers a more direct path instead of forcing you to maintain a separate external stack for everything.

Ubuntu also calls out one practical requirement: users need to be in the render group to actually use these Intel GPU-related capabilities.

2. The NVIDIA CUDA toolkit can now be installed directly with `apt`

For many developers and operators, this may be one of the most immediately useful changes in the notes.

Starting with 26.04, the NVIDIA CUDA toolkit can now be installed directly from Ubuntu Archive:

`1`	`sudo apt install cuda-toolkit`

The value here is bigger than just saving a few setup steps.

For developers shipping software on Ubuntu, this new model means they can simply declare a dependency on the CUDA runtime, while Ubuntu manages installation and compatibility at the distribution level. That makes CUDA feel more like a native system capability on Ubuntu, rather than an extra software layer that always has to be maintained separately.

3. AMD ROCm 7.1.0 is now in Universe

On the AMD side, Ubuntu Universe now includes ROCm 7.1.0.

These libraries mainly provide:

backend infrastructure for AI training and inference on AMD GPUs
software foundations for machine learning and high performance computing

Canonical also notes that ROCm-related components are continuously tested in its CI/CD pipeline. Beyond autopkgtests, that includes several user-space applications such as:

llama.cpp
pytorch
Blender
Lemonade Server

That detail matters, because it shows Ubuntu is not just dropping packages into the archive. It is validating ROCm as a maintainable software stack.

4. The bigger story is that all three GPU ecosystems are landing

It becomes easier to see the direction of 26.04 when DPC++, CUDA, and ROCm are viewed together:

Intel: bringing SYCL / oneAPI components into official repositories
NVIDIA: giving the CUDA toolkit a distribution-managed installation path
AMD: shipping ROCm 7.1.0 in Universe with ongoing testing

If you work with these kinds of workloads on Ubuntu, this release will probably feel more relevant:

local LLM inference
GPU-accelerated training or fine-tuning
Blender, scientific computing, and HPC
development environments that need to move across different GPU platforms

In other words, Ubuntu is no longer just “a system where you can install a GPU driver.” It is starting to carry a fuller user-space software stack for AI and GPU computing.

5. NVIDIA Dynamic Boost is enabled by default

Since 25.04, Dynamic Boost has been enabled by default on supported NVIDIA laptops.

The idea is straightforward: depending on system load, power can be shifted dynamically between the CPU and GPU. In gaming scenarios, that usually means giving more power to the GPU when needed to extract more performance.

It only applies under two conditions:

the laptop is connected to AC power
the GPU load is high enough

It does not engage while the system is running on battery.

6. Support for new Intel integrated and discrete GPUs keeps moving forward

Ubuntu also continues expanding support for new Intel GPUs, including:

Integrated:

Intel Core Ultra Xe2
Intel Core Ultra Xe3

Discrete:

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

Ubuntu also highlights several features already available around these devices:

improved GPU and CPU ray tracing performance through Intel Embree, benefiting applications such as Blender 4.2+
hardware video encoding for AVC, JPEG, HEVC, and AV1 on “Battlemage” devices
a new CCS optimization in Intel Compute Runtime
enabled debugging support for Intel Xe GPUs

If you are watching follow-up releases, 25.10 also continues to bring in more capabilities, including:

initial support for Intel’s next-generation client platform codenamed Panther Lake through Linux kernel 6.17
improved IOMMU, PCIe subsystem, and multi-GPU support
Mesa 25.2.3 enabling VK_KHR_shader_bfloat16 for Battlemage and Panther Lake
intel-media-driver 25.3.0 adding Panther Lake decode support and VP9 encoding
intel-compute-runtime 25.31 adjusting the Level Zero USM pool and local device memory event allocation behavior
level-zero 1.24 and level-zero-raytracing 1.1.0 bringing broader spec and RTAS extension support

7. Suspend and resume is more stable on Nvidia desktops too

Starting with 25.10, Ubuntu enables suspend-resume support in the proprietary Nvidia driver to reduce corruption and freezing when waking a desktop system.

This is not the most visible kind of change, but it matters a lot in everyday use, especially on desktops that stay on for long periods and frequently suspend and resume.

8. ARM, Raspberry Pi, RISC-V, and IBM Z also get harder platform-level changes

Beyond the GPU software stack, the release notes also include several platform-level changes worth calling out separately.

ARM64 desktop platforms

Starting with 25.10, the ARM64 linux-generic kernel provides broader desktop compatibility for ARM64 desktop platforms that boot through UEFI.

A new Raspberry Pi boot layout

One change introduced in 25.10 and refined in 26.04 is a new boot partition layout for Raspberry Pi systems.

Its goal is to improve boot reliability: newly written boot assets are first “tested” before they are committed as the new “known good” set.

The firmware date requirements are the part most users will want to remember:

Pi 3 / 3+ / CM3+ / Zero 2W: no additional action required, the boot firmware is in the image itself
Pi 4 / 400 / CM4: boot firmware must be dated no earlier than 2022-11-25
Pi 5 / 500 / CM5: boot firmware must be dated no earlier than 2025-02-11

You can check it with:

`1`	`sudo rpi-eeprom-update`

If the firmware is too old and you are using Ubuntu 24.04 LTS or newer, you can update it like this:

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi desktop images now use desktop-minimal

Since 25.10, Ubuntu Desktop images for Raspberry Pi are based on desktop-minimal rather than the full desktop seed.

Ubuntu gives a very concrete benefit here: the default app set is smaller, saving about 777MB on the uncompressed image and on installed systems.

If you want to remove that default app set in bulk after upgrading, you can use:

`1`	`sudo apt purge ubuntu-desktop --autoremove`

If you want to keep some of those applications, just mark them as manually installed with apt first.

Swap on Raspberry Pi is now handled by cloud-init

Since 25.10, swap file creation on Raspberry Pi desktop images is handled by cloud-init.
If you want to customize swap size before first boot, you can edit user-data on the boot partition directly.

RISC-V requirements have moved up

Starting with 25.10, the RISC-V build of Ubuntu 26.04 LTS requires hardware that implements the RVA23S64 ISA profile.

Systems that do not meet that requirement can no longer run Ubuntu 26.04 LTS. If you still have boards based on earlier RVA20 processor cores, you need to stay on the support line provided by Ubuntu 24.04 LTS.

According to Ubuntu, as of April 2026, there is still no real RVA23S64 hardware available. So the only currently supported platform is effectively a QEMU virtualized environment configured with -cpu rva23s64.

IBM Z now requires z15 at minimum

Starting with 26.04, the minimum requirement for the s390x architecture has moved up to z15.

That means:

z14 / LinuxONE II and older systems can no longer install Ubuntu 26.04 LTS
z15 / LinuxONE III and newer systems should see better performance

9. Who should read this first

This article is more useful than the desktop overview if you fall into any of these cases:

you use Ubuntu for CUDA, ROCm, SYCL, or local AI inference
you do development or compute work on Intel, NVIDIA, or AMD GPUs
you maintain Raspberry Pi, ARM64, RISC-V, IBM Z, or other non-standard x86 platforms
you are especially sensitive to repository availability, driver behavior, runtimes, and platform requirements after an upgrade

10. One-line takeaway

The key point of Ubuntu 26.04 LTS on the hardware and AI stack side is not that one GPU vendor got a standout upgrade. It is that Intel’s DPC++, NVIDIA’s CUDA, and AMD’s ROCm are all entering the Ubuntu ecosystem in a more official, in-repository, and maintainable way.

If you used to think of Ubuntu as “the system first, then I assemble the GPU environment myself,” 26.04 starts to look more like a distribution that is willing to actively carry AI and heterogeneous computing workloads.

Ubuntu 26.04 LTS Released: Major Desktop Updates with GNOME 50 and Linux 7.0

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS was released on April 23, 2026, under the codename Resolute Raccoon. This is the new long-term support release, with standard support through April 2031. If you use Ubuntu Pro, security maintenance can be extended to 10 years.

If you are upgrading from Ubuntu 24.04 LTS, this is more than a routine release. It also folds in the major changes introduced across 24.10, 25.04, and 25.10. So this article works best as a quick guide to what is worth checking before you upgrade.

If you only want the biggest takeaways from this release, remember these four points first:

GNOME 50 has landed in an LTS release, bringing clearer improvements to desktop experience and display support
Linux kernel 7.0 becomes the new baseline, refreshing both hardware support and the long-term maintenance base
Ubuntu Desktop has now fully moved to Wayland
The default app set has been refreshed across the board, with major updates to Firefox, LibreOffice, Thunderbird, and GIMP

1. Start with the key updates

Ubuntu 26.04 LTS is a long-term support release with standard support through 2031-04
The desktop environment has been updated to GNOME 50
The generic kernel has moved to Linux kernel 7.0
Ubuntu Desktop now provides only a Wayland session
Older versions cannot jump directly to 26.04

If you are still on Ubuntu 22.04 LTS or 25.04, the official recommendation is to upgrade to Ubuntu 24.04 LTS or 25.10 first, then continue to 26.04 LTS.

2. Biggest change #1: GNOME 50 is now in LTS

The most visible desktop-side change this time is that GNOME 50 has finally entered an LTS release. For most users, the value is not one flashy standalone feature, but a smoother desktop experience overall:

Better usability on small screens and narrow windows
Notifications can be grouped by app
Continued improvements to HDR, VRR, and fractional scaling
Better smoothness and stability in remote desktop, Wayland, and NVIDIA-related scenarios
Stronger accessibility support, including clear updates to the Orca screen reader

Ubuntu has also added a few practical changes of its own:

GNOME Shell global search can directly find available snap apps
Web searches can also be triggered directly from search
The Yaru theme continues moving closer to upstream GNOME styling
Permissions, file access, and drag-and-drop behavior for snap apps feel more natural on the desktop

If you mainly use the desktop edition, the real point of this LTS is not a dramatic visual overhaul. It is that many small frictions from the past have been polished away together.

3. Biggest change #2: the default apps got a broad refresh

Compared with 24.04 LTS, the built-in app set in 26.04 LTS has been updated in a big way:

Firefox moves to 150
LibreOffice goes from 24.2 to 25.8
Thunderbird moves to 140
GIMP jumps from 2.10 to 3.2

There are also several replacements that matter in day-to-day use:

The PDF viewer is now Papers, replacing Evince
The image viewer is now Loupe
The terminal is now Ptyxis
The system monitor is now Resources
The default video player is now Showtime

The direction behind these changes is clear: Ubuntu is leaning more fully into a new generation of GNOME applications built on GTK4, libadwaita, and in some cases Rust-based rewrites.

4. Biggest change #3: Wayland is now the only desktop session

This is the most important change for many long-time users.

The shift that started in 25.10 is now fully settled in 26.04 LTS: Ubuntu Desktop runs only on the Wayland backend, because GNOME Shell can no longer run as an X.org session.

That does not mean old applications suddenly stop working. The official notes make it clear that X.org applications can still run through the XWayland compatibility layer. But if your workflow still depends on older graphics drivers, certain remote desktop methods, screen recording tools, or input method details, this is still something you should verify before upgrading.

5. Biggest change #4: Linux kernel 7.0 and the lower stack move forward together

The GA generic stack in Ubuntu 26.04 LTS moves from Linux 6.8 to Linux 7.0, and the HWE stack is also unified on 7.0.

Among the lower-level changes highlighted by Ubuntu, the most relevant ones for general users and operators are:

Crash dump is enabled by default on both desktop and server
sched_ext introduces a new scheduler extension model that lets developers implement scheduling policies with eBPF
The linux-lowlatency binary package is being retired, replaced by linux-generic plus the user-space lowlatency-kernel package for low-latency tuning
The amd64v3 architecture variant is available as an option, but still opt-in by default

If your machine is relatively new, amd64v3 is worth keeping an eye on. The official notes give this enablement method:

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

That said, it is not enabled automatically. Ubuntu is still prioritizing compatibility first.

6. Hardware requirements and install baseline

The official recommended baseline for Ubuntu Desktop 26.04 LTS is:

A 2 GHz dual-core processor or better
At least 6 GB RAM
At least 25 GB of available storage

If your machine is on the lighter side, the official recommendation is to consider Ubuntu flavors such as Xubuntu or Lubuntu.
The server edition has a lower floor. The documentation notes it can start from 1.5 GB RAM and 4 GB of storage, though the real requirement still depends on your workload.

7. Who should prioritize upgrading

If you are already on 24.04 LTS and want the following, 26.04 LTS is worth a close look:

A full-generation desktop stack refresh instead of minor patching
More mature Wayland and display support
A more up-to-date default application set
A newer kernel with a longer support runway

But if you still depend heavily on older X11 workflows, special drivers, or custom desktop extensions, or if your production environment is extremely conservative about changes, it is still best to do a compatibility pass before upgrading.

8. One-line summary

The value of Ubuntu 26.04 LTS is not one especially flashy headline feature. It is that Ubuntu has rolled two years of desktop, kernel, application, and compatibility progress into a new LTS baseline all at once.

If you want the shortest possible judgment, it is this: this is an Ubuntu LTS release that feels broadly newer and more stable as a whole, rather than one built around a single standout feature.

Official release notes: https://documentation.ubuntu.com/release-notes/26.04/
Summary for LTS users: https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/

Understanding the nftables Framework: Tables, Chains, Rules, and Sets

Sat, 18 Apr 2026 10:31:12 +0800

When learning nftables, it is easy to start with command details: how to add a rule, how to delete a handle, or how to write a port match. Commands matter, but if you understand the framework first, reading rules, troubleshooting, and designing rule sets become much easier.

You can think of nftables as a layered structure:

table isolates rule namespaces.
family decides which network protocols the rules apply to.
chain decides at which stage rules are executed.
rule defines the actual match and action.
set, map, and verdict map reduce repeated rules and make rule sets easier to maintain.

The following sections explain these concepts layer by layer.

table: Rule Namespace

table is the outermost rule container in nftables. Different tables are isolated from each other, so a common practice is to put related rules into the same table.

For example, you can separate filtering rules, NAT rules, or custom testing rules. This keeps boundaries clear: when debugging, you know which group of rules you are changing; when cleaning up, you are less likely to delete unrelated content by mistake.

A table itself does not directly process packets. The chain and rule objects inside the table are what actually participate in packet processing.

family: Which Protocols the Rules Apply To

When creating a table, you need to choose a family. It determines what kind of packets the rules in the table apply to.

Common families can be understood this way:

ip: handles IPv4 only.
ip6: handles IPv6 only.
inet: handles both IPv4 and IPv6.
arp: handles ARP.
bridge: handles bridge-layer traffic.
netdev: closer to the network device ingress path, suitable for handling traffic at an earlier stage.

For ordinary firewall rules, inet is commonly used. It lets you keep IPv4 and IPv6 rules in the same table and avoids maintaining two similar rule structures.

chain: Where Rules Are Executed

chain is a list of rules. After a packet enters a hook, it passes through the rules in the chain in order.

Chains can roughly be divided into two types:

Base chain: attached to a hook in the kernel network path and actively called by the packet flow.
Regular chain: not directly attached to a hook; it must be called by jumps from other rules.

A base chain usually specifies several key properties:

type: the purpose of the chain, such as filter, nat, or route.
hook: the processing stage, such as prerouting, input, forward, output, or postrouting.
priority: when multiple chains exist on the same hook, this decides which runs first.
policy: the default action when no rule matches, commonly accept or drop.

The key point is that rules do not take effect just anywhere. The same rule has completely different meaning when placed in input, forward, or output.

rule: Match Conditions Plus Actions

rule is where nftables actually makes decisions. It usually consists of two parts:

Match conditions: source IP, destination IP, protocol, port, interface, connection state, and so on.
Actions: accept, drop, reject, counter, jump, return, and so on.

Rules are evaluated in order. After a packet matches an action that terminates processing, subsequent rules are no longer evaluated. If nothing matches, evaluation continues until the chain ends or the default policy is triggered.

This is why rule order matters: more specific rules usually need to appear before broader rules, otherwise they may never get a chance to run.

set: Group Values Together

If you need to match many IP addresses, ports, or interfaces, writing many separate rules becomes hard to maintain. set lets you manage a group of values of the same type in one place.

For example, a group of trusted IPs, a group of blocked ports, or a group of addresses that need rate limiting can all be stored in a set. The rule only needs to check whether a value belongs to that set.

The benefits of set are:

Fewer rules.
Better readability.
Easier element additions and removals later.

When a rule set contains many repeated conditions, it is usually time to consider set.

map: Map a Matched Value to a Result

map can be understood as a lookup table. It returns a result based on an input value.

For example, different ports can map to different marks, or different addresses can map to different processing parameters. Compared with writing many if/else-style rules, map is more centralized and easier to maintain.

set answers “is this value in the collection”; map answers “what result corresponds to this value”.

verdict map: Map a Matched Value to an Action

verdict map is an important use of map: it maps a matched value to a verdict, which means a rule action.

For example, different IP ranges can correspond to accept, drop, or jumps to different chains. This can compress many branches into one structure.

When a rule set grows more complex, verdict map is very useful. It reduces repeated rules and expresses policy more like a table rather than a long list of conditional statements.

Designing Rules from the Concepts

When designing nftables rules, you can think in this order:

First decide which family the rules belong to.
Then decide which table they should go into.
Choose the proper hook and chain.
Write the concrete rule.
If there are many repeated conditions, introduce set, map, or verdict map.

Rules written this way are easier to maintain and easier to troubleshoot.

Summary

nftables concepts are not complicated, but the hierarchy matters:

table defines rule boundaries.
family defines protocol scope.
chain defines execution position.
rule defines matching and action.
set, map, and verdict map manage complexity.

Understand these concepts first, then look at concrete commands. That is more reliable than memorizing commands directly. Especially after a rule set grows, clear concepts help you determine whether a problem is in protocol scope, execution stage, rule order, or the match condition itself.

References

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables Quick Start: Tables, Chains, Rules, and Common Operations

Sat, 18 Apr 2026 10:22:07 +0800

nftables is a common packet filtering and firewall rule management tool on Linux. If you only need device access control, traffic counters, port matching, or basic rate limiting, you do not need to learn the entire rule system at once. Start with three concepts:

table: a container for rules.
chain: where rules are evaluated, usually attached to a hook.
rule: the actual matching condition and action.

This article outlines a minimal workflow that is suitable for testing first in a safe environment.

Basic Structure

Prepare a few variables first. The following commands reuse them:

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

Create an inet table that supports both IPv4 and IPv6:

`1`	`nft add table inet $table`

Then create a chain attached to the forward stage:

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

Here, type filter means this is a filtering rule chain, and hook forward means it processes forwarded packets.

Common Matching Methods

Match by source IP. This is usually useful for the upload direction:

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

Match by destination IP. This is usually useful for the download direction:

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

When matching by MAC address, ether saddr can be used to control upstream traffic:

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

Note that in networks involving bridging, forwarding, or address translation, downstream packets may not always be reliably filtered by destination MAC. For device access control, start by validating ether saddr or IP-based rules first.

To match ports, you can cover both TCP and UDP:

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

To match a port range, use a comparison expression:

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

Count Traffic for One Device

If you only want to count upload and download traffic for an IP address, use counter return. After a match, it records the counter and returns, which can reduce further matching overhead when more statistic rules exist later.

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

View the statistics:

`1`	`nft list chain inet $table $chain`

If you need to see the handle for each rule, add -a:

`1`	`nft -a list chain inet $table $chain`

handle is important because nftables usually relies on it to delete a single rule.

Basic Rate Limiting

Rate limiting can be done with limit rate over. For example, limit traffic over a specified rate by MAC address:

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

Here, mbytes and kbytes can be understood as the usual M and K units. You do not need to manually multiply by 8. In practice, start with a more relaxed value, confirm the matching direction and effect, then tighten it if needed.

Delete and Clean Up Rules

First list rules with handle values:

`1`	`nft -a list chain inet $table $chain`

Then delete a rule by handle:

`1`	`nft delete rule inet $table $chain handle <handle>`

Flush a chain:

`1`	`nft flush chain inet $table $chain`

Delete a chain:

`1`	`nft delete chain inet $table $chain`

Delete the entire table:

`1`	`nft delete table inet $table`

During daily debugging, only clean up the table you created yourself. Avoid directly changing tables automatically generated by the system or other services. This makes rollback easier even if a rule is written incorrectly.

Usage Notes

When using nftables, it is often safer to create your own independent table and chain first. This has two benefits:

Your rules are less likely to mix with existing system rules.
Debugging, flushing, and deletion are safer.

After writing rules, always use nft list chain to check actual matching behavior. MAC, interface, port, and rate-limit rules may behave differently across devices, bridge setups, and system versions. Small-scope testing is safer than writing complex rules all at once.

References

https://www.right.com.cn/forum/thread-8369750-1-1.html

Ollama Default Model Storage Path and Migration Guide (Avoid Filling Up C Drive)

Mon, 06 Apr 2026 09:38:00 +0800

When running local LLMs, the system drive is often the first thing to run out of space. Ollama stores models in user or system directories by default, so your C drive can fill up quickly without path planning.

Common Default Ollama Model Directories

Windows: C:\Users\<username>\.ollama\models
macOS: ~/.ollama/models
Linux: /usr/share/ollama/.ollama/models (may vary by installation method)

Windows: Move the Model Directory to a Non-System Drive

A practical choice is moving model storage to a path like D:\OllamaModels. The key is setting the OLLAMA_MODELS system environment variable.

1. Create the Target Directory

For example, create: D:\OllamaModels

2. Configure the System Environment Variable

Variable name: OLLAMA_MODELS
Variable value: D:\OllamaModels

You can set it in “System Properties -> Advanced -> Environment Variables”, or with an admin PowerShell command:

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. Restart Ollama (or Reboot the System)

After setting the variable, restart the Ollama service/app. If you’re unsure whether it has taken effect, rebooting the PC is the most reliable option.

4. Verify the New Path Is Active

Pull any model and check whether new files appear under D:\OllamaModels.

5. Clean Up the Old Directory (After Confirmation)

Once models work correctly in the new location, remove old files to reclaim C drive space.

FAQ

Still Writing to C Drive After Configuration

Confirm the variable is a system variable, not a temporary session variable.
Confirm the Ollama process was restarted.
Verify the variable name is exactly OLLAMA_MODELS.

Do I Need to Migrate Existing Model Files

If you want to avoid re-downloading, stop Ollama, copy existing model files to the new directory, then restart Ollama and verify.

Completely Uninstall Ollama on Linux (Including Leftover Cleanup)

Mon, 06 Apr 2026 09:16:29 +0800

If you need to remove Ollama completely from Linux, follow the steps below in order. This guide cleans up the service, executable, model directory, and the ollama user/group.

Before You Uninstall

The commands below will delete local Ollama model files (usually in /usr/share/ollama). Back up first if needed.
These commands use sudo by default. Make sure your account has administrator privileges.

1. Stop and Remove the systemd Service

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. Remove the Ollama Binary

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. Remove Ollama Library Directories (If Present)

If your installation wrote Ollama files into a lib directory, clean them up with:

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. Remove Model and Data Directory

`1`	`sudo rm -rf /usr/share/ollama`

5. Remove System User and Group (If Present)

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. Verify Uninstall Completion

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

If ollama is no longer found in the checks above, the uninstall is complete.

rsync --delete Explained and Practical Directory Cleanup

Sun, 29 Mar 2026 11:00:00 +0800

The core purpose of rsync --delete is to remove files in the target directory that do not exist in the source directory, so both sides stay consistent.

Typical use cases include:

Cleaning stale files on the target side during sync
Quickly emptying a target directory by syncing from an empty source directory

Basic Syntax

`1`	`rsync -a --delete source_dir/ target_dir/`

-a: archive mode, preserves permissions, timestamps, and other attributes
--delete: removes extra files on the target side

Important note: whether source_dir ends with / changes behavior. With /, rsync syncs directory contents; without /, it syncs the directory itself.

Quickly Empty a Target Directory with an Empty Source

If your goal is to keep the directory path but clear all contents, use an empty directory as the source:

# 1) Create an empty directory
mkdir -p /tmp/empty_dir

# 2) Sync and delete target-side content
rsync -a --delete /tmp/empty_dir/ /path/to/target_dir/

In large-directory scenarios, this is often more efficient than deleting files one by one, and it is easier to automate in scripts.

Common Extended Options

--delete-before: delete before transfer, which can be faster in some cases
--progress: show transfer and processing progress

Example (cleaning an Nginx log directory):

`1`	`rsync -a --delete --progress /tmp/empty_dir/ /var/log/nginx/`

Recommendations

Run with --dry-run first to verify the deletion scope
Back up the target directory before running in production
For critical paths, schedule execution during off-peak hours

How Git Tracks File Executable Permission (+x)

Sun, 29 Mar 2026 10:00:00 +0800

In a Linux environment, Git tracks a file’s executable bit (+x). If you want a script to be preserved as an executable file in the repository, you need to explicitly record that permission change in Git.

Add Executable Permission to a File

1
2
3

git update-index --chmod=+x script.sh
git commit -m "chore: mark script.sh as executable"
git push

This command stages the executable-bit change for script.sh. After you commit and push, other users will keep the same permission state when they pull or clone the repository.

Remove Executable Permission from a File

1
2
3

git update-index --chmod=-x script.sh
git commit -m "chore: remove executable bit from script.sh"
git push

Verify the Result

Use the following commands to check file permissions in your working tree:

1
2

git clone xxxxxxxxxxxxxxx
ls -l script.sh

If you see something like -rwxr-xr-x, the file is executable. If you see -rw-r--r--, it is not executable.

Notes

git update-index --chmod=+x/-x only updates the file mode recorded by Git; it does not replace changes to file content.
In team workflows, it is best to commit permission-only changes separately for easier review and tracking.

Linux on KnightLi Blog

pci=nomsi and pcie_aspm=off explained: troubleshooting SATA expansion cards not detected, dropping disks, or freezing on Linux

pci=nomsi: disable message-signaled interrupts

What is MSI?

What happens after adding pci=nomsi?

pcie_aspm=off: disable PCIe Active State Power Management

What is ASPM?

What happens after adding pcie_aspm=off?

The difference between the two parameters

Should you add both?

How to make it permanent on Ubuntu / Debian

What else should you check?

Summary

CVE-2026-43494 / PinTheft: Local Privilege Escalation Risk from Linux RDS and io_uring

What Is the Core Bug?

Why It Is Called PinTheft

The Trigger Conditions Are Not Broad

One-Minute Self-Check

Which Machines Deserve Priority

Temporary Mitigation Ideas

How to Verify After Fixing

References

Impact Summary of Four Recent Linux Local Security Issues: Copy Fail, Dirty Frag, Fragnesia, and ssh-keysign-pwn

What the Four Events Affect

Copy Fail: High Priority for Containers and CI Nodes

Dirty Frag: A Post-Compromise Amplifier

Fragnesia: Similar Attack Surfaces Are Not Cleaned Up All at Once

ssh-keysign-pwn: Not Direct Root, Still Dangerous

Shared Impact: Containers Are Not a Strong Boundary by Default

Shared Impact: Patches Must Reach the Running Kernel

Shared Impact: Attack Surface Reduction Must Be Specific

Suggested Response Order

Conclusion

ssh-keysign-pwn (CVE-2026-46333): Linux Local Information Disclosure, SSH Host Keys, and /etc/shadow Risk

Bottom line

What the vulnerability is

Why SSH host private keys and /etc/shadow may be exposed

How to assess exposure

Which machines to prioritize

Remediation guidance

Temporary mitigation: tighten ptrace_scope

Should SSH host keys be rotated?

What to monitor

Common misconceptions

Response checklist

Summary

Dirty Frag, Copy Fail, and Fragnesia: Comparing Three Recent Linux Local Privilege Escalation Flaws

What the Three Flaws Are

Dirty Frag: CVE-2026-43284

Copy Fail: CVE-2026-31431

Fragnesia: CVE-2026-46300

Similarities: Why They Are Dangerous

Differences: One Mitigation Does Not Cover All

How to Judge Exposure

Operational Priority

How to Treat Temporary Mitigation

What These Three Flaws Tell Us

Summary

Fragnesia (CVE-2026-46300): Impact and Mitigation for a Linux Kernel Local Privilege Escalation Flaw

How It Relates to Dirty Frag

Why the Risk Is High

Known Affected Scope

Temporary Mitigation

If Exploitation Is Suspected

Which Machines Should Come First

Summary

Dirty Frag CVE-2026-43284: Linux Local Privilege Escalation Risk and Mitigation Guide

Which CVEs are involved

Technical overview

Environments to prioritize

Patch first

Interim mitigation: disable related modules

Evaluate business impact before disabling

Do not skip post-compromise checks

About drop_caches

Recommended response order

Summary

Btrfs Scrub Guide: Data Verification, Auto-Repair, and Regular Maintenance

What scrub checks

Common commands