MX Linux 25 Beta: Debian 13 Base, Qt6 Tools and Dual Init Support

  • Thread Author
MX Linux 25’s first public beta lands today, and it marks a clear pivot: the distro is now built on Debian 13 “Trixie,” ships refreshed desktops, modernizes package source handling with the deb822 format, and moves many MX Tools to Qt6 while introducing a new updater and installer improvements that aim to make upgrades and hardware support easier — all packaged as parallel systemd and SysVInit editions for users with different init preferences.

Background​

MX Linux has long occupied a middle ground in the Debian ecosystem: polished, conservative defaults focused on stability, a lightweight Xfce flagship, and a reputation for powerful, user-friendly utilities (the MX Tools) inherited from a close partnership with antiX. With MX-25 (codename “Infinity”) the project adopts Debian 13 as its base, aligning itself with Debian’s updated stack while retaining MX-specific packaging, tooling, and the option to run SysVInit for users who still prefer a non-systemd init.
This beta — published as multiple ISOs for Xfce, KDE Plasma, and Fluxbox — is not a mere package refresh. It bundles upstream desktop updates (Xfce 4.20, KDE Plasma 6.3.6, Fluxbox 1.3.7), adjusts kernels (Debian’s 6.12 series on standard images; Liquorix 6.15 for Advanced Hardware Support or AHS images), and updates important build-time and runtime components such as APT’s sources format and MX Tools’ UI toolkit. The release is explicitly experimental; the team asks testers to focus on installer behavior (ext4 and Btrfs), MX Tools regressions, and package installer/popular-apps entries.

What’s new in MX Linux 25 beta — overview​

  • Debian 13 “Trixie” base — the entire stack moves to Debian stable’s Trixie packages, bringing newer desktop stacks and a 6.12 LTS kernel series.
  • Multiple init editions — systemd and SysVInit images are available for Xfce and Fluxbox; KDE Plasma is systemd-only.
  • Updated desktops — Xfce 4.20, KDE Plasma 6.3.6 (Wayland by default), Fluxbox 1.3.7.
  • Kernels — default Debian kernel (6.12.x LTS) on standard ISO; Liquorix 6.15 kernels on AHS ISOs for newer hardware.
  • deb822 sources format — APT sources move to deb822-based .sources files under /etc/apt/sources.list.d; legacy .list files still supported.
  • MX Tools → Qt6 — the GUI toolset is migrating to Qt6 for better future compatibility.
  • New updater: mx-updater — replaces apt-notifier and can optionally use nala as a backend.
  • Installer improvements — “replace existing Linux installation” workflow (not yet supporting encrypted roots), zram swap setup, optimizations, and 64-bit UEFI Secure Boot support (requires Debian-signed kernels).
  • antiX live integration — the live system adjustments improve compatibility when using systemd.
These points summarize the changes visible in the beta ISOs and the developer notes accompanying them.

Technical deep dive​

Debian 13 base: why it matters​

MX Linux adopting Debian 13 gives immediate access to a more modern base:
  • Newer kernels (Linux 6.12 LTS series), toolchains (GCC/Clang updates), and desktop stacks.
  • Official desktop versions such as Xfce 4.20 and KDE Plasma 6.x are included upstream, reducing divergence work for MX packagers.
  • Debian’s release also promotes long-term security support for the base system.
For MX users this means an easier path to newer hardware support and a refreshed set of applications, while MX-specific repositories continue to provide distro-specific fixes and utilities.

Kernel strategy: Debian 6.12 vs Liquorix 6.15 (AHS)​

MX-25’s standard ISOs ship with Debian’s 6.12 LTS kernel series. AHS builds use a Liquorix kernel from the 6.15 branch to address newer hardware and workstation needs. Practically this splits the user base:
  • Standard ISOs (Debian kernel 6.12.x): aimed at stability and Secure Boot compatibility via Debian-signed kernels.
  • AHS ISOs (Liquorix 6.15): optimized for bleeding-edge hardware and lower-latency workloads (useful for audio production, pro-audio, or newer GPUs) but do not support Secure Boot out of the box.
This is a pragmatic balance: provide a conservative, signed-kernel path for broad compatibility while offering an AHS kernel for users who need newer hardware support or performance tuning.

Desktop updates: Xfce, KDE, Fluxbox​

  • Xfce 4.20 continues Xfce’s modernization trajectory with visual and backend refinements. For MX this remains the mainline, lightweight desktop and the likely default experience for many users.
  • KDE Plasma 6.3.6 ships as the KDE option and uses Wayland by default; X11 remains selectable at login. Plasma 6.x brings the Qt6/Qt 6-based KDE stack improvements and a modern compositing experience. Expect improved rendering and better support for high-DPI displays, but also potential teething issues tied to the relatively newer Plasma code path.
  • Fluxbox 1.3.7 gets configuration and UX updates: revised panel, rofi integration improvements, and redesigned root menus. Fluxbox remains MX’s minimal-window-manager flavor for advanced users wanting a very small footprint.

Packaging and APT modernizations: deb822 and *.sources files​

One of the more structural changes is the movement toward the deb822-style sources files in /etc/apt/sources.list.d/*.sources. This format uses multi-line stanzas (key: value) instead of one-line deb/deb-src entries and allows explicit Signed-By keys and clear key-value mapping per source.
Key implications:
  • Better maintainability and clearer Signed-By entries for repository keys enhance security posture by making key usage explicit.
  • Configuration management tools and graphical utilities need updates to parse and manage deb822 entries. MX Repo Manager has been updated to handle both formats — the legacy *.list files remain supported to ease migration.
The upstream APT tooling also includes utilities (apt modernize-sources) to convert traditional sources lists to deb822. This is a system-level change that will affect many Debian-derived distributions in 2025 and beyond.

MX Tools migration to Qt6​

MX Tools — the collection of GUI utilities (package manager front-ends, installers, service managers, etc.) — are being ported to Qt6. Benefits include:
  • Future-proofing user interfaces against Qt5 deprecation.
  • Improved theme and rendering support on modern desktops (KDE/Plasma in particular).
  • A single toolkit standard across KDE and MX components.
Risks include potential regressions as porting introduces new dependencies and UX changes; the beta explicitly asks testers to focus on MX Tools, especially the Package Installer.

The new updater: mx-updater and optional nala backend​

Mx-updater replaces the long-standing apt-notifier. It aims to be functionally similar but adds preferences and an optional backend choice: nala. Nala is a front-end to APT that provides a nicer output and faster dependency resolution in many user reports. The new updater can:
  • Use traditional apt as the backend, preserving compatibility.
  • Switch to nala for a different update UI/behavior.
This is an interesting evolution: giving users the option to choose the upgrade plumbing without sacrificing the distro’s defaults. Testers should note known issues reported in the beta, like crashes when using “hide until updates” in the updater.

Installer improvements: replace function, zram, Secure Boot​

The installer receives several notable changes:
  • A replace existing Linux installation flow that can overwrite another distro install — handy for users who want to migrate without manual partition juggling. It currently does not support replacing encrypted installations.
  • zram swap support for on-the-fly compressed swap in RAM — helpful for systems with limited RAM.
  • 64-bit UEFI Secure Boot support using Debian-signed kernels, while Liquorix kernels remain unsigned and therefore incompatible with Secure Boot unless the user enrolls a custom key.
These changes aim to reduce friction during installs and address modern hardware needs, but the encryption caveat is important for privacy-conscious users.

Known issues and beta caveats​

The beta notes list several concrete problems to watch for:
  • Installer icon may not show on Fluxbox desktop (workaround: launch installer from MX-Welcome or via terminal).
  • mx-updater can crash when using the “hide until updates” function.
  • quick-system-info may fail if apt-history logs do not exist.
  • Missing root-actions integrations in Dolphin on KDE edition.
  • The “replace” installer function currently lacks encrypted-system support.
As with any beta, these are live issues and may be resolved prior to final release, but they define realistic test cases for early adopters.

Strengths: where MX Linux 25 shines​

  • Balanced approach to modernization: By moving to Debian 13 while preserving AHS Liquorix builds, MX offers both stability and hardware freshness.
  • Multiple init options: Offering systemd and SysVInit in parallel is rare and respects MX’s historical user base that values init choice.
  • Tooling modernization: Porting MX Tools to Qt6 prepares the distro for the Qt6/KDE future and keeps interfaces consistent.
  • Improved package source security: The deb822 format and Signed-By support reduce ambiguity about repository keys, which is positive for security and reproducibility.
  • Installer features: zram swap, a replace-install workflow, and Secure Boot support (for signed kernels) make installation more practical for a wider range of users.
  • Desktop variety: Supporting Xfce (lightweight, stable), KDE Plasma (feature-rich, Wayland by default), and Fluxbox (minimal) caters to diverse user preferences.

Risks and potential drawbacks​

  • Migration complexity: Moving to deb822 and Qt6 is a structural shift. Expect configuration tools, third-party repos, or user scripts to need updates. Administrators should audit automation and management tooling before upgrading production machines.
  • Secure Boot fragmentation: With Liquorix kernels unsigned, AHS users lose Secure Boot compatibility. Users who rely on Secure Boot (corporate-managed laptops, some OEMs) must stick to Debian-signed kernel images or arrange key enrollment.
  • Qt6 port regressions: Porting widely-used tools to a new toolkit can introduce subtle bugs, theme mismatches, or regressions in workflow; community testing will be critical.
  • Systemd vs SysVInit split maintenance: Maintaining two init-support paths increases QA surface area and potential blind spots, particularly as more upstream packages assume systemd-related features.
  • Beta stability: Known bugs in the beta (updater crashes, installer quirks) mean this is not yet production-ready and should be used for testing and feedback only.

Migration and upgrade guidance (practical steps)​

  • Backup everything — full disk image or at least /home and important system configs.
  • Test installer on non-production hardware first, focusing on your preferred filesystem (ext4 or Btrfs) and noting the behavior of the “replace” flow.
  • If using Secure Boot, plan to use the standard ISO with Debian-signed kernels; avoid the Liquorix AHS images or prepare to enroll a local MOK (Machine Owner Key).
  • Inspect /etc/apt/sources.list.d after installation. If your environment uses legacy *.list files, decide when to convert to deb822 using apt modernize-sources and test repository tooling (CI, automation).
  • Evaluate MX Tools workflows after the Qt6 migration — open MX Package Installer, Repo Manager, and other utilities to ensure your daily tasks are covered.
  • If you plan to use nala for updates, test mx-updater in both apt and nala modes; monitor for the “hide until updates” crash and report it if encountered.

Security and enterprise considerations​

  • The adoption of deb822 and explicit Signed-By entries strengthens repository authenticity habits — a benefit for any security-conscious deployment.
  • The split in kernel signing (Debian-signed vs Liquorix unsigned) complicates Secure Boot policies. Enterprises that enforce Secure Boot should standardize on Debian-signed kernels or adopt a workflow to sign custom kernels centrally.
  • Systemd vs SysVInit dual support may be attractive for legacy workloads but introduces divergence in monitoring, service management expectations, and tooling compatibility. Standardizing on one init for enterprise fleets remains advisable for manageability.

Community testing priorities​

For testers and community contributors, the MX team has called out these high-value targets:
  • Installer behavior on ext4 and Btrfs, and the replace-existing-installation path.
  • MX Tools, particularly the Package Installer’s “popular apps” entries.
  • MX Repo Manager’s handling of deb822 files and mirror localization routines.
  • KDE root actions in Dolphin, updater stability, and Fluxbox UI quirks.
  • AHS kernel behavior on specific hardware (NVIDIA drivers and legacy driver compatibility were noted in prior AHS discussions).
Reporting clear reproduction steps, kernel and iso checksums, and logs will accelerate fixes.

How this positions MX Linux in 2025’s Linux desktop landscape​

MX Linux 25’s approach is pragmatic: it modernizes the base, keeps conservative defaults for those who want them, and offers options for power users. The decision to provide systemd and SysVInit in parallel is politically and technically significant; it underscores MX’s intent to be inclusive of differing philosophies while leveraging the realities of upstream desktop and hardware support that increasingly assume systemd.
The deb822 adoption aligns MX with Debian’s own modernization, reducing later divergence. Qt6 migration of MX Tools signals readiness for the next generation of desktop components, especially as KDE, many applications, and future toolkits solidify Qt6 as the baseline.
Compared to other Debian-derived desktops, MX remains differentiated by its tooling, snapshot and remaster capabilities (antiX heritage), and the maintenance of lightweight shells like Fluxbox. These remain strong draws for enthusiasts, educational deployments, and refurbishment projects where performance and tooling matter more than the latest desktop bells.

Verdict and final recommendations​

MX Linux 25 beta is a substantive update that balances modernization with conservatism. For testers and enthusiasts it’s an appealing snapshot: newer kernels and desktops, modernized packaging formats, and refreshed tooling. However, it is a beta and should be treated accordingly — not installed on critical production machines.
Recommended course for different users:
  • Casual or production users: Wait for the stable release unless you have a dedicated test machine, especially if you rely on Secure Boot or encrypted root setups.
  • Power users and testers: Download the relevant beta ISO (choose AHS if you need newer kernel support) and stress test installer paths, MX Tools, and repo handling.
  • System administrators: Review automation tools and management scripts for compatibility with deb822; test apt modernize-sources in a sandbox and create a rollback plan.
MX Linux’s strengths — a focused toolkit, multiple desktop flavors, and careful packaging — remain intact and are enhanced by the Debian 13 base and Qt6 migration. The trade-offs involve short-term instability and the usual beta risks, but the design choices set MX 25 on a path that should serve both conservative users and those chasing newer hardware well.
The beta serves its purpose: solicit real-world testing, identify regressions, and refine features like the installer’s replace flow and the new updater. For anyone invested in the MX ecosystem, this release is worth watching closely and, if possible, participating in by testing and reporting issues.

Source: BetaNews MX Linux 25 beta arrives with Debian 13 base and updated desktops