February 2026 - Arch-general - lists.archlinux.org

Bring ARM into the fold?
by Christer Solskogen 20 Apr '26

20 Apr '26

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

14 27

6.18.13 and updated mdadm (RAID1) won't boot, dropped to recovery console, LTS fine - help?
by David C Rankin 27 Feb '26

27 Feb '26

All, This is the first fail to boot I've had with Arch in years. After a relatively small update, which went fine on my test machine (no RAID/mdadm), I updated the server and was dropped to recovery console on reboot (mild panic set in looking at the "failed to find ....") The update included the 6.18.13 kernel and mdadm 4.5-1. Those were the only packages I could see that may be relevant to this issue (possibly the firmware) Prior to reboot I'd checked that all drives, etc. wer okay, no journal entries out of the ordinary, etc.. But on reboot, the boot failed and I was dropped to the recovery console. I also have LTS on this box, just for the case where an updated kernel doesn't boot, so instead of groping around half-blind in the recovery console, I rebooted and chose to boot LTS -- all fine. This is where I need help. How do I figure out what failed to cause the new 6.18.13 kernel to not boot? LTS is fine, machine is up, running and happy, just as it was on 6.18.9.arch1-2 (prior kernel). Not finding a driver and dropping to the recovery console leaves no logs, so how do I find out why the new kernel and mdadm package are failing? Should I just downgrade those packages (kernel and mdadm) and see if that works, or is there are more systematic way to approach this. I'm proficient in a lot of areas, but unfortunately diagnosing what went wrong from the recovery console isn't one of them. (I'd generally boot the install CD and chroot the system and go at it that way). Anybody able to provide any guidance on how to recover the 6.18.13 setup, or what information I need to check to see why it's failing? My only inclination is the download and burn a new install CD, chroot and try rebuilding initramfs? Curiously, the new initramfs is quite a bit smaller than LTS: -rw------- 1 root root 10250207 Feb 26 21:42 initramfs-linux-lts.img -rw------- 1 root root 9633236 Feb 26 21:43 initramfs-linux.img I always check the "Latest News" feed for any gotchas before upgrading the server, and there was nothing this time, but... Something went very wrong -- help... The list full list of packages updated were: Packages (70) adwaita-fonts-50.0-1 apparmor-4.1.6-2 bubblewrap-0.11.0-2 ca-certificates-mozilla-3.121-1 cpupower-6.19.3-1 ddrescue-1.30-2 deno-2.7.1-1 fasm-1.73.35-1 feh-3.11.3-1 firefox-148.0-1 gawk-5.4.0-1 giac-2.0.0.21-1 glslang-1:1.4.341.0-2 gpgme-2.0.1-3 gst-libav-1.28.1-1 gst-plugins-bad-1.28.1-1 gst-plugins-bad-libs-1.28.1-1 gst-plugins-base-1.28.1-1 gst-plugins-base-libs-1.28.1-1 gst-plugins-good-1.28.1-1 gstreamer-1.28.1-1 inkscape-1.4.3-4 libfyaml-0.9.5-1 libid3tag-0.16.4-1 libinih-62-2 libkeccak-1.4.3-1 libksba-1.6.8-1 libldac-2.0.2.3-3 libmaxminddb-1.13.2-1 libngtcp2-1.21.0-1 libplacebo-7.360.0-2 libreoffice-still-25.8.5-2 libxmp-4.7.0-1 linux-6.18.13.arch1-1 linux-docs-6.18.13.arch1-1 linux-firmware-20260221-1 linux-firmware-amdgpu-20260221-1 linux-firmware-atheros-20260221-1 linux-firmware-broadcom-20260221-1 linux-firmware-cirrus-20260221-1 linux-firmware-intel-20260221-1 linux-firmware-mediatek-20260221-1 linux-firmware-nvidia-20260221-1 linux-firmware-other-20260221-1 linux-firmware-radeon-20260221-1 linux-firmware-realtek-20260221-1 linux-firmware-whence-20260221-1 linux-headers-6.18.13.arch1-1 mdadm-4.5-1 mesa-1:26.0.1-1 nss-3.121-1 openmpi-5.0.10-1 parallel-20260222-1 poppler-26.02.0-2 poppler-glib-26.02.0-2 poppler-qt6-26.02.0-2 postgresql-18.3-1 postgresql-docs-18.3-1 postgresql-libs-18.3-1 python-chardet-6.0.0.post1-1 python-platformdirs-4.9.3-1 python-pypdf-6.7.3-1 python-requests-2.32.5-4 sha3sum-1.2.4-1 shaderc-2026.1-2 spandsp-0.0.6-7 spirv-tools-1:1.4.341.0-2 vim-9.2.0067-1 vim-runtime-9.2.0067-1 xkeyboard-config-2.47-1 -- David C. Rankin, J.D.,P.E.

3 4

strange message on booting the system
by Frank 27 Feb '26

27 Feb '26

Hello, I'm seeing this message when booting the system: Unable to resume from device 'dev/disk/by-partuuid/foo/bar' (259:3) offset 0, continuing boot process. After this the system starts as expected. Resuming from a hibernation image works fine, I only get this message on normal boot. I'm using systemd-boot as my boot manager. Frank

2 1

systemd-coredump[1815]: [🡕] Process 808 (named) of user 40 dumped core.
by David C Rankin 26 Feb '26

26 Feb '26

Arch devs, Not sure if this is worth a bug report to Arch? Upstream?, but for the first time in 24 years named core dumped on me (bind 9.20.18-1). The journal entry is: Feb 12 02:54:22 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 66.76.175.100#53 Feb 12 02:54:23 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 208.180.42.100#53 Feb 12 02:54:24 valkyrie named[808]: timed out resolving '240.78.147.in-addr.arpa/NS/IN': 8.8.4.4#53 Feb 12 02:54:24 valkyrie named[808]: network unreachable resolving '240.78.147.in-addr.arpa/NS/IN': 2001:500:f0::63#53 Feb 12 02:54:25 valkyrie named[808]: host unreachable resolving '119.240.78.147.in-addr.arpa/PTR/IN': 147.78.247.25#53 Feb 12 02:54:25 valkyrie named[808]: named: src/unix/udp.c:292: uv__udp_recvmsg: Assertion `handle->recv_cb != NULL' failed. Feb 12 02:54:25 valkyrie systemd-coredump[1815]: [🡕] Process 808 (named) of user 40 dumped core. Stack trace of thread 849: #0 0x00007fbcbc53da2c n/a (libc.so.6 + 0x98a2c) #1 0x00007fbcbc4e31a0 raise (libc.so.6 + 0x3e1a0) #2 0x00007fbcbc4ca5fe abort (libc.so.6 + 0x255fe) #3 0x00007fbcbc4cb697 n/a (libc.so.6 + 0x26697) #4 0x00007fbcbc4db0b2 __assert_fail (libc.so.6 + 0x360b2) #5 0x00007fbcbcdc7246 n/a (libuv.so.1 + 0xa246) #6 0x00007fbcbcdd1985 n/a (libuv.so.1 + 0x14985) #7 0x00007fbcbcde7ad4 n/a (libuv.so.1 + 0x2aad4) #8 0x00007fbcbcdd2b12 uv_run (libuv.so.1 + 0x15b12) #9 0x00007fbcbd278700 n/a (libisc-9.20.18.so + 0x4b700) #10 0x00007fbcbd28aef0 n/a (libisc-9.20.18.so + 0x5def0) #11 0x00007fbcbc53b97a n/a (libc.so.6 + 0x9697a) #12 0x00007fbcbc5bf2bc n/a (libc.so.6 + 0x11a2bc) ... I've run bind since 2002, and on Arch since 2009 and never in all that time had it crash. The whois on 147.78.247.25 is also rather interesting, a rent-a-server shop with US and Japanese corporate registration info. Given the uniqueness of this crash, there probably should be a report, but I'm not sure if it should go to Arch or ISC (or both with the gitlab bug just tracking upstream) What say the Arch folks? Bug needed? If so, start with Arch, ISC or both? (or maybe freedesktop? but that didn't seem like it was involved other than catching the crash) -- David C. Rankin, J.D.,P.E.

2 1

pacman -Syu listing as a column?
by StyxSailor 25 Feb '26

25 Feb '26

Hi, apologies for the very basic question, but I've relatively recently switched to Arch and am trying to improve my practices, in this case by actually reading what packages will be updated before just leisurely pressing `Y' (what are your habits?). However, when running `pacman -Syu', there is a long line of packages listed rather than in a column, which makes it hard to read. Is it possible to get the listing in a column to make it easier to read before updating? Cheers, Styx

6 6

Help needed
by t+linux＠elaboris.de 19 Feb '26

19 Feb '26

Dear Linux Experts, my name is Tanja Schaaf and I live in Frankfurt. My husband, Markus Schaaf (mschaaf), was sometimes posting emails to Archlinux-Group, but I think in the last few years he was not so active any more. Unfortunately, he passed away last year in November and I stuck with my zero knowledge about Linux - I hope somebody can help me. I apologize already for my missing knowledge, asking stupid questions and being confused. All computers in our home are running (or not) on Linux Manjaro. My major problem is laptop from Markus - I have a password, but the laptop is locked and I do not know how to unlock it. I get the message: "You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, or "exit" to continue bootup." It doesn't matter what I do, I get the next message: "Cannot open access to console, the root account is locked. see sulogin(8( man page for more details. Press enter to continue." After that the system is asking for password and after typing the pw it jumps back to: "You are in emergency mode..." and so on and so on.... I think, it is not needed to write how down I am, especially for the reason that all important info is on his laptop - like PgGP key for his importand emails, which I cannot open now as the key is missing. Would somebody have time to help me? Regards Tanja

5 5

The NVIDIA 590 driver notice
by Mark E. Mallett 17 Feb '26

17 Feb '26

Hi, There was a notice on arch-announce and on archlinux.org/news ( https://archlinux.org/news/nvidia-590-driver-drops-pascal-support-main-pack… ) that confuses me. "With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older" etc. I don't really know if that applies to me, given the brand/model labels and all. (some detail about my hardware is offered at the end of this message.) And even if it does, the notice is (to my dull mind) unclear. It says: 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. That would be bad and makes me hesitent to experiment. Part of what confuses me is this: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support I'm using the proprietary nvidia driver already, so what does that statement mean to me? (I'm not running nouveau or other) So I have questions - the one above ("does this mean me?") - the one about already using the proprietary driver - can I simply not upgrade the nvidia driver, keep using the installed one? - If the system breaks, what is my recourse? - Is "Install nvidia-580xx-dkms from the AUR" (as it says) appropriate for me? I know this sounds like a lot of foggy nonunderstanding, and I guess that's because that's what it is. The relevant system has a very old NVIDIA card. I haven't seen any reactions to this, maybe I'm the only one left ;) Possibly relevant stuff from hwinfo: 22: PCI 100.0: 0300 VGA compatible controller (VGA) [Created at pci.395] Unique ID: VCu0.4tATP2A+FnB Parent ID: 8otl.w6ofvOouCK2 SysFS ID: /devices/pci0000:00/0000:00:04.0/0000:01:00.0 SysFS BusID: 0000:01:00.0 Hardware Class: graphics card Model: "nVidia GM206 [GeForce GTX 960]" Vendor: pci 0x10de "nVidia Corporation" Device: pci 0x1401 "GM206 [GeForce GTX 960]" SubVendor: pci 0x1462 "Micro-Star International Co., Ltd. [MSI]" SubDevice: pci 0x3201 Revision: 0xa1 Driver: "nvidia" Driver Modules: "nvidia" Memory Range: 0xfd000000-0xfdffffff (rw,non-prefetchable) Memory Range: 0xd0000000-0xdfffffff (ro,non-prefetchable) Memory Range: 0xce000000-0xcfffffff (ro,non-prefetchable) I/O Ports: 0xcc00-0xcc7f (rw) Memory Range: 0x000c0000-0x000dffff (rw,non-prefetchable,disabled) IRQ: 27 (1392224 events) Module Alias: "pci:v000010DEd00001401sv00001462sd00003201bc03sc00i00" Driver Info #0: Driver Status: nouveau is not active Driver Activation Cmd: "modprobe nouveau" Driver Info #1: Driver Status: nvidia_drm is active Driver Activation Cmd: "modprobe nvidia_drm" Driver Info #2: Driver Status: nvidia is active Driver Activation Cmd: "modprobe nvidia" Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #20 (PCI bridge) Thanks for any attention. -mm- (long time no write)

10 15

Update orphan package mill
by Gonsolo 11 Feb '26

11 Feb '26

Hi! Mill in Arch is nearly three years old: https://archlinux.org/packages/extra/any/mill/ https://github.com/com-lihaoyi/mill/releases/tag/0.11.0 I have a MR for updating it: https://gitlab.archlinux.org/archlinux/packaging/packages/mill/-/merge_requ… But since it is orphaned it can't be updated. It also can't be moved to AUR. Is there really no way forward? Thanks -- Andreas

3 2

Re: KDE plasma login stalls with Wayland
by SET 10 Feb '26

10 Feb '26

Le jeudi 5 février 2026 20:00:28 heure normale d’Europe centrale sprungles.me a écrit : > If you are needing to get the maintainer, I figured out the culprit is the ddcutil package. It is reported here also: https://gitlab.archlinux.org/archlinux/packaging/packages/ddcutil/-/issues? show=eyJpaWQiOiI1IiwiZnVsbF9wYXRoIjoiYXJjaGxpbnV4L3BhY2thZ2luZy9wYWNrYWdlcy9kZGN1dGlsIiwiaWQiOjIyMzQ2NX0%3D Thank you for your reply.

1 1

Re: glibc 2.43 in testing - moving to stable repos affected
by Genes Lists 10 Feb '26

10 Feb '26

On Tue, 2026-02-10 at 11:45 +0100, Frederik Schwan wrote: > I've pushed glibc 2.43 to testing. Do not move packages linked > against 2.43 to extra or core until glibc itself moves around > Thursday/Friday. > Otherwise the package will probably break. > > Best regards, > Frederik Hi Frederik I wonder if the compile error below might be related to this update since it seems to have just started happening. May not be related of course. Either way, it would be great if someone can suggest a fix for this build error? test machine is updated using testing repos. i.e. binutils 2.46-1 gcc 15.2.1+r604+g0b99615a8aef-1 glibc 2.43+r5+g856c426a7534-1 python 3.14.2-2 Building libcamera gets macro conflicts between the definitions from glibc vs python. This could be happening because libcamera compiles with -std=c++17. What I see is that: /usr/include/features.h (glibc) vs /usr/include/python3.14/pyconfig.h (python) and features.h defines _POSIX_C_SOURCE values of - 200809L varies depending on _XOPEN_SOURCE - 202405L if _GNU_SOURCE is set On other hand, pyconfig.h fixes the value to 2008: /* Define to activate features from IEEE Stds 1003.1-2008 */ #define _POSIX_C_SOURCE 200809L which "suggests" that this is the value libcamera should also use maybe? Building libcamera started having these errors (similar ones for _XOPEN_SOURCE as well): /usr/include/python3.14/pyconfig.h:2007:9: error: ‘_POSIX_C_SOURCE’ redefined [-Werror] 2007 | #define _POSIX_C_SOURCE 200809L /usr/include/features.h:319:10: note: this is the location of the previous definition 319 | # define _POSIX_C_SOURCE 202405L Happens with both the current version (0.7.0) as well as git head of libcamera. thank you for any guidance gene

1 0