Nostr notes by Arch Linux: Recent news updates (RSS Feed)

Mkinitcpio >=42 requires manual intervention for TPM2-based ...

2026-09-22T09:09:27Z

Mkinitcpio >=42 requires manual intervention for TPM2-based unlocking of LUKS devices

Starting with package version 42-1, the mkinitcpio systemd hook now includes systemd-pcrosseparator.service (as https://github.com/systemd/systemd/blob/1f9d56a7ab1d814044ac02939b42fd0efb99a8ab/NEWS#L69).

This affects the measurements of PCR values 0-7, 9 and 12-14.
If you configured the systemd hook and unlock LUKS partitions, that depend on these values, you need to re-enroll the https://wiki.archlinux.org/title/Trusted_Platform_Module in use.

For guidance, please refer to https://man.archlinux.org/man/systemd-cryptenroll.1, or the https://wiki.archlinux.org/title/Systemd-cryptenroll, when using pinned values.
Refer to https://man.archlinux.org/man/core/systemd/systemd-pcrlock.8, when relying on custom policies and a disabled systemd-pcrlock-make-policy.service.

https://archlinux.org/news/mkinitcpio-42-requires-manual-intervention-for-tpm2-based-unlocking-of-luks-devices/

Active AUR malicious packages incident We are currently ...

2026-06-12T18:41:28Z

Active AUR malicious packages incident

We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository.

We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed.
While this is happening, and while we work to create a more permanent solution, users may see issues with the following:

- Creating new accounts on the AUR

- Pushing package updates

- Adopting or creating new packages

We continue to encourage all users of AUR packages to review all PKGBUILD and install script changes when updating, especially during this time.
If you notice suspicious commits to a package that you use, please reach out to Arch staff via the aur-general mailing list with more information.

https://archlinux.org/news/active-aur-malicious-packages-incident/

Arch Linux 2026 Leader Election Results Recently we held our ...

2026-06-04T12:27:57Z

Arch Linux 2026 Leader Election Results

Recently we held our leader elections and after a lively discussion period on the (internal) mailing lists and voting phase with two candidates https://archlinux.org/people/developers/#anthraxx was re-elected as Arch Linux Project Lead.

As per https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader#Election he is re-elected with the term lasting two years.

The role of of the project lead within Arch Linux is connected to https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader#Roles regarding decision making (when no consensus can be reached), community leadership, Code of Conduct enforcement, handling
financial matters with SPI and overall project management tasks.

Congratulations to Levente, thank you for stepping up to serve this community and all the best wishes for another successful term! 🥳

https://archlinux.org/news/arch-linux-2026-leader-election-results/

Breaking changes for all users of `varnish`, which is renamed to ...

2026-05-25T04:58:52Z

Breaking changes for all users of `varnish`, which is renamed to `vinyl-cache`

The Varnish project has https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html#org-vinyl-varnish.
We followed this rename with a https://gitlab.archlinux.org/archlinux/packaging/packages/vinyl-cache.
This upgrade results in https://vinyl-cache.org/docs/9.0/whats-new/upgrading-9.0.html and users are advised to study these changes and how it affects them before following the replacement.
All references to "varnish" have been changed to "vinyl" in all binaries and directories.

At minimum, users will have to:

- rename /etc/varnish to /etc/vinyl-cache

- rename /var/lib/varnish to /var/lib/vinyl-cache

- fix up ownership of files inside /var/lib/varnish

- user varnish becomes vinyl

- group varnish becomes vinyl

- user varnishlog becomes vinyllog

- user vcache remains the same

- disable the old varnish.service and varnishncsa.service systemd units

- enable the new vinyl-cache.service and vinylncsa.service systemd units

Meanwhile, the varnish package has been dropped from [extra].
We're not currently planning to maintain a new varnish package as it's a different upstream project.

https://archlinux.org/news/breaking-changes-for-all-users-of-varnish-which-is-renamed-to-vinyl-cache/

iptables now defaults to the nft backend The old iptables-nft ...

2026-04-05T18:28:33Z

iptables now defaults to the nft backend

The old iptables-nft package name is replaced by iptables, and the
legacy backend is available as iptables-legacy.

When switching packages (among iptables-nft, iptables, iptables-legacy),
check for .pacsave files in /etc/iptables/ and restore your rules if needed:

- /etc/iptables/iptables.rules.pacsave

- /etc/iptables/ip6tables.rules.pacsave

Most setups should work unchanged, but users relying on uncommon xtables
extensions or legacy-only behavior should test carefully and use
iptables-legacy if required.

https://archlinux.org/news/iptables-now-defaults-to-the-nft-backend/

NVIDIA 590 driver drops Pascal and lower support; main packages ...

2025-12-20T18:53:42Z

NVIDIA 590 driver drops Pascal and lower support; main packages switch to Open Kernel Modules

With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the nvidia package with nvidia-open, nvidia-dkms with nvidia-open-dkms, and nvidia-lts with nvidia-lts-open.
Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment.
Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:

Uninstall the official nvidia, nvidia-lts, or nvidia-dkms packages.
Install nvidia-580xx-dkms from the AUR

Users with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention.

https://archlinux.org/news/nvidia-590-driver-drops-pascal-support-main-packages-switch-to-open-kernel-modules/

waydroid >= 1.5.4-3 update may require manual intervention The ...

2025-11-06T00:35:08Z

waydroid >= 1.5.4-3 update may require manual intervention

The waydroid package prior to version 1.5.4-2 (including aur/waydroid) creates Python byte-code files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process.
As a result, the upgrade may conflict with the unowned files created in previous versions. If you encounter errors like the following during the update:

error: failed to commit transaction (conflicting files)
waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem
waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem
waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem

You can safely overwrite these files by running the following command:
pacman -Syu --overwrite /usr/lib/waydroid/tools/\*__pycache__/\*

https://archlinux.org/news/waydroid-154-3-update-may-require-manual-intervention/

dovecot >= 2.4 requires manual intervention The dovecot 2.4 ...

2025-10-31T21:20:51Z

dovecot >= 2.4 requires manual intervention

The dovecot 2.4 release branch has made breaking changes which result
in it being incompatible with any <= 2.3 configuration file.
Thus, the dovecot service will no longer be able to start until the
configuration file was migrated, requiring manual intervention.
For guidance on the 2.3-to-2.4 migration, please refer to the
following upstream documentation:
https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html

Furthermore, the dovecot 2.4 branch no longer supports their
replication feature, it was removed.
For users relying on the replication feature or who are unable to
perform the 2.4 migration right now, we provide alternative packages
available in [extra]:

dovecot23
pigeonhole23
dovecot23-fts-elastic
dovecot23-fts-xapian

The dovecot 2.3 release branch is going to <a href="https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L76DOC3NKUNSSPIXQNKINGOCYH5K/"; rel="nofollow">receive critical security
fixes</a>
from upstream until stated otherwise.

https://archlinux.org/news/dovecot-24-requires-manual-intervention/