January 2024 - 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

the archlinux torrent
by Jude DaShiell 03 Jul '24

03 Jul '24

Having downloaded the torrent and burned the iso to a dvd I verified the torrent using sha256sum but apparently that wasn't enough since the installation broke part of the way through which means I ought to have used the gpg verification that is available online. What is done with those asc files to verify a download? I used lftp with no options on the command line and maybe that was also a mistake on my part. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

3 18

Bring ARM into the fold?
by Christer Solskogen 02 Mar '24

02 Mar '24

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

3 2

Re: Migration from LXD to Incus
by Bernd Rinn 13 Feb '24

13 Feb '24

Hello, The issue with using the lxd-to-incus migration program is that it requires the lxd server to run in order to work. If I install incus via pacman and then try to migrate, I get: # lxd-to-incus => Looking for source server ==> Detected: manual installation => Looking for target server Error: No target server could be found This message is expected, because the target server (lxd) was uninstalled by pacman during the installation of incus. In comparison, on a Debian box, 'apt-get install incus' installs Incus in parallel to lxd and the subsequent migration program works fine. Best, > Hello, > > I am yet to migrate to incus, however the lxd-to-incus tool is provided > by the incus package [1], and thus should still work as it seems to > migrate itself (lxd is just a frontend after all). > > Let incus replace lxd, run the tool, and it should work just fine. If > not, post the error and the log here so that you can be helped further. > > > What the proper way of migrating from LXD to Incus under Archlinux? > > Seen as incus is relatively new, there is no wiki article on it, and > thus, there is no "proper" way currently, but in general if the > solution provided by upstream works, why change it? > > It goes without saying but you might want to backup before you attempt > this. > > Take care,

4 6

[arch-general][OT] vagrant + ubuntu 20.04 based docker image
by Javier 02 Feb '24

02 Feb '24

Hello ! At work I need to use an ubuntu 20.04 based docker image built by our org, and we use vagrant to easy the way to load and start the image. I'm not able to do "vagrant up", since it seems the host can't connect to the container (guest): > INFO global: Vagrant version: 2.4.1 > INFO global: Ruby version: 3.0.6 > INFO global: RubyGems version: 3.3.25 > INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/opt/vagrant/embedded" > INFO global: VAGRANT_EXECUTABLE="/opt/vagrant/embedded/gems/gems/vagrant-2.4.1/bin/vagrant" > INFO global: VAGRANT_INSTALLER_ENV="1" > INFO global: VAGRANT_INSTALLER_VERSION="2" > INFO global: VAGRANT_LOG="debug" > ... > DEBUG ssh: Checking key permissions: /home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519 > DEBUG ssh: Checking key permissions: /home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa > INFO ssh: Attempting SSH connection... > INFO ssh: Attempting to connect to SSH... > INFO ssh: - Host: 127.0.0.1 > INFO ssh: - Port: 2222 > INFO ssh: - Username: a2sdk > INFO ssh: - Password? false > INFO ssh: - Key Path: ["/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519", "/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa"] > DEBUG ssh: - connect_opts: {:auth_methods=>["none", "hostbased", "publickey"], :config=>false, :forward_agent=>true, :send_env=>false, :keys_only=>true, :verify_host_key=>:never, :password=>nil, :port=>"2222", :timeout=>15, :user_known_hosts_file=>[], :verbose=>:debug, :logger=>#<Logger:0x000070e2913f9dc0 @level=0, @progname=nil, @default_formatter=#<Logger::Formatter:0x000070e2913f9d20 @datetime_format=nil>, @formatter=nil, @logdev=#<Logger::LogDevice:0x000070e2913f9c80 @shift_period_suffix=nil, @shift_size=nil, @shift_age=nil, @filename=nil, @dev=#<StringIO:0x000070e2913f9e38>, @binmode=false, @mon_data=#<Monitor:0x000070e2913f9c30>, @mon_data_owner_object_id=14600>>, :keys=>["/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.ed25519", "/home/vasqueja/.vagrant.d/insecure_private_keys/vagrant.key.rsa"], :remote_user=>"a2sdk", :keepalive=>true, :keepalive_interval=>5} > DEBUG ssh: == Net-SSH connection debug-level log START == > DEBUG ssh: D, [2024-01-26T23:11:19.799621 #24466] DEBUG -- net.ssh.transport.session[391c]: establishing connection to 127.0.0.1:2222 > D, [2024-01-26T23:11:19.799907 #24466] DEBUG -- net.ssh.transport.session[391c]: connection established > I, [2024-01-26T23:11:19.799980 #24466] INFO -- net.ssh.transport.server_version[3930]: negotiating protocol version > D, [2024-01-26T23:11:19.800002 #24466] DEBUG -- net.ssh.transport.server_version[3930]: local is `SSH-2.0-Ruby/Net::SSH_7.2.1 x86_64-linux' > D, [2024-01-26T23:11:19.810429 #24466] DEBUG -- net.ssh.transport.server_version[3930]: remote is `SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.9' > I, [2024-01-26T23:11:19.810692 #24466] INFO -- net.ssh.transport.algorithms[3944]: sending KEXINIT > D, [2024-01-26T23:11:19.810886 #24466] DEBUG -- socket[3958]: queueing packet nr 0 type 20 len 852 > D, [2024-01-26T23:11:19.810953 #24466] DEBUG -- socket[3958]: sent 856 bytes > D, [2024-01-26T23:11:19.811421 #24466] DEBUG -- socket[3958]: read 1056 bytes > D, [2024-01-26T23:11:19.811496 #24466] DEBUG -- socket[3958]: received packet nr 0 type 20 len 1052 > I, [2024-01-26T23:11:19.811532 #24466] INFO -- net.ssh.transport.algorithms[3944]: got KEXINIT from server > I, [2024-01-26T23:11:19.811623 #24466] INFO -- net.ssh.transport.algorithms[3944]: negotiating algorithms > D, [2024-01-26T23:11:19.811712 #24466] DEBUG -- net.ssh.transport.algorithms[3944]: negotiated: >... > * kex: ecdh-sha2-nistp521 > * host_key: ssh-ed25519 > * encryption_server: aes256-ctr > * encryption_client: aes256-ctr > * hmac_client: hmac-sha2-512-etm(a)openssh.com > * hmac_server: hmac-sha2-512-etm(a)openssh.com > * compression_client: none > * compression_server: none > * language_client: > * language_server: > D, [2024-01-26T23:11:19.811733 #24466] DEBUG -- net.ssh.transport.algorithms[3944]: exchanging keys > D, [2024-01-26T23:11:19.812318 #24466] DEBUG -- socket[3958]: queueing packet nr 1 type 30 len 148 > D, [2024-01-26T23:11:19.812375 #24466] DEBUG -- socket[3958]: sent 152 bytes > D, [2024-01-26T23:11:19.816223 #24466] DEBUG -- socket[3958]: read 312 bytes > D, [2024-01-26T23:11:19.816293 #24466] DEBUG -- socket[3958]: received packet nr 1 type 31 len 292 > D, [2024-01-26T23:11:19.818291 #24466] DEBUG -- socket[3958]: queueing packet nr 2 type 21 len 20 > D, [2024-01-26T23:11:19.818346 #24466] DEBUG -- socket[3958]: sent 24 bytes > D, [2024-01-26T23:11:19.818401 #24466] DEBUG -- socket[3958]: received packet nr 2 type 21 len 12 > D, [2024-01-26T23:11:19.818751 #24466] DEBUG -- net.ssh.authentication.session[396c]: beginning authentication of `a2sdk' > D, [2024-01-26T23:11:19.818817 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.820166 #24466] DEBUG -- socket[3958]: queueing packet nr 3 type 5 len 32 > D, [2024-01-26T23:11:19.820205 #24466] DEBUG -- socket[3958]: sent 100 bytes > D, [2024-01-26T23:11:19.859904 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.860311 #24466] DEBUG -- socket[3958]: received packet nr 3 type 6 len 32 > D, [2024-01-26T23:11:19.860522 #24466] DEBUG -- net.ssh.authentication.session[396c]: trying none > D, [2024-01-26T23:11:19.860731 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.860969 #24466] DEBUG -- socket[3958]: queueing packet nr 4 type 50 len 48 > D, [2024-01-26T23:11:19.861076 #24466] DEBUG -- socket[3958]: sent 116 bytes > D, [2024-01-26T23:11:19.866706 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.867057 #24466] DEBUG -- socket[3958]: received packet nr 4 type 51 len 32 > D, [2024-01-26T23:11:19.867183 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.867282 #24466] DEBUG -- net.ssh.authentication.methods.none[3980]: none failed > D, [2024-01-26T23:11:19.867369 #24466] DEBUG -- net.ssh.authentication.session[396c]: trying publickey > D, [2024-01-26T23:11:19.868848 #24466] DEBUG -- net.ssh.authentication.agent[3994]: connecting to ssh-agent > D, [2024-01-26T23:11:19.869065 #24466] DEBUG -- net.ssh.authentication.agent[3994]: sending agent request 1 len 44 > D, [2024-01-26T23:11:19.869366 #24466] DEBUG -- net.ssh.authentication.agent[3994]: received agent packet 5 len 1 > D, [2024-01-26T23:11:19.869434 #24466] DEBUG -- net.ssh.authentication.agent[3994]: sending agent request 11 len 0 > D, [2024-01-26T23:11:19.869678 #24466] DEBUG -- net.ssh.authentication.agent[3994]: received agent packet 12 len 498 > D, [2024-01-26T23:11:19.870704 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6) alg rsa-sha2-256 > D, [2024-01-26T23:11:19.870908 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.871129 #24466] DEBUG -- socket[3958]: queueing packet nr 5 type 50 len 352 > D, [2024-01-26T23:11:19.871241 #24466] DEBUG -- socket[3958]: sent 420 bytes > D, [2024-01-26T23:11:19.876890 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.877237 #24466] DEBUG -- socket[3958]: received packet nr 5 type 51 len 32 > D, [2024-01-26T23:11:19.877359 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.877425 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6) alg ssh-rsa > D, [2024-01-26T23:11:19.877582 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.877778 #24466] DEBUG -- socket[3958]: queueing packet nr 6 type 50 len 352 > D, [2024-01-26T23:11:19.877885 #24466] DEBUG -- socket[3958]: sent 420 bytes > D, [2024-01-26T23:11:19.883542 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.883942 #24466] DEBUG -- socket[3958]: received packet nr 6 type 51 len 32 > D, [2024-01-26T23:11:19.884065 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > D, [2024-01-26T23:11:19.884282 #24466] DEBUG -- net.ssh.authentication.methods.publickey[39bc]: trying publickey (c8:ac:1c:f8:c5:f9:7f:fc:86:97:a4:96:a3:a1:2e:d8) alg ssh-ed25519 > D, [2024-01-26T23:11:19.884463 #24466] DEBUG -- socket[3958]: using encrypt-then-mac > D, [2024-01-26T23:11:19.884677 #24466] DEBUG -- socket[3958]: queueing packet nr 7 type 50 len 128 > D, [2024-01-26T23:11:19.884800 #24466] DEBUG -- socket[3958]: sent 196 bytes > D, [2024-01-26T23:11:19.890441 #24466] DEBUG -- socket[3958]: read 100 bytes > D, [2024-01-26T23:11:19.890795 #24466] DEBUG -- socket[3958]: received packet nr 7 type 51 len 32 > D, [2024-01-26T23:11:19.890918 #24466] DEBUG -- net.ssh.authentication.session[396c]: allowed methods: publickey,password > E, [2024-01-26T23:11:19.891081 #24466] ERROR -- net.ssh.authentication.session[396c]: all authorization methods failed (tried none, publickey) > > DEBUG ssh: == Net-SSH connection debug-level log END == > INFO ssh: SSH not up: #<Vagrant::Errors::SSHAuthenticationFailed: SSH authentication failed! This is typically caused by the public/private > keypair for the SSH user not being properly set on the guest VM. Please > verify that the guest VM is setup with the proper public key, and that > the private key path for Vagrant is setup properly as well.> > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO warden: Beginning recovery process... > INFO warden: Recovery complete. > ERROR warden: Error occurred: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > ... > INFO interface: error: Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > Guest-specific operations were attempted on a machine that is not > ready for guest communication. This should not happen and a bug > should be reported. > INFO interface: Machine: error-exit ["Vagrant::Errors::MachineGuestNotReady", "Guest-specific operations were attempted on a machine that is not\nready for guest communication. This should not happen and a bug\nshould be reported."] After the SSH authentication error, apparently because none of the attempted key authentication methods worked. Weird thing, on ubuntu 22.04 there's no problem. On arch is that I see the error. BTW, I tried "config.ssh.disable_deprecated_algorithms" [1] set to true on the Vagrantfile, and it doesn't help. I see nothing particularly curious on the Vagrantfile. For SSH: > # SSH options > sdk.ssh.username = "<container_username>" > sdk.ssh.forward_agent = true > sdk.ssh.pty = true > sdk.ssh.forward_x11 = true > sdk.ssh.insert_key = false Disabling deprecated algorithms since Arch has obviously a newer openssh, but again, that didn't help. It's weird that on arch the SSH authentication fails... I've created other docker containers based on ubuntu, pretty similar on this SSH Vagrantfile config, and no issues. On the other hand, I've also used other docker containers. Actually there are 2 from the org I work, that I would like to use on my arch box, but I just cant, currently relying on remote VMs... Thanks for any hints... -- Javier [1] https://developer.hashicorp.com/vagrant/docs/vagrantfile/ssh_settings

2 2

When I upgrade to dbus-broker should I expect anything to break?
by David C. Rankin 31 Jan '24

31 Jan '24

Archdevs, Just got the announcement about the replacement of dbus-daemon with dbus-broker. The RFC link is rather terse on any problems users may encounter when upgrading. Will all existing rules be accepted by dbus-broker or should we expect custom rules to break? (like custom access to embedded devices as character devices) What has been the experience of the devs in making the change? -- David C. Rankin, J.D.,P.E.

13 22

Postorius configuration help
by Georg 30 Jan '24

30 Jan '24

Hi list, I'm looking for a good description for postorius configuration. The Arch wiki is unclear to me, and the mailman documentation points to postorius.org configuration, who then points to another mailman doc providing little info on the actual configuration. Long story short, I'm failing to set up postorius so I can create users and let them log in. It would be highly appreciated if someone proficient in this topic is willing to walk me throuh. I'd then amend the wiki for more clarity. Thanks in advance Georg

2 1

libjxl upgrade issue
by Brian Allred 26 Jan '24

26 Jan '24

Hey all, After this morning's upgrade, libjxl was upgraded from 0.8.2-2 to 0.9.1-1. This upgrade broke several apps I use regularly, including Telegram and Discord. Downgrading back to 0.8.2-2 solved the problem, but I figured I'd send a heads-up to anyone else scratching their heads like I did for a bit. Brian

6 7

Postfix db, cdb, lmdb -- general question
by David C. Rankin 25 Jan '24

25 Jan '24

Devs, The "[Postfix] Warn that databases need regeneration" thread touched on a proposed change from BDB to another, either cdb or lmdb. This loosely mentions "licensing" issues. What licensing issue is the problem? The Oracle open-source license is OSI-certified and permits use of Berkeley DB in open source projects ... https://www.oracle.com/database/technologies/related/berkeleydb/berkeleydb-… Is there a question whether Arch or Postfix are open-source? Seems like they certainly qualify. The larger issue is what of other packages using a db backend, like Apache basic auth and the htdbm or dbmmanage tools? This begins to impact a number of server operations if db is dropped and other packages are impacted. This may be a non-issue, but not knowing what all db is integrated with, the prospect of db just going away is a bit concerning. So is this proposed change just for postfix, or could it impact other packages? -- David C. Rankin, J.D.,P.E.

2 1

[Postfix] Warn that databases need regeneration
by Polarian 24 Jan '24

24 Jan '24

Hello, I realised overnight I was not receiving emails after the latest version of postfix [1]. This is currently in testing, however I thought it would be best to discuss in the general mailing list instead of #archlinux-testing as it is a larger topic. I searched for a "updating" or "upgrading" documentation from postfix, and read their announcement and no mention was made of this. [2][3] Background behind this, I thought it was weird I didn't receive any emails for 24 hours (spam emails are pretty common, and mailing list emails so this is unheard of), so I checked the logs and found the following after updating: Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: virtual_alias_domains lookup failure Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: virtual_alias_domains: hash:/etc/postfix/virtual: table lookup problem Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: warning: hash:/etc/postfix/virtual is unavailable. open database /etc/postfix/virtual.db: Invalid argument Jan 23 14:43:46 email postfix/trivial-rewrite[1043]: error: open database /etc/postfix/virtual.db: Invalid argument (Note these are in REVERSE order) So I found this pretty weird and checked my config, and checked to see virtual.db existed, which it did, so I decided to just regenerate it (postmap virtual). And it fixed the issue. I then restarted and found this: Jan 23 14:46:55 email postfix/local[1094]: warning: hash:/etc/postfix/aliases: lookup of 'polarian' failed Jan 23 14:46:55 email postfix/local[1094]: warning: hash:/etc/postfix/aliases is unavailable. open database /etc/postfix/aliases.db: Invalid argument And I did the same thing, regenerated aliases.db (postmap aliases). This fixed the issue and I am back to recieving emails, but there was NO warning of the requirement to regenerate the databases, unless it is deeply nested into the documentation somewhere? I have had my email server for years, and I have never had issues with updating, so I do find it a little strange that this update required regeneration of the databases, and there was no warning in the accouncement about it. So I have a few suggestions: - Adding a upgrading note to the ArchWiki article. [4] - Add a echo to warn the user to regenerate the virtual and aliases database in post_upgrade(). [5] And also a few questions: - Does anyone know if there is any source I am missing which warned about the requirement to regenerate the aliases and virtual databases on upgrade? - Did anyone else encounter this issue? (you would need to have testing repository enabled) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev [1] https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/commit/… [2] https://www.postfix.org/smtp-smuggling.html [3] https://www.postfix.org/announcements/postfix-3.8.5.html [4] https://wiki.archlinux.org/title/Postfix [5] https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/blob/ma…

3 5