- Arch-general - lists.archlinux.org

Lost OTP authenticator
by whiteman808＠paraboletancza.org 08 Nov '25

08 Nov '25

I lost OTP authenticator and I'm no longer be able to log in to gitlab.archlinux.org. I tried to send mail to accountsupport(a)archlinux.org but I didn't get answer.

4 5

Re: Possible to script pacman -U to automate swap between dovecot 2.3/2.4, or 2.4/2.3?
by Pocket 07 Nov '25

07 Nov '25

On 11/7/25 3:20 PM, David C Rankin wrote: > On 11/6/25 5:01 PM, Pocket wrote: >> I use the btrfs filesystem, I create a subvolume for version 1 and >> install the base packages and the "old version" It is configured and >> boots and "runs" using systemd-nspawn. >> >> I then create a subvolume for version 2, install the base packages and >> the "old version" It is configured and boots and "runs" using >> systemd- nspawn. >> >> I then can use machinectl to run/start a "version" and then I can shut >> it down and run the other, ie >> machinectl start "version 1" >> machine login "version 1" >> >> when I am finished then >> >> machinectl start "version 2" >> machine login "version 2" >> >> systemd containers are your friend > > Thanks! > > That's something I've not looked into yet. I've avoided btrfs and > stayed on ext4 --- I also run opensuse and lived through the development > years when btrfs would regularly exhaust drive space leaving users > without a usable system. > > It's matured, but there are also distros now dropping it, so that has > been another ding against my trying it. The systemd container aspect > does as a huge capability to its arsenal. I'll have to read up. > ls /var/lib/machines/ DNS PiHole machinectl list MACHINE CLASS SERVICE OS VERSION ADDRESSES DNS container systemd-nspawn archarm - - PiHole container systemd-nspawn archarm - - - base packages are installed to DNS and PiHole. bind is installed into the DNS subvolume and pihole is installed into the PiHole subvolume. They are started at boot. They are separate from the "Root" subvolume that the system boots to. This keeps all the "services" separate from the boot system and I don't have the bind and pihole packages installed/mixed into the "root system". I am currently creating a subvolume for nginx to provide web service to the local network. btrfs subvolume list /mnt ID 256 gen 9111 top level 5 path Root ID 257 gen 9099 top level 5 path Home ID 258 gen 8452 top level 5 path Pkgs ID 259 gen 263 top level 256 path Root/var/lib/portables ID 260 gen 9100 top level 256 path Root/var/lib/machines ID 261 gen 9111 top level 5 path PiHole ID 262 gen 263 top level 261 path PiHole/var/lib/portables ID 263 gen 1005 top level 261 path PiHole/var/lib/machines ID 264 gen 9110 top level 5 path DNS ID 265 gen 1005 top level 264 path DNS/var/lib/portables ID 266 gen 1005 top level 264 path DNS/var/lib/machines Overall: Device size: 27.31GiB Device allocated: 4.57GiB Device unallocated: 22.74GiB Device missing: 0.00B Device slack: 0.00B Used: 2.35GiB Free (estimated): 24.65GiB (min: 13.28GiB) Free (statfs, df): 24.65GiB Data ratio: 1.00 Metadata ratio: 2.00 Global reserve: 7.53MiB (used: 0.00B) Multiple profiles: no Data,single: Size:4.01GiB, Used:2.10GiB (52.32%) /dev/mmcblk0p2 4.01GiB Metadata,DUP: Size:256.00MiB, Used:129.83MiB (50.71%) /dev/mmcblk0p2 512.00MiB System,DUP: Size:32.00MiB, Used:16.00KiB (0.05%) /dev/mmcblk0p2 64.00MiB Unallocated: /dev/mmcblk0p2 22.74GiB I have compress=lzo turned on all volumes -- Hindi madali ang maging ako

1 0

Possible to script pacman -U to automate swap between dovecot 2.3/2.4, or 2.4/2.3?
by David C Rankin 06 Nov '25

06 Nov '25

Arch pacman gurus, I'd thought I would automate the swap between dovecot versions for testing between dovecot23 and dovecot with pacman -U --noconfirm, but since pacman considers dovecot23 and dovecot to be in conflict, the upgrade fails with: :: dovecot-2.4.2-3 and dovecot23-2.3.21.1-3 are in conflict. Remove dovecot23? [y/N] error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: dovecot-2.4.2-3 and dovecot23-2.3.21.1-3 are in conflict Job for dovecot.service failed because the control process exited with error code. See "systemctl status dovecot.service" and "journalctl -xeu dovecot.service" for details. Manually swapping is easy enough, it just takes a little more time to do the service stop, pacman upgrade, copy the changed configs and restart the service. Is there any way to script around the dovecot23/dovecot conflict issue? Moreover, since dovecot23 and dovecot are single packages, why the conflict? Seems a warning about config breakage would be appropriate, but the user should be able to swap between them without triggering a conflict. -- David C. Rankin, J.D.,P.E.

3 3

dovecot 2.4
by Friedrich Strohmaier 04 Nov '25

04 Nov '25

Hi @all, does anybody know, why dovecot 2.4 didn't make it into extra until now? Couldn't find any info about it. best Friedrich

8 15

Fwd: News draft: dovecot >= 2.4 requires manual intervention
by David C Rankin 31 Oct '25

31 Oct '25

Thank you Thore, Preserving 2.3, while maintained, to provide replication functionality is much appreciated. Smart move. Draft of announcement seems fine. (posted to arch-general as no reply capability to arch-dev-public) -------- Forwarded Message -------- Subject: News draft: dovecot >= 2.4 requires manual intervention Date: Wed, 29 Oct 2025 19:54:34 +0100 From: Thore Bödecker <foxxx0(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Hi folks, the upstream dovecot 2.4 branch comes with handful of breaking changes, mostly concerning configuration semantics and syntax. For this, upstream provides a migration guide [1]. We've kept dovecot 2.4.1 in [testing] for quite some time and it received a decent number of signoffs. There was already a bit of chatter on arch-general regarding the availability of a dovecot 2.4 package in [extra]. While slightly unintentional, I've built and pushed todays upstream release version 2.4.2 to [extra]. However, there is a feature disparity: the 2.4 branch no longer supports replication. My own setup relies on that particular feature and I've grown quite fond of it, so I'm a bit sad to see it going away. As per upstreams EOL announcement [2], the 2.3 branch is supposedly going to receive critical secrity fixes, which I considered "maintained enough" to warrant packaging it separately until upstream fully drops it. The following packages are now available in [extra]: - dovecot23 - pigeonhole23 - dovecot23-fts-elastic - dovecot23-fts-xapian Where applicable, they are configured with the necessary conflicts/provides. The most recent dovecot-2.4.2-3 build also contains the following dovecot.install notice: > ==> Dovecot 2.4 is incompatible with older configurations and requires manual intervention. > ==> Refer to 'https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html' for upgrading instructions. > ==> Alternatively, there is a dovecot23 (and pigeonhole23) package available. Given the fact that any dovecot 2.4 binary *will not* start with a <= 2.3 configuration file, it seems reasonable for us to publish an announcement to make users aware of this situation while also informing them about the alternate 2.3 packages we provide. News draft below. ----8<---- # 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: [Upgrading Dovecot CE from 2.3 to 2.4](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 [receive critical security fixes](https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/threa… from upstream until stated otherwise. ---->8---- [1] https://doc.dovecot.org/latest/installation/upgrade/2.3-to-2.4.html [2] https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/3P45L… Cheers -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6 -- David C. Rankin, J.D.,P.E.

1 0

[arch-general] System terribly slow
by riveravaldez 27 Oct '25

27 Oct '25

Hi, I'm looking for some advice trying to pinpoint why or where my system has becoming almost unusable slow. Searching the web I've found some hints but nothing precise enough. Maybe it's a failing HDD, but I'm first posting what I have until now in the hope someone can give some advice. Superficial symptoms are a general slowness. I'm using just IceWM and `startx` to initialize the GUI, and even logging into my account previous to that takes almost a minute to get done. Then any application I launch takes minutes to just start (from IceWM to firefox, from qtox to pcmanfm or geany, etc.). Even navigate the folders tree with pcmanfm takes 10 or more seconds just to show any folder content... Hope some of this helps: $ sudo journalctl -b -exp3 -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 19:50:29 -03. -- dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Asking for cache data failed dic 03 00:48:43 arch kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through dic 03 00:50:39 arch libvirtd[592]: cannot open directory '/home/dell/Software/VMs/TrisquelMini8': No existe el fichero o el directorio dic 03 00:50:39 arch libvirtd[592]: error interno: Falló al iniciar automáticamente el grupo de almacenamiento 'TrisquelMini8': cannot open directory '/home/dell/Softwar> dic 03 00:50:41 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:50:57 arch libvirtd[592]: No se encontró 'dmidecode' en ruta: No existe el fichero o el directorio dic 03 00:56:40 arch systemd[1]: Failed to start Disk Manager. Subject: A start job for unit udisks2.service has failed Defined-By: systemd Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel A start job for unit udisks2.service has finished with a failure. The job identifier is 1072 and the job result is failed. $ systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. $ systemd-analyze Startup finished in 11.038s (kernel) + 1min 31.352s (userspace) = 1min 42.391s graphical.target reached after 1min 31.352s in userspace $ systemd-analyze blame 37.946s polkit.service 29.248s dev-sda1.device 28.827s systemd-tmpfiles-clean.service 24.692s udisks2.service 15.936s systemd-journal-flush.service 14.228s systemd-hwdb-update.service 13.930s ldconfig.service 13.502s upower.service 12.881s ufw.service 8.830s user(a)1000.service 7.556s systemd-tmpfiles-setup-dev.service 7.280s avahi-daemon.service 7.275s bluetooth.service 7.262s iwd.service 6.067s systemd-logind.service 6.058s systemd-machined.service 5.825s systemd-tmpfiles-setup.service 5.123s systemd-sysusers.service 4.569s systemd-udevd.service 4.511s systemd-resolved.service 4.281s systemd-networkd.service 3.724s systemd-journal-catalog-update.service 3.415s systemd-fsck@dev-disk-by\x2duuid-1d72b82c\x2d9c58\x2d4f57\x2d97a3\x2de29ff35a5632.service 2.959s systemd-modules-load.service 2.557s lm_sensors.service 2.503s systemd-random-seed.service 2.389s systemd-backlight@backlight:acpi_video0.service 1.983s dev-disk-by\x2duuid-84c91978\x2da09c\x2d4087\x2db60d\x2d86730d142f63.swap 1.967s systemd-backlight@leds:dell::kbd_backlight.service 1.563s systemd-timesyncd.service 1.457s systemd-update-utmp.service 1.287s systemd-udev-trigger.service 1.278s systemd-rfkill.service 1.219s alsa-restore.service 1.164s systemd-sysctl.service (...) $ systemctl status polkit.service ● polkit.service - Authorization Manager Loaded: loaded (/usr/lib/systemd/system/polkit.service; static) Active: active (running) since Fri 2021-12-03 00:50:28 -03; 19h ago Docs: man:polkit(8) Main PID: 613 (polkitd) Tasks: 12 (limit: 6993) Memory: 18.9M CPU: 1.032s CGroup: /system.slice/polkit.service └─613 /usr/lib/polkit-1/polkitd --no-debug dic 03 00:49:50 arch systemd[1]: Starting Authorization Manager... dic 03 00:50:05 arch polkitd[613]: Started polkitd version 0.120 dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /etc/polkit-1/rules.d dic 03 00:50:26 arch polkitd[613]: Loading rules from directory /usr/share/polkit-1/rules.d dic 03 00:50:28 arch polkitd[613]: Finished loading, compiling and executing 6 rules dic 03 00:50:28 arch systemd[1]: Started Authorization Manager. dic 03 00:50:28 arch polkitd[613]: Acquired the name org.freedesktop.PolicyKit1 on the system bus $ systemctl status dev-sda1.device ● dev-sda1.device - Hitachi_HTS545025B9A300 ROOT Follows: unit currently follows state of sys-devices-pci0000:00-0000:00:1f.2-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device Loaded: loaded Active: active (plugged) since Fri 2021-12-03 00:49:12 -03; 19h ago Device: /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1 Notice: journal has been rotated since unit was started, output may be incomplete. $ systemctl status systemd-tmpfiles-clean.service ○ systemd-tmpfiles-clean.service - Cleanup of Temporary Directories Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.service; static) Active: inactive (dead) since Fri 2021-12-03 01:03:52 -03; 19h ago TriggeredBy: ● systemd-tmpfiles-clean.timer Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 1473 ExecStart=systemd-tmpfiles --clean (code=exited, status=0/SUCCESS) Main PID: 1473 (code=exited, status=0/SUCCESS) CPU: 185ms dic 03 01:03:23 arch systemd[1]: Starting Cleanup of Temporary Directories... dic 03 01:03:52 arch systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. dic 03 01:03:52 arch systemd[1]: Finished Cleanup of Temporary Directories. $ systemctl status udisks2.service ● udisks2.service - Disk Manager Loaded: loaded (/usr/lib/systemd/system/udisks2.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2021-12-03 00:59:51 -03; 19h ago Docs: man:udisks(8) Main PID: 1129 (udisksd) Tasks: 5 (limit: 6993) Memory: 3.2M CPU: 23.045s CGroup: /system.slice/udisks2.service └─1129 /usr/lib/udisks2/udisksd dic 03 00:59:26 arch systemd[1]: Starting Disk Manager... dic 03 00:59:26 arch udisksd[1129]: udisks daemon version 2.9.4 starting dic 03 00:59:51 arch systemd[1]: Started Disk Manager. dic 03 00:59:54 arch udisksd[1129]: Acquired the name org.freedesktop.UDisks2 on the system message bus $ systemctl status systemd-journal-flush.service ● systemd-journal-flush.service - Flush Journal to Persistent Storage Loaded: loaded (/usr/lib/systemd/system/systemd-journal-flush.service; static) Active: active (exited) since Fri 2021-12-03 00:48:59 -03; 19h ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Process: 283 ExecStart=journalctl --flush (code=exited, status=0/SUCCESS) Main PID: 283 (code=exited, status=0/SUCCESS) CPU: 15ms dic 03 00:48:43 arch systemd[1]: Starting Flush Journal to Persistent Storage... dic 03 00:48:59 arch systemd[1]: Finished Flush Journal to Persistent Storage. $ systemctl status systemd-hwdb-update.service ● systemd-hwdb-update.service - Rebuild Hardware Database Loaded: loaded (/usr/lib/systemd/system/systemd-hwdb-update.service; static) Active: active (exited) since Fri 2021-12-03 00:48:57 -03; 19h ago Docs: man:hwdb(7) man:systemd-hwdb(8) Process: 279 ExecStart=systemd-hwdb update (code=exited, status=0/SUCCESS) Main PID: 279 (code=exited, status=0/SUCCESS) CPU: 1.746s dic 03 00:48:57 arch systemd[1]: Finished Rebuild Hardware Database. $ journalctl -b -u systemd-journald.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:49:18 -03. -- dic 03 00:48:43 arch systemd-journald[271]: Journal started dic 03 00:48:43 arch systemd-journald[271]: Runtime Journal (/run/log/journal/431f639f382e4bad8a43628868f2fc6c) is 8.0M, max 292.4M, 284.4M free. dic 03 00:48:44 arch systemd-journald[271]: Time spent on flushing to /var/log/journal/431f639f382e4bad8a43628868f2fc6c is 7.561088s for 798 entries. dic 03 00:48:44 arch systemd-journald[271]: System Journal (/var/log/journal/431f639f382e4bad8a43628868f2fc6c) is 16.0M, max 2.4G, 2.4G free. $ journalctl -b -u systemd-fsck@dev-disk-by\\x2duuid-1d72b82c\\x2d9c58\\x2d4f57\\x2d97a3\\x2de29ff35a5632.service -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Fri 2021-12-03 20:52:36 -03. -- dic 03 00:49:18 arch systemd[1]: Starting File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632... dic 03 00:49:21 arch systemd-fsck[485]: HOME: limpio, 208781/13107200 ficheros, 37165716/52398592 bloques dic 03 00:49:21 arch systemd[1]: Finished File System Check on /dev/disk/by-uuid/1d72b82c-9c58-4f57-97a3-e29ff35a5632. $ journalctl --verify PASS: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/user-1000.journal 3b84d8: Data object's entry array not sorted File corruption detected at /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal:915878 (of 16777216 bytes, 56%). FAIL: /var/log/journal/431f639f382e4bad8a43628868f2fc6c/system.journal (Mensaje erróneo) $ journalctl --disk-usage Archived and active journals take up 24.0M in the file system. Maybe it's pertinent to mention that I've just cleaned up /var/log/journal to rule out storage issues. Any help will be most welcome. Thanks a lot in advance.

6 8

Btrfs
by Pocket 26 Oct '25

26 Oct '25

I am currently in process of moving fomr ext4 filesystem to btrfs. I have the following on a raspberry pi server The fdisk -l /dev/mmcblk0 /dev/mmcblk0p1 2048 1050623 1048576 512M c W95 FAT32 (LBA) /dev/mmcblk0p2 1050624 58327039 57276416 27.3G 83 Linux /dev/mmcblk0p3 58327040 62521343 4194304 2G 82 Linux swap / Solaris partition 1 is vfat partition 2 is btrfs This will go on a SSD nvme drive after the test phase is complete. It is currently booting and functioning is good. BTRFS top level: Container subvolume Home subvolume Root subvolume Snapshot DNS-2025-10-23 PiHole-2025-10-26 Snapshot volumes are from Container DNS-2025-10-23 has base and bind installed PiHole-2025-10-26 has base and pi hole installed I mount DNS-2025-10-23 to /var/lib/machines/DNS and I mount PiHole-2025-10-26 /var/lib/machines/PiHole They are mounted in /etc/fstab and I start them on boot machinectl enable DNS machinectl enable PiHole I dedup them by mounting the top level to /mnt and running duperemove -r -d /mnt I am planning to change the layout so it would be like this Root subvolume Home subvolume DNS subvolume PiHole subvolume then dedup? Also what are the issues when updating (pacman -Syu) on each subvolume then dedup. Is there anything I need to watch out for? -- Hindi madali ang maging ako

1 0

Fwd: Remove GTK2 from the official repositories
by David C Rankin 26 Oct '25

26 Oct '25

Directed to general since not allowed to post to dev: I still use Gtk2, and if it isn't a burden and isn't failing to build, I would like to see it kept. I use hexchat, nitrogen and parcellite along with xdialog. Yes we can always to to AUR, but an official package is always preferrable. (just a reqsponse to the request for opinions) -------- Forwarded Message -------- Subject: Remove GTK2 from the official repositories Date: Fri, 24 Oct 2025 00:12:39 +0200 From: Balló György <bgyorgy(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Hi all, I think we've reached the point when we can remove the very old GTK2 package from the official repositories. I recently dropped the GTK2 version of LXDE, and there are only a few applications left that still depend on GTK2: - alltray - amsynth - bless - calf - eq10q - gimp-nufraw - gkrellm - gpsim - gtk2fontsel - gtk-chtheme - hexchat - hexter - leafpad - mono-tools - nitrogen - nspluginwrapper - osdlyrics - parcellite - pidgin - sbxkb - trayer - xboard - xdialog - xlockmore Most of these have no active development a long time ago. If no one has objections, I'll drop these packages to AUR in the next days if it's not possible to build them without GTK2. Any opinion? -- György Balló Package Maintainer -- David C. Rankin, J.D.,P.E.

6 7

systemd-networkd relies on all mountable mountpoints?
by Bjoern Franke 25 Oct '25

25 Oct '25

Hi, after an uptime of ~200 days I rebootet my NUC which had issues bringing up systemd-networkd afterwards. systemd-networkd.service: Failed to set up mount namespacing: /home: No such device Excerpt from fstab: UUID="7f313178-70b4-4a93-8e86-9c3d19e2f2b3" /mnt xfs noauto,noatime 0 0 /mnt/home /home none bind,x-systemd.automount 0 0 /mnt is mounted after unlocking it manually as it is on a luks device. Months before that setup had no issues, so does systemd try now to create namespace for all mountpoints even when the devices don't exist? Regards Bjoern

1 0

btrfs send/receive between same UUID filesystems
by Alipour Alipour 25 Oct '25

25 Oct '25

Does having the same UUID for btrfs filesystem on local and remote machines cause problems when using btrfs send/receive between them (piped through SSH)?

2 1