March 2022 - Arch-general - lists.archlinux.org

[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

Re: [arch-general] [arch-dev-public] RFC: Forbid dummy packages from AUR
by Óscar García Amor 04 Apr '22

04 Apr '22

El jue, 24 mar 2022 a las 8:14, Allan McRae via arch-dev-public (<arch-dev-public(a)lists.archlinux.org>) escribió: > > On 24/3/22 11:07, Brett Cornwall via arch-dev-public wrote: > > Summary: Reject AUR packages that fulfill package dependencies without > > providing the files/binaries of the package in question. But why? I don't quite understand why this should be banned. IMHO I think it is something very interesting and also, as described in the RFC, has a clear and justified use. It would be different if there was a way to tell Pacman by configuration to assume that these dependencies are covered, but as far as I know it is not possible. And while it is true that you can pass the `--assume-installed` option to it, but that must always be done at run time and if you have a high number of dummy dependencies it can be messy. Greetings -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

3 3

[arch-general] Vim errors: Can't allocate color Orange, Can't allocate color SlateBlue, etc...
by David C. Rankin 01 Apr '22

01 Apr '22

All, A recent change to how vim is being packages has resulted in errors when opening files with C syntax highlight on my system. The error I receive is, e.g.: Error detected while processing /etc/vimrc[38]../usr/share/vim/vim82/syntax/syntax.vim[19]../usr/share/vim/vim82/syntax/synload.vim[21]../usr/share/vim/vim82/syntax/syncolor.vim: line 53: E254: Cannot allocate color SlateBlue E254: Cannot allocate color SlateBlue I get the same error with different colors depending on what different highlight elements are present in any file. Was the vim package changed to put this stuff in another package? Odd error -- David C. Rankin, J.D.,P.E.

2 1

[arch-general] Status of gnupg - time to update
by Genes Lists 28 Mar '22

28 Mar '22

Current Arch version is LTS 2.2.32 [1]. As per the announcement [2] 2.3.4 is considered the current stable version: "Version 2.3 is the current stable version with a lot of new features compared to 2.2." I have hazy recollections from some time back that there was a reason for delaying updating to current version - don't recall what exactly. It's been a while now, and there are some nice features in 2.3.4 [3] Also, our libgcrypt is up to date ( ignoring today's release of 1.10.1) Any remaining reason not to update gnupg to current version? thanks gene [1] Aside - LTS 2.3.34 was released recently in early Feb of this year. [2] https://lists.gnupg.org/pipermail/gnupg-announce/2022q1/000470.html [3] https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000458.html

1 0

[arch-general] Pacman Search on Package Names Only?
by 2QdxY4RzWzUUiLuE＠potatochowder.com 25 Mar '22

25 Mar '22

Greetings, Is there a way to limit Pacman to search package names only, rather than package names and descriptions? https://wiki.archlinux.org/title/Pacman#Querying_package_databases says that you can do that by tweaking the search term, but that doesn't really work. As a [horrible] workaround, I could write my own script atop pacman -Qq, but, well, yuck. :-) Thanks, Dan

2 2

[arch-general] Output of make -s kernelrelease has a "" suffix
by u34＠net9.ga 23 Mar '22

23 Mar '22

With 5.17.arch1, the output of make -s kernelrelease ends with "". That is, having a double \" character at the end of the string. It was not like that in prevoius versions. Is that expected? -- u34

2 2

[arch-general] Atheros AR9462 - kernel upgrade warning
by Danila Kiver 21 Mar '22

21 Mar '22

A little heads up for Atheros AR9462 owners. It seems that the latest kernel renders AR9462 (and maybe some other cards using ath9k module) WiFi close to unusable due to network connection being dropped continuously. The problem seems to be not Arch-specific; there is an upstream report for this: https://bugzilla.kernel.org/show_bug.cgi?id=215698 Upgrade with caution; keep old kernel package cached. Rolling back to linux-5.16.3 worked well for me. Regards, Danila Kiver.

2 2

[arch-general] FS#73728 - Installing mandoc uninstalls certain doc-only packages (dependency issue)
by Kelvin M. Klann 08 Mar '22

08 Mar '22

Greetings. Some packages are currently affected by Arch bug FS#73728[1]. It seems that not all of the relevant package maintainers were added to the bug report, so I figured that I'd send the bug status to a mailing list and copy whoever is missing. I'm not sure if this is relevant to arch-dev-public, so I'm sending it to arch-general. Apologies if it's not the correct list. Here's a partial quoting of the issue[1]: > Both man-db and mandoc provide "man" and also conflict with each other. > > And there are documentation-only packages which depend on "man-db" rather > than on just "man". > > This prevents installing both mandoc (instead of man-db) and these > documentation-only packages at the same time. > > Note: "man-db" provides only man(1) and related tools; the "default" man > pages themselves are provided by "man-pages". Suggested fix: Change all of the following packages to depend on "man" rather than on "man-db": * man-pages-zh_cn * man-pages-zh_tw * man2html * xorg-docs Note: The following packages were already fixed[2][3]: * bat-extras * man-pages-cs * man-pages-da * man-pages-de * man-pages-es * man-pages-fr * man-pages-hu * man-pages-it * man-pages-mk * man-pages-nl * man-pages-pl * man-pages-pt_br * man-pages-ro Note2: In the case of man2html, it does not call man(1); you have to call it yourself and pass the output to man2html. From man2html(1): > Typical Usage: > > man2html[-options] < infile > outfile > > man topic | man2html [-options] > outfile I have tested it with both man-db and mandoc: $ yes | sudo pacman -Sdd man-db >/dev/null 2>&1 $ man /usr/share/man/man1/tr.1.gz | man2html >tr_mandb.1.html $ yes | sudo pacman -Sdd mandoc >/dev/null 2>&1 $ man /usr/share/man/man1/tr.1.gz | man2html >tr_mandoc.1.html The main difference that I noticed was that with man-db, everything is put inside a pre tag, while with mandoc it uses h2, b and pre tags for each section. So the output looks different, but at least the main content is present on both. Package versions: * coreutils 9.0-2 * man-db 2.10.1-1 * mandoc 1.14.6-1 Cheers, Kelvin [1] https://bugs.archlinux.org/task/73728 [2] https://github.com/archlinux/svntogit-community/commit/c4d5698c9f031547039a… [3] https://github.com/archlinux/svntogit-community/commit/c79b07ccfa1389d58bb6…

1 0

[arch-general] Use Grub with Preloader
by Giovanni Santini 04 Mar '22

04 Mar '22

Hi all, I was reinstalling Arch after an unlucky SDD wipe due to warranty. I reinstalled Arch and then proceeded to use Secure Boot via Preloader. I followed the steps at: https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secu… But I got an error from Grub saying: *error: verification requested but nobody cares* I decided to re-create the Grub binary with the TPM module via *grub-install --target=x86_64-efi --efi-directory=ESP_DIR --modules="tpm" --bootloader-id=BOOTLOADER* But that didn't do the trick. Do I have to do something peculiar in order to make Grub to work? Bests, -- Giovanni Santini Telegram: @ItachiSan Github: https://github.com/ItachiSan LinkedIn: https://www.linkedin.com/in/giovanni-santini/ Facebook: https://fb.me/giovanni.santini

2 4