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

PATCH: Plymouth localisation is broken on Arch release 26.134.222
by Ava Glass 16 Jul '26

16 Jul '26

Hey all, I sent this patch to the Plymouth package maintainer a short while ago however it doesn't appear to have been seen and it fixes an important issue to me with Plymouth localisation. I'm having some account issues with my ArchLinux GitLab account otherwise I would create a MR on there with this patch, so I figured this would be the best next place? All the best, Ava -------- Forwarded Message -------- Subject: PATCH: Plymouth localisation is broken on Arch release 26.134.222 Hi, The attached patch resolves the following issue for plymouth where the localisation defined in /etc/vconsole.conf is not applied to plymouth. See: https://gitlab.freedesktop.org/plymouth/plymouth/-/work_items/337 This patch is for the Arch Linux plymouth package adding the necessary lines to plymouth.initcpio_install to resolve the issue. Best, Ava Glass

1 0

When will be the next ArchConf?
by hello＠ismailarilik.com 14 Jul '26

14 Jul '26

Hey there. The last (and the first as I know) ArchConf was in 2020. Is there any plan for the next one? I don't know how much a conference takes or whether Arch Linux has enough financial power for it or not but I think the community is big enough to handle a small conference. BTW I am volunteer for all kind of tasks for an event.

1 0

How does Arch handle boot if / is RAID1 and in resync - the box appeared hard-locked?
by David C Rankin 12 Jul '26

12 Jul '26

All, Devs, This affects a normal boot and a boot from the Arch ISO. I had a odd occurrence today where Arch boot failed and for all practical purposes it appeared there was a serious hardware failure leading to some type of panic/freeze but there was no outward indication or any error displayed. The Arch ISO behaved the same way. There was apparently a hard, unexplained, shutdown at 11:09:00 CST on this server. The / filesystem is RAID1 (mdadm) on an ext4 filesystem, the bootloader written to each individual disk. On reboot, the boot proceeded normally through the "Recovering journal", then the "root clean ......." message, and then the small underline blinking cursor below "root clean" showed activity for about 15 seconds, then froze. After several minutes, I shut the server down. I downloaded a fresh 7/01 Arch install iso, dd'ed it to a USB and booted from it choosing the x86_64 install/maintenance entry. The init image loaded fine, but then the loading of Arch froze, in the same manner, appearing like a hardware freeze. Waiting several minutes, with nothing but rising CPU temp and fan noise, I shut down and booted back into the install ISO and ran memtest. An hour later with no errors and 60% of Pass 1 done, it was obviously not a memory problem. Reboot the install ISO and run the hardware check, all drives report good. Reboot the install ISO again and try the Install/Maintenance option and this time it booted into Arch, there was a flashed message about RAID running in degraded mode. A quick check of /proc/mdstat showed / in resync ~50% complete, all other arrays working fine. Another 90 seconds or so and the resync completed normally. Then a reboot to the system drives worked normally. So from what I can deduce there was a momentary power problem (UPS has been flawless, but apparently not foolproof). The end of the journal at 11:09:00 was unremarkable, it just ended. So my best guess is the / array was left in an inconsistent state requiring resync, otherwise all arrays were fine. The question I have is how does the Arch boot process handle this? Or is this just one of the quirky corner cases that there isn't any good way to handle? Had there been an indication that the / filesystem couldn't be loaded -- that would have made sense and clued me into the fact that / needed investigation. However, apparently when mdadm is conducting a resync, there is no message generated to inform the user to wait, and no timeout whatsoever. The box for all purposes just appears frozen. Adding to the confusion was the Arch ISO which showed the same behavior (in hindsight it makes sense it would). The ISO automatically assembles the mdadm arrays, which left it in the same state waiting on / with no error and no timeout. This may just be an odd corner-case, where the both disks in the array are good, not in degraded mode, but in resync. The boot process does not seem to handle that in any way except waiting for / to become available. I don't have "systemd" in the /etc/mkinitcpio.conf HOOKS array, so this may just apply to a busybox init if that makes any difference (I don't know what the ISO uses). Should this be handled somehow so a warning is generated? Is that something Arch can do or will it take upstream mdadm changes or the like? Sorry for the length, it got longer than anticipated, but I wanted to make sure I included enough so the scenario made sense. -- David C. Rankin, J.D.,P.E.

3 6

PKGBUILD: adwaita-icon-theme-legacy
by Pocket 01 Jul '26

01 Jul '26

Patch is wrong name? diff --git a/PKGBUILD b/PKGBUILD index 483d1b9..04353f5 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -30,7 +30,7 @@ prepare() { # Use a unique licenses directory # https://gitlab.gnome.org/GNOME/adwaita-icon-theme-legacy/-/merge_requests/1 - git apply -3 ../adwaita-icon-theme-legacy-unique-license-directory.patch + git apply -3 ../0001-Use-a-unique-licenses-directory.patch } build() { -- Hindi madali ang maging ako

1 0