From anthony.naddeo at gmail.com Wed Dec 1 19:19:03 2021 From: anthony.naddeo at gmail.com (Anthony Naddeo) Date: Wed, 1 Dec 2021 11:19:03 -0800 Subject: [arch-general] Comment on dovecot 2.3.17 in testing In-Reply-To: <0c4cfae4-9352-9dcf-34b3-5549059b4c77@sapience.com> References: <0c4cfae4-9352-9dcf-34b3-5549059b4c77@sapience.com> Message-ID: UNSUBSCRIBE On Sun, Nov 28, 2021 at 4:52 AM Genes Lists via arch-general < arch-general at lists.archlinux.org> wrote: > > > Just sharing my experience with this update. I'm aware that there > have been quite a few folks with troubles as reported on the dovecot > mailing list. > > My own experience was > > a) dovecot itself worked with no problems at all. > > b) I did however have pigeonhole failing which was perplexing - > however restarting dovecot a second time got the sieve working and over > the last half day or so everything is working well. I have noticed for > users with no sieve script there remained some fails running the default > sieve script. I am recompiling that script (sievec) manually to see if > that helps. > > gene > From riveravaldezmail at gmail.com Sat Dec 4 00:07:18 2021 From: riveravaldezmail at gmail.com (riveravaldez) Date: Fri, 3 Dec 2021 21:07:18 -0300 Subject: [arch-general] System terribly slow Message-ID: 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 at 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 at 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 at backlight:acpi_video0.service 1.983s dev-disk-by\x2duuid-84c91978\x2da09c\x2d4087\x2db60d\x2d86730d142f63.swap 1.967s systemd-backlight at 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 at 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. From santiago at forero.xyz Sat Dec 4 00:32:38 2021 From: santiago at forero.xyz (Santiago Forero) Date: Fri, 3 Dec 2021 19:32:38 -0500 Subject: [arch-general] System terribly slow In-Reply-To: References: Message-ID: Hey, have you tried booting any live system from a USB drive? If it works better then it might be a problem with your HDD. Cheers On Fri, Dec 3, 2021, 7:07 PM riveravaldez via arch-general < arch-general at lists.archlinux.org> wrote: > 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 at 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 at 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 at backlight:acpi_video0.service > 1.983s > dev-disk-by\x2duuid-84c91978\x2da09c\x2d4087\x2db60d\x2d86730d142f63.swap > 1.967s systemd-backlight at 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 at 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. > From me at iyanmv.com Sat Dec 4 00:33:49 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Sat, 04 Dec 2021 01:33:49 +0100 Subject: [arch-general] System terribly slow In-Reply-To: References: Message-ID: <4391671.LvFx2qVVIh@master> Hi, On Saturday, 4 December 2021 01:07:18 CET riveravaldez via arch-general wrote: > 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. Have you check SMART health status of your disks? Maybe also run some self- tests to discard HDD issues. A HDD about to die can make system incredible slow. > 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... Do you have a single disk or more than one? If so, do you feel a difference navigating directories that are physically in different disks? Also, to discard other hardware problems, can you boot arch (or any other distro) on a USB and check if system is more responsive. Another thing you can check is the CPU freq. If CPU too hot, modern CPUs will throttle a lot. Although if you have a HDD I don't think this is the case... anycase, it's a quick think to check temperature and frequency. Also, did the slowness start after updating any BIOS/firmware? Maybe also run some memtest? Hope it helps. -- Iy?n M?ndez Veiga GPG: 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From srvrs at prvtmail.net Sat Dec 4 09:17:17 2021 From: srvrs at prvtmail.net (TG Servers) Date: Sat, 4 Dec 2021 10:17:17 +0100 Subject: [arch-general] outdated mediainfo and libmediainfo packages Message-ID: Hello, is there any particular reason why these 2 packages are outdated since several months, or were they just not maintained? I am asking because I would need some of the newer functionality and would compile them from source otherwise. But only if there are no known problems with them. The compiles from upstream 21.09 work without any issues and I can't see of any problems, but always better to just confirm Thanks From ralph at inputplus.co.uk Sat Dec 4 09:35:47 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 04 Dec 2021 09:35:47 +0000 Subject: [arch-general] System terribly slow In-Reply-To: References: Message-ID: <20211204093547.CF72A1FB49@orac.inputplus.co.uk> Hi Rivera, > 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. Once logged in, run ?LC_ALL=C dstat -tap? and leave it to settle down with nothing happening. Then start any of the complex GUI programs you mentioned which take a long time. Observe dstat's output to see where there's a bottleneck. $ LC_ALL=C dstat -tap ----system---- --total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system-- ---procs--- time |usr sys idl wai stl| read writ| recv send| in out | int csw |run blk new I doubt CPU usr and sys will be the problem; if they are then it suggests you CPU got slower. If CPU wai(t) it high then the CPUs are stalled from doing work waiting for I/O, e.g. disk reads. Lots of paging could show a problem some of the machine's RAM not being used. Seeing those figures might give you, and us on the list, some idea. -- Cheers, Ralph. From james at jamescm.co.uk Sat Dec 4 10:44:17 2021 From: james at jamescm.co.uk (James Crake-Merani) Date: Sat, 4 Dec 2021 10:44:17 +0000 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: References: Message-ID: <20211204104417.46qjw4wjenn3k7up@jamescrake-meraniarch> On 21/12/04 10:17am, TG Servers via arch-general wrote: > Hello, > > is there any particular reason why these 2 packages are outdated since > several months, or were they just not maintained? > I am asking because I would need some of the newer functionality and would > compile them from source otherwise. > But only if there are no known problems with them. The compiles from > upstream 21.09 work without any issues and I can't see of any problems, but > always better to just confirm > > Thanks Hi, I recall a long discussion on this mailing list about outdated packages. This lead to a debate which, at some points in my opinion, got quite toxic. But the bottom line was that the arch devs haven't had the resources/volunteers to maintain all packages therefore I think your theory about them not being maintained is probably correct. If it works without any issues from your own build then I don't think you'll have anything to worry about. If it interests you, you can always check the archives for the full discussion. From srvrs at prvtmail.net Sat Dec 4 11:06:49 2021 From: srvrs at prvtmail.net (TG Servers) Date: Sat, 4 Dec 2021 12:06:49 +0100 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: <20211204104417.46qjw4wjenn3k7up@jamescrake-meraniarch> References: <20211204104417.46qjw4wjenn3k7up@jamescrake-meraniarch> Message-ID: Thanks on that James I don't intend to get into toxic areas, or complaining about it. I will just use the sources from upstream then. Will have a look at the archives re that, too, thanks On 04/12/2021 11:44, James Crake-Merani via arch-general wrote: > On 21/12/04 10:17am, TG Servers via arch-general wrote: >> Hello, >> >> is there any particular reason why these 2 packages are outdated since >> several months, or were they just not maintained? >> I am asking because I would need some of the newer functionality and would >> compile them from source otherwise. >> But only if there are no known problems with them. The compiles from >> upstream 21.09 work without any issues and I can't see of any problems, but >> always better to just confirm >> >> Thanks > Hi, > > I recall a long discussion on this mailing list about outdated packages. This lead to a debate which, at some points in my opinion, got quite toxic. But the bottom line was that the arch devs haven't had the resources/volunteers to maintain all packages therefore I think your theory about them not being maintained is probably correct. If it works without any issues from your own build then I don't think you'll have anything to worry about. > > If it interests you, you can always check the archives for the full discussion. From grawlinson at archlinux.org Sun Dec 5 06:40:38 2021 From: grawlinson at archlinux.org (George Rawlinson) Date: Sun, 5 Dec 2021 06:40:38 +0000 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: References: Message-ID: <20211205064038.vimrcapgtvo3lqpu@dev> On 21-12-04 10:17, TG Servers via arch-general wrote: > Hello, > > is there any particular reason why these 2 packages are outdated since > several months, or were they just not maintained? > I am asking because I would need some of the newer functionality and would > compile them from source otherwise. > But only if there are no known problems with them. The compiles from > upstream 21.09 work without any issues and I can't see of any problems, but > always better to just confirm > > Thanks I knew these packages sounded familiar! I was the last packager, but have not added them to my version watch-list. I'll have a look at them at some point this week. -- George Rawlinson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From srvrs at prvtmail.net Sun Dec 5 07:08:32 2021 From: srvrs at prvtmail.net (TG Servers) Date: Sun, 5 Dec 2021 08:08:32 +0100 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: <20211205064038.vimrcapgtvo3lqpu@dev> References: <20211205064038.vimrcapgtvo3lqpu@dev> Message-ID: <8de5be2f-44c8-3163-7344-6580dc7c04c2@prvtmail.net> Thanks that would be great. They compile just fine from upstream so it seems there is really only a need to change the source tarballs. On 05/12/2021 07:40, George Rawlinson wrote: > On 21-12-04 10:17, TG Servers via arch-general wrote: >> Hello, >> >> is there any particular reason why these 2 packages are outdated since >> several months, or were they just not maintained? >> I am asking because I would need some of the newer functionality and would >> compile them from source otherwise. >> But only if there are no known problems with them. The compiles from >> upstream 21.09 work without any issues and I can't see of any problems, but >> always better to just confirm >> >> Thanks > I knew these packages sounded familiar! I was the last packager, but > have not added them to my version watch-list. > > I'll have a look at them at some point this week. > > -- > George Rawlinson From lone_wolf at klaas-de-kat.nl Sun Dec 5 12:43:28 2021 From: lone_wolf at klaas-de-kat.nl (Lone_Wolf) Date: Sun, 5 Dec 2021 13:43:28 +0100 Subject: [arch-general] Mesa is splitting off legacy drivers from main Message-ID: <12694f07-91bb-25f5-95d4-0a48d30f8f35@klaas-de-kat.nl> Hi, Mesa main has started dropping support for classic drivers[1] . This will affect users of Amd cards using r100 & r200 chipsets, (old) Nvidia cards using nouveau-vieux and Intel i915c & i965c . The plan is to support those older drivers through a new mesa LTS version that can be installed alongside normal mesa. Archlinux team will have to decide whether to add a mesa-lts package to keep supporting that hardware or just drop official support for them and hope some users will support them through aur. Atm it looks like mesa 22.0 will be the first stable version without support for this hardware, so there is still time to prepare for this. Lone_Wolf [1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10153 From kspatlas at disroot.org Sun Dec 5 16:53:32 2021 From: kspatlas at disroot.org (KSP Atlas) Date: Sun, 05 Dec 2021 16:53:32 +0000 Subject: [arch-general] Nvidia, fuck you again Message-ID: With the new kernel, Nvidia drivers will not work no matter what. nvidia does not load during boot, causing the nouveau driver to be loaded instead (nouveau, try not to break for 5 seconds) and nvidia-beta doesn't start the X server and you can't switch ttys, basically breaking your system unless you uninstall them via ssh or single user mode. I would get an AMD if miners cared about people other than themselves. From me at iyanmv.com Sun Dec 5 18:20:30 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Sun, 05 Dec 2021 19:20:30 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: References: Message-ID: <5546209.DvuYhMxLoT@master> Hi, On Sunday, 5 December 2021 17:53:32 CET KSP Atlas via arch-general wrote: > With the new kernel, Nvidia drivers will not work no matter what. nvidia > does not load during boot, causing the nouveau driver to be loaded instead > (nouveau, try not to break for 5 seconds) and nvidia-beta doesn't start the > X server and you can't switch ttys, basically breaking your system unless > you uninstall them via ssh or single user mode. I would get an AMD if > miners cared about people other than themselves. nvidia 495.44 is also broken in my system (both X11 and Wayland) with a GTX 1070. You can always install nvidia-470xx-dkms and everything else you need (e.g. nvidia-470xx-settings, opencl-nvidia-470xx) from AUR. Only be carefull with cuda and cudnn, because latest version require driver 495. But use previous release, and everything works just fine with linux 5.15. Cheers, Iy?n -- Iy?n M?ndez Veiga GPG: 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From paulf at quillandmouse.com Sun Dec 5 21:29:26 2021 From: paulf at quillandmouse.com (Paul M. Foster) Date: Sun, 5 Dec 2021 16:29:26 -0500 Subject: [arch-general] Replicating a package set on a new machine Message-ID: <607dff5b-d245-6c26-7231-754cd6658c22@quillandmouse.com> Folks: Assume I've installed a bunch of packages manually on machine A. Now I want to install those same packages-- not manually-- on machine B. I can have pacman tell me what packages are installed on machine A. Now, can I take the package list from machine A and, in an automated way, have pacman then install those packages on machine B? If so, how? Paul From lists at necoro.eu Sun Dec 5 21:36:53 2021 From: lists at necoro.eu (=?UTF-8?Q?Ren=c3=a9_Neumann?=) Date: Sun, 5 Dec 2021 22:36:53 +0100 Subject: [arch-general] Replicating a package set on a new machine In-Reply-To: <607dff5b-d245-6c26-7231-754cd6658c22@quillandmouse.com> References: <607dff5b-d245-6c26-7231-754cd6658c22@quillandmouse.com> Message-ID: <628f78ae-839f-b3da-8a27-ee1a51dc084c@necoro.eu> To generate the list, I'd propose: pacman -Qeq > list.txt -e : only explicitly installed packages (deps get installed anyways...) -q : output better suited for scripts And on the other machine, just do the obvious: pacman -S - < list.txt (Note the single '-', specifiying to read the list of packages from stdin). - Ren? Am 05.12.21 um 22:29 schrieb Paul M. Foster via arch-general: > Folks: > > Assume I've installed a bunch of packages manually on machine A. Now I > want to install those same packages-- not manually-- on machine B. I can > have pacman tell me what packages are installed on machine A. Now, can I > take the package list from machine A and, in an automated way, have > pacman then install those packages on machine B? If so, how? > > Paul > From paulf at quillandmouse.com Sun Dec 5 21:56:12 2021 From: paulf at quillandmouse.com (Paul M. Foster) Date: Sun, 5 Dec 2021 16:56:12 -0500 Subject: [arch-general] Replicating a package set on a new machine In-Reply-To: <628f78ae-839f-b3da-8a27-ee1a51dc084c@necoro.eu> References: <607dff5b-d245-6c26-7231-754cd6658c22@quillandmouse.com> <628f78ae-839f-b3da-8a27-ee1a51dc084c@necoro.eu> Message-ID: <7b5c7952-89f1-ff5c-1f83-23fc9bbe8506@quillandmouse.com> On 12/5/21 4:36 PM, Ren? Neumann wrote: > To generate the list, I'd propose: > > pacman -Qeq > list.txt > > -e : only explicitly installed packages (deps get installed anyways...) > -q : output better suited for scripts > > > And on the other machine, just do the obvious: > > pacman -S - < list.txt > > (Note the single '-', specifiying to read the list of packages from stdin). > > - Ren? > > Am 05.12.21 um 22:29 schrieb Paul M. Foster via arch-general: >> Folks: >> >> Assume I've installed a bunch of packages manually on machine A. Now I >> want to install those same packages-- not manually-- on machine B. I >> can have pacman tell me what packages are installed on machine A. Now, >> can I take the package list from machine A and, in an automated way, >> have pacman then install those packages on machine B? If so, how? >> >> Paul >> Outstanding. That looks like it would work. Many thanks. Paul From drankinatty at gmail.com Mon Dec 6 01:54:05 2021 From: drankinatty at gmail.com (David C. Rankin) Date: Sun, 5 Dec 2021 19:54:05 -0600 Subject: [arch-general] Mesa is splitting off legacy drivers from main In-Reply-To: <12694f07-91bb-25f5-95d4-0a48d30f8f35@klaas-de-kat.nl> References: <12694f07-91bb-25f5-95d4-0a48d30f8f35@klaas-de-kat.nl> Message-ID: <4786bae8-2a19-ca54-1944-2ea03ddf3e43@gmail.com> On 12/5/21 6:43 AM, Lone_Wolf via arch-general wrote: > Hi, > > > Mesa main has started dropping support for classic drivers[1] . > > This will affect users of Amd cards using r100 & r200 chipsets, (old) Nvidia > cards using nouveau-vieux and Intel i915c & i965c . > > The plan is to support those older drivers through a new mesa LTS version that > can be installed alongside normal mesa. > > > Archlinux team will have to decide whether to add a mesa-lts package to keep > supporting that hardware or just drop official support for them and hope some > users will support them through aur. Linux runs on a lot of old boxes. Dropping hardware support is a bad idea. Either continuing hardware support though Mesa or Arch packaging Mesa-LTS is the correct approach. Having someone wanting to try Arch load it an it fails - expecting them to have also read all about AUR and split functionality is unrealistic. Unless there is a clear burden on the packages that justifies dropping hardware support - keep it. (and the burden would need to be significant, not some "white-glove" test of -- I have to add a new compile option... let's drop it) Just my $.02. Arch generally does the right thing, so I suspect it will here as well. -- David C. Rankin, J.D.,P.E. From jonathon at m2x.dev Mon Dec 6 02:09:46 2021 From: jonathon at m2x.dev (Jonathon Fernyhough) Date: Mon, 6 Dec 2021 02:09:46 +0000 Subject: [arch-general] Mesa is splitting off legacy drivers from main In-Reply-To: <4786bae8-2a19-ca54-1944-2ea03ddf3e43@gmail.com> References: <12694f07-91bb-25f5-95d4-0a48d30f8f35@klaas-de-kat.nl> <4786bae8-2a19-ca54-1944-2ea03ddf3e43@gmail.com> Message-ID: On 06/12/2021 01:54, David C. Rankin via arch-general wrote: > Dropping hardware support is a bad idea. Just to present the opposite side of the argument: there has to be some limit, though, for example i686? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From drankinatty at gmail.com Mon Dec 6 02:13:08 2021 From: drankinatty at gmail.com (David C. Rankin) Date: Sun, 5 Dec 2021 20:13:08 -0600 Subject: [arch-general] Mesa is splitting off legacy drivers from main In-Reply-To: References: <12694f07-91bb-25f5-95d4-0a48d30f8f35@klaas-de-kat.nl> <4786bae8-2a19-ca54-1944-2ea03ddf3e43@gmail.com> Message-ID: On 12/5/21 8:09 PM, Jonathon Fernyhough via arch-general wrote: > On 06/12/2021 01:54, David C. Rankin via arch-general wrote: >> Dropping hardware support is a bad idea. > > Just to present the opposite side of the argument: there has to be some limit, > though, for example i686? > Agreed, but for x86_64, it would be beneficial to preserve the support. -- David C. Rankin, J.D.,P.E. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From grawlinson at archlinux.org Mon Dec 6 03:11:32 2021 From: grawlinson at archlinux.org (George Rawlinson) Date: Mon, 6 Dec 2021 03:11:32 +0000 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: <8de5be2f-44c8-3163-7344-6580dc7c04c2@prvtmail.net> References: <20211205064038.vimrcapgtvo3lqpu@dev> <8de5be2f-44c8-3163-7344-6580dc7c04c2@prvtmail.net> Message-ID: <20211206031132.gfvhpaxtkmrgph3r@dev> On 21-12-05 08:08, TG Servers wrote: > Thanks that would be great. They compile just fine from upstream so it seems > there is really only a need to change the source tarballs. They're now in community-testing due to a couple of changes: * Bugfix backported from upstream[0]. * New dependency (graphviz) This is shown in the first line of the * changelog[1]. [0]: https://github.com/MediaArea/MediaInfoLib/pull/1434/commits/038dff8433053aada3e8bf34655e2cec67305c5c [1]: https://mediaarea.net/MediaInfo/ChangeLog -- George Rawlinson -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From srvrs at prvtmail.net Mon Dec 6 09:43:37 2021 From: srvrs at prvtmail.net (TG Servers) Date: Mon, 6 Dec 2021 10:43:37 +0100 Subject: [arch-general] outdated mediainfo and libmediainfo packages In-Reply-To: <20211206031132.gfvhpaxtkmrgph3r@dev> References: <20211205064038.vimrcapgtvo3lqpu@dev> <8de5be2f-44c8-3163-7344-6580dc7c04c2@prvtmail.net> <20211206031132.gfvhpaxtkmrgph3r@dev> Message-ID: <41b8d2bc-daf0-382d-00cc-0eb35f41c08f@prvtmail.net> Oh yes the graphviz dep seems to be only for the gui part, I don't use that so I forgot about it. But it is part of the whole mediainfo "package" of course On 06/12/2021 04:11, George Rawlinson wrote: > On 21-12-05 08:08, TG Servers wrote: >> Thanks that would be great. They compile just fine from upstream so it seems >> there is really only a need to change the source tarballs. > They're now in community-testing due to a couple of changes: > > * Bugfix backported from upstream[0]. > * New dependency (graphviz) This is shown in the first line of the > * changelog[1]. > > [0]: https://github.com/MediaArea/MediaInfoLib/pull/1434/commits/038dff8433053aada3e8bf34655e2cec67305c5c > [1]: https://mediaarea.net/MediaInfo/ChangeLog > > -- > George Rawlinson From grazzolini at archlinux.org Mon Dec 6 12:00:37 2021 From: grazzolini at archlinux.org (Giancarlo Razzolini) Date: Mon, 06 Dec 2021 09:00:37 -0300 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: References: Message-ID: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> Em dezembro 5, 2021 13:53 KSP Atlas via arch-general escreveu: > With the new kernel, Nvidia drivers will not work no matter what. nvidia does not load during boot, causing the nouveau driver to be loaded instead (nouveau, try not to break for 5 seconds) and nvidia-beta doesn't start the X server and you can't switch ttys, basically breaking your system unless you uninstall them via ssh or single user mode. I would get an AMD if miners cared about people other than themselves. > You should probably do early loading [0]. Also, let's be respectful. [0] https://wiki.archlinux.org/title/NVIDIA#Early_loading -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From me at iyanmv.com Mon Dec 6 12:09:43 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Mon, 06 Dec 2021 13:09:43 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> References: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> Message-ID: <11916883.O9o76ZdvQC@thinkpad> Hi Giancarlo, On Monday 6 December 2021 13:00:37 CET Giancarlo Razzolini via arch-general wrote: > You should probably do early loading [0]. Also, let's be respectful. > > [0] https://wiki.archlinux.org/title/NVIDIA#Early_loading I've always done early loading, but still 495.44 is broken right now for me. At least with KDE Plasma. Cheers, Iy?n -- Iy?n M?ndez Veiga GPG 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From sl1pkn07 at gmail.com Mon Dec 6 13:03:17 2021 From: sl1pkn07 at gmail.com (sL1pKn07 SpinFlo) Date: Mon, 6 Dec 2021 14:03:17 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <11916883.O9o76ZdvQC@thinkpad> References: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> <11916883.O9o76ZdvQC@thinkpad> Message-ID: Hi works for me (plasma+wayland+GBM+nvidia 495.44) BUT, im still use a old kernel (5.15.2-arch1-1) greetings From grazzolini at archlinux.org Mon Dec 6 13:26:14 2021 From: grazzolini at archlinux.org (Giancarlo Razzolini) Date: Mon, 06 Dec 2021 10:26:14 -0300 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <11916883.O9o76ZdvQC@thinkpad> References: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> <11916883.O9o76ZdvQC@thinkpad> Message-ID: <1638797040.htpddi3gcd.astroid@arch.razzolini.com.br.none> Em dezembro 6, 2021 9:09 Iy?n M?ndez Veiga via arch-general escreveu: > Hi Giancarlo, > > On Monday 6 December 2021 13:00:37 CET Giancarlo Razzolini via arch-general > wrote: >> You should probably do early loading [0]. Also, let's be respectful. >> >> [0] https://wiki.archlinux.org/title/NVIDIA#Early_loading > > I've always done early loading, but still 495.44 is broken right now for me. > At least with KDE Plasma. > > Cheers, > Iy?n > > -- > Iy?n M?ndez Veiga > GPG 0x422E3694311E5AC1 The only way for nvidia to not be loaded if you're doing early loading, is if your nvidia modules are not on the initramfs in the first place, or old ones are there, which can't be loaded to a new kernel. All of this is easy to find out and fix. You can probably fix both by having a pacman hook to re-create the initramfs when only the nvidia module is updated. Regards, Giancarlo Razzolini -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bennett at piater.name Mon Dec 6 15:40:28 2021 From: bennett at piater.name (Bennett Piater) Date: Mon, 06 Dec 2021 16:40:28 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <11916883.O9o76ZdvQC@thinkpad> References: <1638791957.59603dun6e.astroid@arch.razzolini.com.br.none> <11916883.O9o76ZdvQC@thinkpad> Message-ID: <8a4fac9c99f57a949e5a23a676dd511d@piater.name> On 2021-12-06 13:09, Iy?n M?ndez Veiga via arch-general wrote: > I've always done early loading, but still 495.44 is broken right now > for me. > At least with KDE Plasma. Hi, as far as I remember, 495 dropped support for a few generations of GPUs. So if you're using relatively old hardware, you might be stuck downgrading to 475(?) or whatever the previous version was. And a compatible LTS kernel, but if you're on nvidia that's probably already what you're doing? Otherwise, you may want to switch to the open-source driver, as long as you don't need AAA gaming, CUDA or vulkan. Cheers, Bennett From me at iyanmv.com Mon Dec 6 15:54:39 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Mon, 06 Dec 2021 16:54:39 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <8a4fac9c99f57a949e5a23a676dd511d@piater.name> References: <11916883.O9o76ZdvQC@thinkpad> <8a4fac9c99f57a949e5a23a676dd511d@piater.name> Message-ID: <2203588.iZASKD2KPV@thinkpad> Hi Bennett, On Monday 6 December 2021 16:40:28 CET Bennett Piater via arch-general wrote: > On 2021-12-06 13:09, Iy?n M?ndez Veiga via arch-general wrote: > > I've always done early loading, but still 495.44 is broken right now > > for me. > > At least with KDE Plasma. > > Hi, as far as I remember, 495 dropped support for a few generations of > GPUs. I have a GTX 1070 which is (in theory) fully supported by nvidia, and I don't expect them to drop the support for a few more years. I mean, even the GeForce 700 Series are still supported (~8 years old) in the latest 495.44. > So if you're using relatively old hardware, you might be stuck > downgrading to 475(?) or whatever the previous version was. > And a compatible LTS kernel, but if you're on nvidia that's probably > already what you're doing? I'm using the latest kernel but the driver 470.86 from AUR (which is btw, the current production branch version). > Otherwise, you may want to switch to the open-source driver, as long as > you don't need AAA gaming, CUDA or vulkan. I do need CUDA. And also AAA gaming with 495 on Linux is a no go right now as well. I have two friends with a RTX 2060 and a RTX 3080 (yeah, they do exist apparently), and they cannot run Steam on the latest driver either. So, as I said, I think 495.44 is buggy, and 470.86 is fully compatible with linux 5.15.x. So anyone with issues should simply use the 470.xx packages from AUR until nvidia releases a new version. Cheers, Iy?n -- Iy?n M?ndez Veiga GPG 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From darose at darose.net Mon Dec 6 16:11:59 2021 From: darose at darose.net (David Rosenstrauch) Date: Mon, 6 Dec 2021 11:11:59 -0500 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <2203588.iZASKD2KPV@thinkpad> References: <11916883.O9o76ZdvQC@thinkpad> <8a4fac9c99f57a949e5a23a676dd511d@piater.name> <2203588.iZASKD2KPV@thinkpad> Message-ID: <9dbe4c24-9897-5466-8c8d-94bb9bb63f1a@darose.net> On 12/6/21 10:54 AM, Iy?n M?ndez Veiga via arch-general wrote: > I have a GTX 1070 which is (in theory) fully supported by nvidia, and I don't > expect them to drop the support for a few more years. I mean, even the GeForce > 700 Series are still supported (~8 years old) in the latest 495.44. > So, as I said, I think 495.44 is buggy, and 470.86 is fully compatible with > linux 5.15.x. So anyone with issues should simply use the 470.xx packages from > AUR until nvidia releases a new version. I've not heard anything about 495.44 being buggy. Rather, I think your issue is that that version of the driver no longer supports your card. I have a GTK 1050 Ti and it works fine; I just need to use the 470.86 version. You can see at the nvidia driver search/download site that your 1070 is only supported by the 470 version of the driver: https://www.nvidia.com/Download/index.aspx?lang=en-us https://www.nvidia.com/Download/driverResults.aspx/183575/en-us Install the following packages from AUR and you should be fine: libxnvctrl-470xx 470.86-1 nvidia-470xx-dkms 470.86-3 nvidia-470xx-settings 470.86-1 nvidia-470xx-utils 470.86-3 opencl-nvidia-470xx 470.86-3 DR From me at iyanmv.com Mon Dec 6 16:40:12 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Mon, 06 Dec 2021 17:40:12 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <9dbe4c24-9897-5466-8c8d-94bb9bb63f1a@darose.net> References: <2203588.iZASKD2KPV@thinkpad> <9dbe4c24-9897-5466-8c8d-94bb9bb63f1a@darose.net> Message-ID: <3116263.5fSG56mABF@thinkpad> On Monday 6 December 2021 17:11:59 CET David Rosenstrauch via arch-general wrote: > On 12/6/21 10:54 AM, Iy?n M?ndez Veiga via arch-general wrote: > > I have a GTX 1070 which is (in theory) fully supported by nvidia, and I > > don't expect them to drop the support for a few more years. I mean, even > > the GeForce 700 Series are still supported (~8 years old) in the latest > > 495.44. > > > > So, as I said, I think 495.44 is buggy, and 470.86 is fully compatible > > with > > linux 5.15.x. So anyone with issues should simply use the 470.xx packages > > from AUR until nvidia releases a new version. > > I've not heard anything about 495.44 being buggy. Rather, I think your > issue is that that version of the driver no longer supports your card. > I have a GTK 1050 Ti and it works fine; I just need to use the 470.86 > version. Can you double check before saying nonsense? Of course the GTX 1070 is supported [1]. You just need to select "New Feature Branch" instead of "Production Branch" in those links you sent here. Your GTX 1050 Ti is also supported in the 495.44 by the way. > You can see at the nvidia driver search/download site that your 1070 is > only supported by the 470 version of the driver: > > https://www.nvidia.com/Download/index.aspx?lang=en-us > https://www.nvidia.com/Download/driverResults.aspx/183575/en-us Not true. > Install the following packages from AUR and you should be fine: > > libxnvctrl-470xx 470.86-1 > nvidia-470xx-dkms 470.86-3 > nvidia-470xx-settings 470.86-1 > nvidia-470xx-utils 470.86-3 > opencl-nvidia-470xx 470.86-3 Yes, I used those, but not for the reason you gave. Cheers, Iy?n [1]: https://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/ supportedchips.html -- Iy?n M?ndez Veiga GPG 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From j at lollyshouse.ca Mon Dec 6 16:54:40 2021 From: j at lollyshouse.ca (Jon Irving) Date: Mon, 06 Dec 2021 17:54:40 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <3116263.5fSG56mABF@thinkpad> References: <2203588.iZASKD2KPV@thinkpad> <9dbe4c24-9897-5466-8c8d-94bb9bb63f1a@darose.net> <3116263.5fSG56mABF@thinkpad> Message-ID: <87pmq9k6q3.fsf@lollyshouse.ca> Hey everyone On Mon, 06 Dec 2021 at 17:40:12 +0100, Iy?n M?ndez Veiga via arch-general wrote: > Can you double check before saying nonsense? So much asshole. FWIW another point of information: 5.15.6-arch2-1 nvidia_drm 73728 12 nvidia_uvm 2564096 0 nvidia_modeset 1155072 19 nvidia_drm nvidia 36966400 944 nvidia_uvm,nvidia_modeset Name : nvidia-dkms Version : 495.44-6 Description : NVIDIA drivers - module sources Architecture : x86_64 URL : http://www.nvidia.com/ Licenses : custom Groups : None Provides : NVIDIA-MODULE Depends On : dkms nvidia-utils=495.44 libglvnd Optional Deps : None Required By : None Optional For : None Conflicts With : None Replaces : None Installed Size : 48.37 MiB Packager : Jan Alexander Steffens (heftig) Build Date : Sun 21 Nov 2021 01:42:16 AM Install Date : Sat 04 Dec 2021 05:00:19 PM Install Reason : Explicitly installed Install Script : No Validated By : Signature Thanks for toxic a fun time over the years, I need to get away from the Arch testosterone now. -- In this world / we walk on the roof of hell / gazing at flowers - Kobayashi Issa https://j0ni.ca ~ https://keybase.io/j0ni -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From me at iyanmv.com Mon Dec 6 17:11:25 2021 From: me at iyanmv.com (=?ISO-8859-1?Q?Iy=E1n_M=E9ndez?= Veiga) Date: Mon, 06 Dec 2021 18:11:25 +0100 Subject: [arch-general] Nvidia, fuck you again In-Reply-To: <87pmq9k6q3.fsf@lollyshouse.ca> References: <3116263.5fSG56mABF@thinkpad> <87pmq9k6q3.fsf@lollyshouse.ca> Message-ID: <1844447.CQOukoFCf9@thinkpad> Hi, On Monday 6 December 2021 17:54:40 CET Jon Irving via arch-general wrote: > Hey everyone > > On Mon, 06 Dec 2021 at 17:40:12 +0100, Iy?n M?ndez Veiga via arch-general wrote: > > Can you double check before saying nonsense? > > So much asshole. Don't know why you got offended. I only said to double check things before sending misleading information. I wasn't rude or use any swear words (like you just did). > FWIW another point of information: > > 5.15.6-arch2-1 > > nvidia_drm 73728 12 > nvidia_uvm 2564096 0 > nvidia_modeset 1155072 19 nvidia_drm > nvidia 36966400 944 nvidia_uvm,nvidia_modeset > > Name : nvidia-dkms > Version : 495.44-6 > Description : NVIDIA drivers - module sources > Architecture : x86_64 > URL : http://www.nvidia.com/ > Licenses : custom > Groups : None > Provides : NVIDIA-MODULE > Depends On : dkms nvidia-utils=495.44 libglvnd > Optional Deps : None > Required By : None > Optional For : None > Conflicts With : None > Replaces : None > Installed Size : 48.37 MiB > Packager : Jan Alexander Steffens (heftig) > Build Date : Sun 21 Nov 2021 01:42:16 AM > Install Date : Sat 04 Dec 2021 05:00:19 PM > Install Reason : Explicitly installed > Install Script : No > Validated By : Signature Can you elaborate on this? What is your point? And also, what GPU do you have? Probably not all cards are affected. > Thanks for toxic a fun time over the years, I need to get away from the > Arch testosterone now. ... > -- > In this world / we walk on the roof of hell / gazing at flowers > - Kobayashi Issa > > https://j0ni.ca ~ https://keybase.io/j0ni Cheers, Iy?n -- Iy?n M?ndez Veiga GPG 0x422E3694311E5AC1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From drankinatty at gmail.com Sun Dec 12 06:14:45 2021 From: drankinatty at gmail.com (David C. Rankin) Date: Sun, 12 Dec 2021 00:14:45 -0600 Subject: [arch-general] pacman 6 current/total not displayed on TDE - what does old konsole lack? Message-ID: <85471198-b1ee-9569-1bbb-6fcbabadc06f@gmail.com> All, As mentioned in an earlier thread, the new pacman current/total update scheme causes the old KDE3/TDE konsole output to look jittery instead of updating the multi-line progress bar. I'm trying to track down why so we can patch TDE konsole to fix the problem, but I'm having a difficult time chasing down just exactly what is being written that is causing the problem. I've chased through callback.c: static void dload_progress_event(const char *filename, alpm_download_event_progress_t *data) Where the update is done, https://gitlab.archlinux.org/pacman/pacman/-/blob/master/src/pacman/callback.c#L981 Either with console_cursor_goto_bar(index) for the current file or console_cursor_move_end() for the total and those are simple ANSI escapes from util.c: /* Moves console cursor `lines` up */ void console_cursor_move_up(unsigned int lines) { printf("\x1B[%dF", lines); } /* Moves console cursor `lines` down */ void console_cursor_move_down(unsigned int lines) { printf("\x1B[%dE", lines); } /* Erases line from the current cursor position till the end of the line */ void console_erase_line(void) { printf("\x1B[K"); } What is it that the new pacman is doing with the multi-line progress bar TDE/konsole lacks? -- David C. Rankin, J.D.,P.E. From admin at progandy.de Sun Dec 12 10:37:20 2021 From: admin at progandy.de (Andreas Bosch) Date: Sun, 12 Dec 2021 11:37:20 +0100 Subject: [arch-general] pacman 6 current/total not displayed on TDE - what does old konsole lack? In-Reply-To: <85471198-b1ee-9569-1bbb-6fcbabadc06f@gmail.com> References: <85471198-b1ee-9569-1bbb-6fcbabadc06f@gmail.com> Message-ID: <0bbc419b-c2e8-3a24-d999-e8c807508886@progandy.de> Am 12.12.21 um 07:14 schrieb David C. Rankin via arch-general: > [...] >> What is it that the new pacman is doing with the multi-line progress bar > TDE/konsole lacks? > Hello, You are missing support for two of those escape codes. Upstream Konsole has them since last year: https://git.trinitydesktop.org/cgit/tdebase/tree/konsole/konsole/TEmuVt102.cpp?h=r14.0.11#n623 https://git.trinitydesktop.org/cgit/tdebase/tree/konsole/doc/More/ansix364.txt?h=r14.0.11#n34 https://invent.kde.org/utilities/konsole/-/merge_requests/116 -- Andreas B. From ralph at inputplus.co.uk Sun Dec 12 10:41:11 2021 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 12 Dec 2021 10:41:11 +0000 Subject: [arch-general] pacman 6 current/total not displayed on TDE - what does old konsole lack? In-Reply-To: <85471198-b1ee-9569-1bbb-6fcbabadc06f@gmail.com> References: <85471198-b1ee-9569-1bbb-6fcbabadc06f@gmail.com> Message-ID: <20211212104111.C54FF1F96E@orac.inputplus.co.uk> Hi David, > /* Moves console cursor `lines` up */ > void console_cursor_move_up(unsigned int lines) > { > printf("\x1B[%dF", lines); > } It's a shame the code isn't using terminfo(5) so it's portable to different terminals, including older ones, and less misleading in its choice of function names and commentary. By sticking with terminfo's names we have a lingua franca. https://invisible-island.net/xterm/ctlseqs/ctlseqs.pdf is very useful when digging into this kind of thing. It's from Thomas Dickey, xterm(1)'s maintainer. Here's terminfo moving the cursor up N lines, as that function suggests it does. ?cuu? is in terminfo(5). $ seq 4; printf 5; tput cuu 3; printf here 1 2here$ 3 4 5 The tput is using Esc '[' N 'A', not 'F' which that function uses. $ tput cuu 3 | od -c 0000000 033 [ 3 A 0000004 ctlseqs describes this on page 8 as ?Cursor Up Ps Times (default = 1) (CUU)?. console_cursor_move_up()'s 'F' is a few lines down in ctlseqs, described as ?Cursor Preceding Line Ps Times (default = 1) (CPL)?. terminfo(5) doesn't have ?cpl?. The ECMA 48 standard, https://www.ecma-international.org/wp-content/uploads/ECMA-48_5th_edition_june_1991.pdf, does have CUU and CPL, logical pages 37 and 35 respectively, physical 51 and 49. It seems CPL does a CUU and then moves to the first column, as Carriage Return, CR, logical page 35, often does. Here's CUU, and then CPL using ECMA 48's definitions. $ printf '1\n2\n3\n4\n555\x1b[3Ahere' 1 2 here$ 3 4 555 $ printf '1\n2\n3\n4\n555\x1b[3Fhere' 1 here$ 3 4 555 I'm not saying this is the cause of your problems; I just picked on console_cursor_move_up() at random, but it shows the folly of not using terminfo in the time-honoured way and hard-coding escape sequences as if this were MS DOS. Hopefully, it's also provided some resources for you debug more where the problem lies. I suggest testing the sequences you find on your terminal. Also, script(1) may be useful to record what gets output to the terminal by the program which isn't working. -- Cheers, Ralph. From pg.nikolic1 at gmail.com Sun Dec 12 10:59:14 2021 From: pg.nikolic1 at gmail.com (pete) Date: Sun, 12 Dec 2021 10:59:14 +0000 Subject: [arch-general] Strange and annoying causing issues Message-ID: <20211212105914.6814c60e@ds9> Hi folks Most the time the system is spot ion thanks Arch Linux but every now and then i get something that is causing consternation one of those times is now i am getting this filling dmesg 23.113873] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 23.114081] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) [ 23.125584] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) [ 23.127583] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 23.719265] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 23.719777] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) [ 23.730310] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) [ 23.732198] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)[ 26.246319] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/private/systemd/journal-upload supports timestamps until 2038 (0x7fffffff) [ 26.253998] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/private/systemd/journal-upload supports timestamps until 2038 (0x7fffffff) [ 26.254017] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 26.272915] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/private/systemd/journal-upload supports timestamps until 2038 (0x7fffffff) [ 26.273523] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 79.301218] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fffffff) [ 79.301364] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ 79.318565] xfs filesystem being remounted at /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 (0x7fffffff) [ 79.319569] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) it is causing issues as far as i can make out on the USB Camera i get a pile of the above scroll up and the camera dies the camera is Bus 002 Device 002: ID 23c5:1478 Xiongmai web camera it works very well good clear video untill this lot started now it dies all the time in the middle of streaming (Discord) Thanks . Pete Pete From nsajko at gmail.com Sun Dec 12 14:04:44 2021 From: nsajko at gmail.com (Neven Sajko) Date: Sun, 12 Dec 2021 14:04:44 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211212105914.6814c60e@ds9> References: <20211212105914.6814c60e@ds9> Message-ID: On Sun, 12 Dec 2021 at 10:59, pete via arch-general wrote: > > Hi folks > > Most the time the system is spot ion thanks Arch Linux but every now and then > i get something that is causing consternation one of those times is now i am > getting this filling dmesg > > 23.113873] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp > supports timestamps until 2038 (0x7fffffff) [ 23.114081] xfs filesystem > being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps > until 2038 (0x7fffffff) [ 23.125584] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) > [ 23.127583] xfs filesystem being remounted at > /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) > [ 23.719265] xfs filesystem being remounted at /run/systemd/unit-root/var/tmp > supports timestamps until 2038 (0x7fffffff) [ 23.719777] xfs filesystem > being remounted at /run/systemd/unit-root/var/lib/tor supports timestamps > until 2038 (0x7fffffff) [ 23.730310] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/tor supports timestamps until 2038 (0x7fffffff) > [ 23.732198] xfs filesystem being remounted at > /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff)[ > 26.246319] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/private/systemd/journal-upload supports > timestamps until 2038 (0x7fffffff) [ 26.253998] xfs filesystem being > remounted at /run/systemd/unit-root/var/lib/private/systemd/journal-upload > supports timestamps until 2038 (0x7fffffff) [ 26.254017] xfs filesystem > being remounted at /run/systemd/unit-root/var/tmp supports timestamps until > 2038 (0x7fffffff) [ 26.272915] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/private/systemd/journal-upload supports > timestamps until 2038 (0x7fffffff) [ 26.273523] xfs filesystem being > remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 > (0x7fffffff) [ 79.301218] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 > (0x7fffffff) [ 79.301364] xfs filesystem being remounted at > /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) [ > 79.318565] xfs filesystem being remounted at > /run/systemd/unit-root/var/lib/upower supports timestamps until 2038 > (0x7fffffff) [ 79.319569] xfs filesystem being remounted at > /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) > > it is causing issues as far as i can make out on the USB Camera i get a pile > of the above scroll up and the camera dies > > the camera is > Bus 002 Device 002: ID 23c5:1478 Xiongmai web camera it works very well good > clear video untill this lot started now it dies all the time in the middle of > streaming (Discord) > > Thanks . > > Pete > > Pete It seems you messed up with your filesystems and mount points. I don't know much about XFS, but I'm pretty sure that a mount point named "tmp" should have tmpfs, not xfs. Regards, Neven From silver.bullet at zoho.com Sun Dec 12 14:36:55 2021 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Sun, 12 Dec 2021 15:36:55 +0100 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: References: <20211212105914.6814c60e@ds9> Message-ID: <20211212153655.18decfa1@utnubu> On Sun, 12 Dec 2021 14:04:44 +0000, Neven Sajko via arch-general wrote: >I'm pretty sure that a mount point named "tmp" should have tmpfs Hi, not necessarily, see https://wiki.archlinux.org/title/tmpfs#Disable_automatic_mount Regards, Ralf From pg.nikolic1 at gmail.com Sun Dec 12 23:41:49 2021 From: pg.nikolic1 at gmail.com (pete) Date: Sun, 12 Dec 2021 23:41:49 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211212153655.18decfa1@utnubu> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> Message-ID: <20211212234149.2d194923@ds9> On Sun, 12 Dec 2021 15:36:55 +0100 Ralf Mardorf via arch-general wrote: > On Sun, 12 Dec 2021 14:04:44 +0000, Neven Sajko via arch-general wrote: > >I'm pretty sure that a mount point named "tmp" should have tmpfs > > Hi, > > not necessarily, see > https://wiki.archlinux.org/title/tmpfs#Disable_automatic_mount > > Regards, > Ralf Thank you Ralf i will try that hope it solves the issue as for messing up the filesystem i have not done anything apart from updtaes via " pacman -Syu" for a good few weeks . Cheers Pete From silver.bullet at zoho.com Mon Dec 13 02:31:51 2021 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Mon, 13 Dec 2021 03:31:51 +0100 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211212234149.2d194923@ds9> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> Message-ID: <20211213033151.2abd5979@utnubu> On Sun, 12 Dec 2021 23:41:49 +0000, pete via arch-general wrote: >On Sun, 12 Dec 2021 15:36:55 +0100 >Ralf Mardorf via arch-general wrote: > >> On Sun, 12 Dec 2021 14:04:44 +0000, Neven Sajko via arch-general >> wrote: >> >I'm pretty sure that a mount point named "tmp" should have tmpfs >> >> Hi, >> >> not necessarily, see >> https://wiki.archlinux.org/title/tmpfs#Disable_automatic_mount >> >> Regards, >> Ralf > >Thank you Ralf i will try that hope it solves the issue as for >messing up the filesystem i have not done anything apart from updtaes >via " pacman -Syu" > for a good few weeks . Hi, I don't think it's related to the issue. [root at archlinux rocketmouse]# df -h -t tmpfs Filesystem Size Used Avail Use% Mounted on run 7.6G 1.4M 7.6G 1% /run tmpfs 7.6G 192K 7.6G 1% /dev/shm tmpfs 7.6G 4.3M 7.6G 1% /tmp tmpfs 1.6G 56K 1.6G 1% /run/user/1000 https://wiki.archlinux.org/title/tmpfs#Usage I only wanted to point out, that "tmp" where ever located, e.g. even /tmp, not necessarily is tmpfs. Better take a look at https://www.google.de/search?q=arch+linux+%22filesystem+being+remounted%22+%22supports+timestamps+until%22 At least the timestamp part is unimportant. "I can't off hand help with the remounting problem, but the timestamps message is due to https://en.wikipedia.org/wiki/Year_2038_problem." - https://forums.centos.org/viewtopic.php?t=73195#p307936 However, a lot of "filesystem being remounted" hits by the above Google search are related to xfs. I didn't read the hits, so I don't know if one of those hits is related to your issue. Regards, Ralf From brettm at coiloptic.org Mon Dec 13 05:27:49 2021 From: brettm at coiloptic.org (brettm) Date: Mon, 13 Dec 2021 16:27:49 +1100 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211213033151.2abd5979@utnubu> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> Message-ID: <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> | > /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) | > | > it is causing issues as far as i can make out on the USB Camera i get a pile | > of the above scroll up and the camera dies | > | > the camera is | > Bus 002 Device 002: ID 23c5:1478 Xiongmai web camera it works very well good | > clear video untill this lot started now it dies all the time in the middle of | > streaming (Discord) | > The part about the timestamps is a normal warning with XFS (there is an option to format with 64 bit timestamps but I seem to recall it being flakey somehow) It might be worth checking or repairing your drive to see if that fixes your camera issue, see: https://wiki.archlinux.org/title/XFS#Repair (you might need to install `xfsprogs`) See what changes would be made (without making any actual changes): xfs_repair -n /dev/sdX1 -t 120 "If the journal log has become corrupted, you can reset the log by specifying the -L option to xfs_repair." Warning: "The xfs_repair utility cannot repair an XFS file system with a dirty log. To clear the log, mount and unmount the XFS file system. If the log is corrupt and cannot be replayed, use the -L option ("force log zeroing") to clear the log, that is, xfs_repair -L /dev/device. Be aware that this may result in further corruption or data loss." xfs_repair -L /dev/sdX1 -t 120 Brett. From darose at darose.net Mon Dec 13 16:16:50 2021 From: darose at darose.net (David Rosenstrauch) Date: Mon, 13 Dec 2021 11:16:50 -0500 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> Message-ID: On 12/13/21 12:27 AM, brettm via arch-general wrote: > The part about the timestamps is a normal warning with XFS (there is an option to format with 64 bit timestamps but I seem to recall it being flakey somehow) The XFS bigtime features isn't at all flakey. (I've been using it for months without any issue.) But it used to print out an "experimental" feature warning. They removed that warning a few months ago, as the feature had been merged in over a year ago and has had no major issues reported. DR From pg.nikolic1 at gmail.com Mon Dec 13 19:30:20 2021 From: pg.nikolic1 at gmail.com (pete) Date: Mon, 13 Dec 2021 19:30:20 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> Message-ID: <20211213193020.6daa1bd3@ds9> On Mon, 13 Dec 2021 11:16:50 -0500 David Rosenstrauch via arch-general wrote: > > > On 12/13/21 12:27 AM, brettm via arch-general wrote: > > The part about the timestamps is a normal warning with XFS (there is an > > option to format with 64 bit timestamps but I seem to recall it being > > flakey somehow) > > The XFS bigtime features isn't at all flakey. (I've been using it for > months without any issue.) But it used to print out an "experimental" > feature warning. They removed that warning a few months ago, as the > feature had been merged in over a year ago and has had no major issues > reported. > > DR Ahhh there may be my problem I still gt the experimental warning every now and then have to try forced update of all XFS related progs Pete . From brettm at coiloptic.org Mon Dec 13 19:47:11 2021 From: brettm at coiloptic.org (brettm) Date: Tue, 14 Dec 2021 06:47:11 +1100 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> Message-ID: <20211214064711.60c828bb45507dcfe8f82779@coiloptic.org> | On 12/13/21 12:27 AM, brettm via arch-general wrote: | > The part about the timestamps is a normal warning with XFS (there is an option to format with 64 bit timestamps but I seem to recall it being flakey somehow) | | The XFS bigtime features isn't at all flakey. (I've been using it for | months without any issue.) But it used to print out an "experimental" | feature warning. They removed that warning a few months ago, as the | feature had been merged in over a year ago and has had no major issues | reported. | After I wrote that email, I remembered what the problem was. It wasn't flakeyness. A drive formatted on Arch Linux with XFS 64-bit timestamps was unable to be mounted on my spare laptop running Linux Mint. I didn't look any further into the issue, just used 32-bit timestamps. Somehow I doubt I'll still be using this drive in the year 2038... Brett. From darose at darose.net Mon Dec 13 20:00:28 2021 From: darose at darose.net (David Rosenstrauch) Date: Mon, 13 Dec 2021 15:00:28 -0500 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211213193020.6daa1bd3@ds9> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> Message-ID: <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> On 12/13/21 2:30 PM, pete via arch-general wrote: > On Mon, 13 Dec 2021 11:16:50 -0500 > David Rosenstrauch via arch-general wrote: > >> >> >> On 12/13/21 12:27 AM, brettm via arch-general wrote: >>> The part about the timestamps is a normal warning with XFS (there is an >>> option to format with 64 bit timestamps but I seem to recall it being >>> flakey somehow) >> >> The XFS bigtime features isn't at all flakey. (I've been using it for >> months without any issue.) But it used to print out an "experimental" >> feature warning. They removed that warning a few months ago, as the >> feature had been merged in over a year ago and has had no major issues >> reported. >> >> DR > > Ahhh there may be my problem > > I still gt the experimental warning every now and then have to try forced > update of all XFS related progs You shouldn't be seeing the experimental warning any more if you're running up to date kernels. It got removed around August. (https://www.spinics.net/lists/linux-xfs/msg54740.html) DR From u34 at net9.ga Mon Dec 13 20:59:09 2021 From: u34 at net9.ga (u34 at net9.ga) Date: Mon, 13 Dec 2021 20:59:09 +0000 Subject: [arch-general] Python 3.10: LooseVersion, distutils slated for removal at 3.12 In-Reply-To: References: Message-ID: Evangelos Foutras via arch-dev-public wrote: > Python 3.10 is now in the stable repos! > > (Some issues are to be expected but hopefully nothing too bad.) I assume you are aware to. For the record: /usr/bin/unoconv:19: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives from distutils.version import LooseVersion Line breaks added by me for clarity. -- u34 From pg.nikolic1 at gmail.com Tue Dec 14 13:27:18 2021 From: pg.nikolic1 at gmail.com (pete) Date: Tue, 14 Dec 2021 13:27:18 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> Message-ID: <20211214132718.2ff32df9@ds9> On Mon, 13 Dec 2021 15:00:28 -0500 David Rosenstrauch via arch-general wrote: > On 12/13/21 2:30 PM, pete via arch-general wrote: > > On Mon, 13 Dec 2021 11:16:50 -0500 > > David Rosenstrauch via arch-general > > wrote: > >> > >> > >> On 12/13/21 12:27 AM, brettm via arch-general wrote: > >>> The part about the timestamps is a normal warning with XFS (there is an > >>> option to format with 64 bit timestamps but I seem to recall it being > >>> flakey somehow) > >> > >> The XFS bigtime features isn't at all flakey. (I've been using it for > >> months without any issue.) But it used to print out an "experimental" > >> feature warning. They removed that warning a few months ago, as the > >> feature had been merged in over a year ago and has had no major issues > >> reported. > >> > >> DR > > > > Ahhh there may be my problem > > > > I still gt the experimental warning every now and then have to try forced > > update of all XFS related progs > > You shouldn't be seeing the experimental warning any more if you're > running up to date kernels. It got removed around August. > (https://www.spinics.net/lists/linux-xfs/msg54740.html) > > DR Hi . Wonder why then because i update almost daily with " pacman -Syu" the only thing i am cautcious of is messa as it can cause problems in some programs for me . Pete From darose at darose.net Tue Dec 14 14:32:55 2021 From: darose at darose.net (David Rosenstrauch) Date: Tue, 14 Dec 2021 09:32:55 -0500 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211214132718.2ff32df9@ds9> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> Message-ID: <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> On 12/14/21 8:27 AM, pete via arch-general wrote: > On Mon, 13 Dec 2021 15:00:28 -0500 > David Rosenstrauch via arch-general wrote: > >> On 12/13/21 2:30 PM, pete via arch-general wrote: >>> I still gt the experimental warning every now and then have to try forced >>> update of all XFS related progs >> >> You shouldn't be seeing the experimental warning any more if you're >> running up to date kernels. It got removed around August. >> (https://www.spinics.net/lists/linux-xfs/msg54740.html) >> >> DR > > Hi . > > Wonder why then because i update almost daily with " pacman -Syu" the only > thing i am cautcious of is messa as it can cause problems in some programs for > me . Mirror (very) out of date? From pg.nikolic1 at gmail.com Tue Dec 14 16:32:31 2021 From: pg.nikolic1 at gmail.com (pete) Date: Tue, 14 Dec 2021 16:32:31 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> Message-ID: <20211214163231.2a6a50b5@ds9> On Tue, 14 Dec 2021 09:32:55 -0500 David Rosenstrauch via arch-general wrote: > On 12/14/21 8:27 AM, pete via arch-general wrote: > > On Mon, 13 Dec 2021 15:00:28 -0500 > > David Rosenstrauch via arch-general > > wrote: > >> On 12/13/21 2:30 PM, pete via arch-general wrote: > >>> I still gt the experimental warning every now and then have to try forced > >>> update of all XFS related progs > >> > >> You shouldn't be seeing the experimental warning any more if you're > >> running up to date kernels. It got removed around August. > >> (https://www.spinics.net/lists/linux-xfs/msg54740.html) > >> > >> DR > > > > Hi . > > > > Wonder why then because i update almost daily with " pacman -Syu" the only > > thing i am cautcious of is messa as it can cause problems in some programs > > for me . > > Mirror (very) out of date? So why am i still seeing this then as i say i update the system virtually every day it makes no sense Pete . From darose at darose.net Tue Dec 14 17:10:40 2021 From: darose at darose.net (David Rosenstrauch) Date: Tue, 14 Dec 2021 12:10:40 -0500 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211214163231.2a6a50b5@ds9> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> Message-ID: <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> On 12/14/21 11:32 AM, pete via arch-general wrote: > So why am i still seeing this then > > as i say i update the system virtually every day it makes no sense You are seeing this message in your dmesg / journalctl? "EXPERIMENTAL big timestamp feature in use. Use at your own risk!" Are you using the LTS kernel? DR From gdamjan at gmail.com Wed Dec 15 16:22:37 2021 From: gdamjan at gmail.com (Damjan Georgievski) Date: Wed, 15 Dec 2021 17:22:37 +0100 Subject: [arch-general] RFC: declarative reference to installed kernel(s) and its modules and vmlinuz image Message-ID: Currently it's quite complicated to make the reference from an installed kernel package(s) to it's files (the kernel image and modules), except by either invoking `pacman -Qlq linux | grep vmlinuz$` or some heuristics like what mkinitcpio does. So the proposal is that every kernel package should also include a symlink in /var/lib/kernel/ to the path in /usr/lib/modules//. for ex. currently that would be: /var/lib/kernel/linux -> /usr/lib/modules/5.15.7-arch1-1/ /var/lib/kernel/linux-lts -> /usr/lib/modules/5.10.85-1-lts/ Benefits of this approach would be for tools like mkinitcpio, or sbctl, which can declaratively refer to the kernel modules and the vmlinuz image, by just knowing the package name. -- damjan From pg.nikolic1 at gmail.com Thu Dec 16 00:43:06 2021 From: pg.nikolic1 at gmail.com (pete) Date: Thu, 16 Dec 2021 00:43:06 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> Message-ID: <20211216004306.3cd5d88e@ds9> On Tue, 14 Dec 2021 12:10:40 -0500 David Rosenstrauch via arch-general wrote: > > > On 12/14/21 11:32 AM, pete via arch-general wrote: > > So why am i still seeing this then > > > > as i say i update the system virtually every day it makes no sense > > You are seeing this message in your dmesg / journalctl? > > "EXPERIMENTAL big timestamp feature in use. Use at your own risk!" > > Are you using the LTS kernel? > > DR Hi . I see this once booted after i log in to a tty i do not start into a graphical enviroment i prefer old school then startx I see the message in the tty Pete From riveravaldezmail at gmail.com Fri Dec 17 00:51:47 2021 From: riveravaldezmail at gmail.com (riveravaldez) Date: Thu, 16 Dec 2021 21:51:47 -0300 Subject: [arch-general] System terribly slow In-Reply-To: References: Message-ID: On Friday, December 3, 2021, Santiago Forero via arch-general < arch-general at lists.archlinux.org> wrote: > Hey, have you tried booting any live system from a USB drive? If it works > better then it might be a problem with your HDD. > > Cheers Hi, thanks a lot for the reply and sorry for the delay. I'll try that next and report the results. Thanks a lot! From riveravaldezmail at gmail.com Fri Dec 17 03:33:57 2021 From: riveravaldezmail at gmail.com (riveravaldez) Date: Fri, 17 Dec 2021 00:33:57 -0300 Subject: [arch-general] System terribly slow In-Reply-To: <4391671.LvFx2qVVIh@master> References: <4391671.LvFx2qVVIh@master> Message-ID: On Friday, December 3, 2021, Iy?n M?ndez Veiga via arch-general < arch-general at lists.archlinux.org> wrote: > Hi, > > On Saturday, 4 December 2021 01:07:18 CET riveravaldez via arch-general wrote: >> 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. > > Have you check SMART health status of your disks? Maybe also run some self- > tests to discard HDD issues. A HDD about to die can make system incredible > slow. Hi, Iy?n, thanks a lot for the reply and sorry for the delay. I've run some SMART tests (short and long), this is what I have til now: $ sudo smartctl -i /dev/sda | grep SMART SMART support is: Available - device has SMART capability. SMART support is: Enabled $ sudo smartctl -c /dev/sda === START OF READ SMART DATA SECTION === General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 113) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: ( 645) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 83) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. $ sudo smartctl -H /dev/sda === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED $ sudo smartctl -l selftest /dev/sda === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 10% 52941 98659719 # 2 Short offline Completed without error 00% 52932 - # 3 Extended offline Completed: read failure 10% 52887 78053410 # 4 Short offline Completed without error 00% 52881 - # 5 Extended offline Completed: read failure 10% 52875 98659715 # 6 Short offline Completed without error 00% 52868 - $ sudo smartctl -a /dev/sda === START OF INFORMATION SECTION === Model Family: Hitachi Travelstar 5K500.B Device Model: Hitachi HTS545025B9A300 Serial Number: 091108PB42061SCP1DUL LU WWN Device Id: 5 000cca 5e8c99119 Firmware Version: PB2OC60N User Capacity: 250.059.350.016 bytes [250 GB] Sector Size: 512 bytes logical/physical Rotation Rate: 5400 rpm Form Factor: 2.5 inches Device is: In smartctl database [for details use: -P show] ATA Version is: ATA8-ACS T13/1699-D revision 6 SATA Version is: SATA 2.6, 3.0 Gb/s Local Time is: Thu Dec 16 21:59:01 2021 -03 SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 113) The previous self-test completed having the read element of the test failed. Total time to complete Offline data collection: ( 645) seconds. Offline data collection capabilities: (0x5b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 83) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 098 098 062 Pre-fail Always - 196609 2 Throughput_Performance 0x0005 100 100 040 Pre-fail Offline - 0 3 Spin_Up_Time 0x0007 206 206 033 Pre-fail Always - 1 4 Start_Stop_Count 0x0012 098 098 000 Old_age Always - 3347 5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 100 100 067 Pre-fail Always - 0 8 Seek_Time_Performance 0x0005 100 100 040 Pre-fail Offline - 0 9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 53005 10 Spin_Retry_Count 0x0013 100 100 060 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 3213 191 G-Sense_Error_Rate 0x000a 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 1114237 193 Load_Cycle_Count 0x0012 001 001 000 Old_age Always - 4508441 194 Temperature_Celsius 0x0002 144 144 000 Old_age Always - 38 (Min/Max 9/50) 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 7 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 3 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 2 223 Load_Retry_Count 0x000a 100 100 000 Old_age Always - 0 SMART Error Log Version: 1 ATA Error Count: 2 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 2 occurred at disk power-on lifetime: 3303 hours (137 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 4b dd df 1d e1 Error: UNC 75 sectors at LBA = 0x011ddfdd = 18735069 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 80 a8 df 1d e0 00 00:34:49.600 READ DMA EXT ea 00 00 00 00 00 a0 00 00:34:49.600 FLUSH CACHE EXT 25 00 08 80 cc 1d e0 00 00:34:49.600 READ DMA EXT 35 00 08 c8 cd 5b e0 00 00:34:49.600 WRITE DMA EXT 25 00 08 f8 41 28 e0 00 00:34:49.600 READ DMA EXT Error 1 occurred at disk power-on lifetime: 3303 hours (137 days + 15 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 4b dd df 1d e1 Error: UNC 75 sectors at LBA = 0x011ddfdd = 18735069 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 80 a8 df 1d e0 00 00:34:45.600 READ DMA EXT 25 00 08 50 a0 20 e0 00 00:34:44.700 READ DMA EXT 25 00 68 00 df 1d e0 00 00:34:44.700 READ DMA EXT 25 00 30 80 f9 20 e0 00 00:34:44.700 READ DMA EXT 25 00 08 20 b6 21 e0 00 00:34:44.700 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 10% 52941 98659719 # 2 Short offline Completed without error 00% 52932 - # 3 Extended offline Completed: read failure 10% 52887 78053410 # 4 Short offline Completed without error 00% 52881 - # 5 Extended offline Completed: read failure 10% 52875 98659715 # 6 Short offline Completed without error 00% 52868 - SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. That's it. I'm not sure if that's more or less normal or a dying disk... Any comment? Something informative there? >> 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... > > Do you have a single disk or more than one? Single disk. > Also, to discard other hardware problems, can you boot arch (or any other > distro) on a USB and check if system is more responsive. I'll do that next and report. > Another thing you can check is the CPU freq. If CPU too hot, modern CPUs will > throttle a lot. Although if you have a HDD I don't think this is the case... > anycase, it's a quick think to check temperature and frequency. I'm looking for that right now. Any hint or recommendation about how to better do it? > Also, did the slowness start after updating any BIOS/firmware? Not to my knowledge. Right now, on boot, this is all I have: $ sudo dmesg (...) [ 533.325003] nouveau 0000:01:00.0: fifo: INTR 00000001: 00000000 [ 533.325022] nouveau 0000:01:00.0: fifo: SCHED_ERROR 00 [] [ 533.325029] nouveau 0000:01:00.0: fifo: INTR 00010000: 00000000 [ 533.325034] nouveau 0000:01:00.0: fifo: INTR 01000000: 00000000 [ 533.325042] nouveau 0000:01:00.0: fifo: INTR 08800010 [ 533.325090] nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 002100 [ !ENGINE ] (...) $ sudo journalctl -b -exp3 -- Journal begins at Thu 2021-12-02 23:59:31 -03, ends at Mon 2021-12-13 21:32:34 -03. -- dic 13 20:58:00 arch libvirtd[608]: cannot open directory '/home/dell/Software/VMs/TrisquelMini8': No existe el fichero o el directorio dic 13 20:58:00 arch libvirtd[608]: error interno: Fall? al iniciar autom?ticamente el grupo de almacenamiento 'TrisquelMini8': cannot open directory '/home/dell/Softwar> dic 13 20:58:02 arch libvirtd[608]: No se encontr? 'dmidecode' en ruta: No existe el fichero o el directorio dic 13 20:58:12 arch libvirtd[608]: No se encontr? 'dmidecode' en ruta: No existe el fichero o el directorio dic 13 21:05:29 arch kernel: nouveau 0000:01:00.0: fifo: SCHED_ERROR 00 [] dic 13 21:05:29 arch kernel: nouveau 0000:01:00.0: fifo: INTR 08800010 dic 13 21:05:29 arch kernel: nouveau 0000:01:00.0: bus: MMIO read of 00000000 FAULT at 002100 [ !ENGINE ] > Maybe also run some memtest? I'll try that also and report. > Hope it helps. Me too. Thanks a lot again! From lm at zork.pl Fri Dec 17 07:07:44 2021 From: lm at zork.pl (=?UTF-8?Q?=c5=81ukasz_Michalski?=) Date: Fri, 17 Dec 2021 08:07:44 +0100 Subject: [arch-general] System terribly slow In-Reply-To: References: <4391671.LvFx2qVVIh@master> Message-ID: <4efcfe21-c6e5-bf3f-ab4b-3efe3c79d602@zork.pl> On 12/17/21 04:33, riveravaldez via arch-general wrote: > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining LifeTime(hours) > LBA_of_first_error > # 1 Extended offline Completed: read failure 10% 52941 > 98659719 > # 2 Short offline Completed without error 00% 52932 > - > # 3 Extended offline Completed: read failure 10% 52887 > 78053410 > # 4 Short offline Completed without error 00% 52881 > - > # 5 Extended offline Completed: read failure 10% 52875 > 98659715 > # 6 Short offline Completed without error 00% 52868 > - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. > > That's it. > I'm not sure if that's more or less normal or a dying disk... > Any comment? Something informative there? > Hard to say. I would backup all data that you have on this disk. There are 3 pending sectors that you need to rewrite to be able to re-run smartd long test. A suspicious thing is that three long tests stopped on different LBA_of_first_error - it may be an not mechanical problem, but hdd electronics. My advice is - after doing a backup to run badblocks read-write test[1]. If it passes then you should have 0 "Current pending sector" reported by smartd and "Reallocated_Sector_Ct" set to 3. Then you can run smartctl --test=long and see if it passes. Anyway, this disk is suspicious and I would not use it without constant backup. [1] https://wiki.archlinux.org/title/badblocks#Read-write_test_(non-destructive) From lists at realcyber.de Sun Dec 19 21:30:43 2021 From: lists at realcyber.de (Paul Schaefer) Date: Sun, 19 Dec 2021 22:30:43 +0100 Subject: [arch-general] Pipewire Problem Message-ID: Hello folks! on 12-16 I upgraded my system and installed a pipewire upgrade: [2021-12-16T15:44:27+0100] [ALPM] upgraded pipewire (1:0.3.40-1 -> 1:0.3.42-1) After a reboot, my USB microphone/speaker device (Jabra Speak 410) did not work anymore (see pipewire's log below). I use wireplumber as session manager but the problem persisted even after switching back to pipewire-media-session. Is this a problem I should report on the bugtracker, or can somebody help me figuring out how to solve this problem? Thank you! $ journalctl --user -b -1 -u pipewire Dec 19 22:15:07 archbook systemd[1829]: Started PipeWire Multimedia Service. Dec 19 22:15:20 archbook pipewire[1837]: spa.alsa: 0x55945ef5fdd8: card already opened at rate:48000 Dec 19 22:15:20 archbook pipewire[1837]: pw.node: (alsa_input.usb- 0b0e_Jabra_SPEAK_410_USB_50C2ED128945x011200-00.mono-fallbac> Dec 19 22:15:20 archbook pipewire[1837]: spa.audioadapter: params Spa:Enum:ParamId:EnumFormat: 0:0 (convert format) Success Dec 19 22:15:20 archbook pipewire[1837]: Object: size 160, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:En> Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Id 1 (Spa:Enum:MediaType:audio) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Id 1 (Spa:Enum:MediaSubtype:raw) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:format (65537), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Id 259 (Spa:Enum:AudioFormat:S16LE) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:rate (65539), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Int 16000 Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:channels (65540), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Int 1 Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:position (65541), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Array: child.size 4, child.type Spa:Id Dec 19 22:15:20 archbook pipewire[1837]: Id 2 (Spa:Enum:AudioChannel:MONO) Dec 19 22:15:20 archbook pipewire[1837]: Object: size 216, type Spa:Pod:Object:Param:Format (262147), id Spa:Enum:ParamId:En> Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:mediaType (1), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Id 1 (Spa:Enum:MediaType:audio) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:mediaSubtype (2), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Id 1 (Spa:Enum:MediaSubtype:raw) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:format (65537), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Choice: type Spa:Enum:Choice:None, flags 00000000 24 4 Dec 19 22:15:20 archbook pipewire[1837]: Id 259 (Spa:Enum:AudioFormat:S16LE) Dec 19 22:15:20 archbook pipewire[1837]: Id 259 (Spa:Enum:AudioFormat:S16LE) Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:rate (65539), flags 00000000 Dec 19 22:15:20 archbook pipewire[1837]: Choice: type Spa:Enum:Choice:Range, flags 00000000 28 4 Dec 19 22:15:20 archbook pipewire[1837]: Int 16000 Dec 19 22:15:20 archbook pipewire[1837]: Int 48000 Dec 19 22:15:20 archbook pipewire[1837]: Int 16000 Dec 19 22:15:20 archbook pipewire[1837]: Prop: key Spa:Pod:Object:Param:Format:Audio:channels (65540), flags 00000000 From paul.marwick at gmail.com Mon Dec 20 06:08:44 2021 From: paul.marwick at gmail.com (Paul Marwick) Date: Mon, 20 Dec 2021 06:08:44 +0000 Subject: [arch-general] Difficulty installing UEFI In-Reply-To: <3a4048e5-d78b-44a7-e672-369215ce5b47@quillandmouse.com> References: <7e66ddbb-c130-488a-b87d-8fa8043e1011@gmail.com> <3a4048e5-d78b-44a7-e672-369215ce5b47@quillandmouse.com> Message-ID: <60f992fb-d9b4-e011-22f5-bd773e9d20e9@gmail.com> On 16/11/2021 04:42, Paul M. Foster via arch-general wrote: > On 11/15/21 6:34 PM, Yash Karandikar wrote: >> Hi, >> >> What's the output of "ls /sys/firmware/efi/efivars"? >> >> Thanks, >> Yash >> >> Yash Karandikar >> d5c4 1cbc 071b 41b3 f235 da13 f01e 92cd 2390 f369 > > There's nothing there. No files exist there. > > Paul > A lot of Lenovo machines seem to be set to boot in legacy mode first. I would check the firmware (startup section) and set UEFI first in the boot order. If necessary, disable legacy mode to make sure it only boots in UEFI. Then use F12 when booting and make sure to select the UEFI entry for the USB you are attempting to install from. I have a Lenovo T420 which is a 2013 machine running UEFI, can't imagine that a 2017 Lenovo machine would not support UEFI. Paul. From kspatlas at disroot.org Mon Dec 20 08:44:57 2021 From: kspatlas at disroot.org (KSP Atlas) Date: Mon, 20 Dec 2021 08:44:57 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <20211216004306.3cd5d88e@ds9> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> <20211216004306.3cd5d88e@ds9> Message-ID: So it seems that you are using an old LTS kernel, try do "sudo pacman -S linux" and when asked remove linux-lts. If you aren't using LTS, try to update your mirrors. On 16 December 2021 00:43:06 GMT, pete via arch-general wrote: >On Tue, 14 Dec 2021 12:10:40 -0500 >David Rosenstrauch via arch-general wrote: > >> >> >> On 12/14/21 11:32 AM, pete via arch-general wrote: >> > So why am i still seeing this then >> > >> > as i say i update the system virtually every day it makes no sense >> >> You are seeing this message in your dmesg / journalctl? >> >> "EXPERIMENTAL big timestamp feature in use. Use at your own risk!" >> >> Are you using the LTS kernel? >> >> DR > >Hi . >I see this once booted after i log in to a tty i do not start into a >graphical enviroment i prefer old school then startx > >I see the message in the tty > > >Pete From bjo at schafweide.org Mon Dec 20 08:51:53 2021 From: bjo at schafweide.org (Bjoern Franke) Date: Mon, 20 Dec 2021 09:51:53 +0100 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> <20211216004306.3cd5d88e@ds9> Message-ID: <68830096-d2f7-8a14-cbd7-6abeede9b837@schafweide.org> Am 20.12.21 um 09:44 schrieb KSP Atlas via arch-general: > So it seems that you are using an old LTS kernel, try do "sudo pacman -S linux" and when asked remove linux-lts. If you aren't using LTS, try to update your mirrors. > > At least I'm getting xfs filesystem being remounted at /run/systemd/unit-root/var/tmp supports timestamps until 2038 (0x7fffffff) also on 5.15.x Kind Regards Bjoern From pg.nikolic1 at gmail.com Mon Dec 20 12:15:14 2021 From: pg.nikolic1 at gmail.com (pete) Date: Mon, 20 Dec 2021 12:15:14 +0000 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> <20211216004306.3cd5d88e@ds9> Message-ID: <20211220121514.17c705e4@ds9> On Mon, 20 Dec 2021 08:44:57 +0000 KSP Atlas via arch-general wrote: > So it seems that you are using an old LTS kernel, try do "sudo pacman -S > linux" and when asked remove linux-lts. If you aren't using LTS, try to > update your mirrors. > > On 16 December 2021 00:43:06 GMT, pete via arch-general > wrote: > >On Tue, 14 Dec 2021 12:10:40 -0500 > >David Rosenstrauch via arch-general wrote: > > > >> > >> > >> On 12/14/21 11:32 AM, pete via arch-general wrote: > >> > So why am i still seeing this then > >> > > >> > as i say i update the system virtually every day it makes no sense > >> > >> You are seeing this message in your dmesg / journalctl? > >> > >> "EXPERIMENTAL big timestamp feature in use. Use at your own risk!" > >> > >> Are you using the LTS kernel? > >> > >> DR > > > >Hi . > >I see this once booted after i log in to a tty i do not start into a > >graphical enviroment i prefer old school then startx > > > >I see the message in the tty > > > > > >Pete Hi nope latest kernel updated daily " pacman -S linux warning: linux-5.15.10.arch1-1 is up to date -- reinstalling resolving dependencies... looking for conflicting packages... Packages (1) linux-5.15.10.arch1-1 Total Installed Size: 135.25 MiB Net Upgrade Size: 0.00 MiB . " this is getting silly now Cheers Pete From darose at darose.net Mon Dec 20 16:12:22 2021 From: darose at darose.net (David Rosenstrauch) Date: Mon, 20 Dec 2021 11:12:22 -0500 Subject: [arch-general] Strange and annoying causing issues In-Reply-To: <68830096-d2f7-8a14-cbd7-6abeede9b837@schafweide.org> References: <20211212105914.6814c60e@ds9> <20211212153655.18decfa1@utnubu> <20211212234149.2d194923@ds9> <20211213033151.2abd5979@utnubu> <20211213162749.4d72f4b5084f3b6c2a3f5ed3@coiloptic.org> <20211213193020.6daa1bd3@ds9> <5f8ff31a-0d61-a419-5b59-b7f7d90a1482@darose.net> <20211214132718.2ff32df9@ds9> <2f025523-7ead-23cd-a322-b45ea54dd73b@darose.net> <20211214163231.2a6a50b5@ds9> <85bf2abb-62b7-67ad-1acb-40b6dc1baade@darose.net> <20211216004306.3cd5d88e@ds9> <68830096-d2f7-8a14-cbd7-6abeede9b837@schafweide.org> Message-ID: <8ded37f6-4c66-286d-a0a8-261fe13a0d96@darose.net> On 12/20/21 3:51 AM, Bjoern Franke via arch-general wrote: > At least I'm getting xfs filesystem being remounted at > /run/systemd/unit-root/var/tmp supports timestamps until 2038 > (0x7fffffff) also on 5.15.x > > Kind Regards > Bjoern That's a different message. That means that your filesystem is *not* using the bigtime feature, and so will experience an issue with dates further forward than 2038. (See https://en.wikipedia.org/wiki/Year_2038_problem) To switch the xfs file system to use bigtime, see the instructions here: https://wiki.archlinux.org/title/XFS#Big_timestamps (Note that the file system has to be unmounted when you make the conversion.) DR From u34 at net9.ga Mon Dec 20 22:25:36 2021 From: u34 at net9.ga (u34 at net9.ga) Date: Mon, 20 Dec 2021 22:25:36 +0000 Subject: [arch-general] ntfs3 kenel module: permissions not consistent with dmask=0027 from /etc/fstab Message-ID: Hello, With the ntfs3 linux module, some, but not all, directories of the ntfs partition do not have permissions that are consistent with dmask 027. dmask=0027 is from /etc/fstab. Based on a small set, the files permissions are consistent with the fmask setting. As an aside, as of 5.15.10-arch1-1, I believe arch didn't apply https://lore.kernel.org/ntfs3/20211127135105.27795-1-ales.astone at gmail.com/T/ , or some other solution. Which is why I think it is expected to have the 37777600 prefix issue with the ntfs3 linux module. -- u34 From isaacjohnr22 at gmail.com Wed Dec 22 01:13:59 2021 From: isaacjohnr22 at gmail.com (Isaac R.) Date: Tue, 21 Dec 2021 19:13:59 -0600 Subject: [arch-general] ntfs3 kenel module: permissions not consistent with dmask=0027 from /etc/fstab In-Reply-To: References: Message-ID: Is the ntfs3 module in the standard "linux" package, or is it packaged separately? If it's packaged with the kernel, then you will probably have to wait until it reaches the stable kernel. On Mon, Dec 20, 2021, 4:25 PM u34--- via arch-general < arch-general at lists.archlinux.org> wrote: > Hello, > > With the ntfs3 linux module, some, but not all, directories of the ntfs > partition do not have permissions that are consistent with dmask 027. > dmask=0027 is from /etc/fstab. > Based on a small set, the files permissions are consistent with the fmask > setting. > > As an aside, as of 5.15.10-arch1-1, I believe arch didn't apply > > https://lore.kernel.org/ntfs3/20211127135105.27795-1-ales.astone at gmail.com/T/ > , or some other solution. Which is why I think it is expected to have the > 37777600 prefix issue with the ntfs3 linux module. > > -- > u34 > From nihilistzsche at gmail.com Wed Dec 22 10:21:36 2021 From: nihilistzsche at gmail.com (nihilistzsche) Date: Wed, 22 Dec 2021 02:21:36 -0800 Subject: [arch-general] ntfs3 kenel module: permissions not consistent with dmask=0027 from /etc/fstab In-Reply-To: References: Message-ID: It has been added to the kernel in 5.15. On Tue, Dec 21, 2021 at 5:14 PM Isaac R. via arch-general < arch-general at lists.archlinux.org> wrote: > Is the ntfs3 module in the standard "linux" package, or is it packaged > separately? If it's packaged with the kernel, then you will probably have > to wait until it reaches the stable kernel. > > On Mon, Dec 20, 2021, 4:25 PM u34--- via arch-general < > arch-general at lists.archlinux.org> wrote: > > > Hello, > > > > With the ntfs3 linux module, some, but not all, directories of the ntfs > > partition do not have permissions that are consistent with dmask 027. > > dmask=0027 is from /etc/fstab. > > Based on a small set, the files permissions are consistent with the fmask > > setting. > > > > As an aside, as of 5.15.10-arch1-1, I believe arch didn't apply > > > > > https://lore.kernel.org/ntfs3/20211127135105.27795-1-ales.astone at gmail.com/T/ > > , or some other solution. Which is why I think it is expected to have the > > 37777600 prefix issue with the ntfs3 linux module. > > > > -- > > u34 > > > From u34 at net9.ga Sat Dec 25 09:24:08 2021 From: u34 at net9.ga (u34 at net9.ga) Date: Sat, 25 Dec 2021 09:24:08 +0000 Subject: [arch-general] ntfs3 kenel module: permissions not consistent with dmask=0027 from /etc/fstab In-Reply-To: References: Message-ID: Hello, I, who started this thread, have posted https://lore.kernel.org/ntfs3/E1n0BSg-0001lD-UY at mx1.net9.ga/ . No followup so far. With a mounted ntfs3 C:, Preferbly of MS Windows 10, can you post the output of $ ls -ld /'/Users/Default/My Documents' and $ ls -ld //Users/Default/Documents and the umask and dmask of the mount options? My results are: $ ls -ld /'/Users/Default/My Documents' lrwxrwxrwx 1 user user 26 Mar 12 2020 '/mount directory/Users/Default/My Documents' -> C:/Users/Default/Documents $ ls -ld //Users/Default/Documents dr-xr-x--- 1 user user 4096 Jul 25 2019 /mount directory/Users/Default/Documents umask is not explicitly set. dmask=0027. Thank you. -- u34 nihilistzsche via arch-general wrote: > It has been added to the kernel in 5.15. > > On Tue, Dec 21, 2021 at 5:14 PM Isaac R. via arch-general < > arch-general at lists.archlinux.org> wrote: > > > Is the ntfs3 module in the standard "linux" package, or is it packaged > > separately? If it's packaged with the kernel, then you will probably have > > to wait until it reaches the stable kernel. > > > > On Mon, Dec 20, 2021, 4:25 PM u34--- via arch-general < > > arch-general at lists.archlinux.org> wrote: > > > > > Hello, > > > > > > With the ntfs3 linux module, some, but not all, directories of the ntfs > > > partition do not have permissions that are consistent with dmask 027. > > > dmask=0027 is from /etc/fstab. > > > Based on a small set, the files permissions are consistent with the fmask > > > setting. > > > > > > As an aside, as of 5.15.10-arch1-1, I believe arch didn't apply > > > > > > > > https://lore.kernel.org/ntfs3/20211127135105.27795-1-ales.astone at gmail.com/T/ > > > , or some other solution. Which is why I think it is expected to have the > > > 37777600 prefix issue with the ntfs3 linux module. > > > > > > -- > > > u34 > > > > > From suseguitar at mailbox.org Fri Dec 31 12:26:23 2021 From: suseguitar at mailbox.org (Susanne Schneider) Date: Fri, 31 Dec 2021 13:26:23 +0100 Subject: [arch-general] ffado-mixer error after latest "pacman -Syu" Message-ID: hi, when trying to start ffado-mixer I receive the following message: > ?? ...?? $ ffado-mixer Traceback (most recent call last): ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 460, in updatePanels ??? self.addPanel(idx) ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line 339, in addPanel ??? mixerwidget.initValues() ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 102, in initValues ??? self.selectCorrectMode() ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 61, in selectCorrectMode ??? self.large.initValues() ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line 137, in initValues ??? self.updateValues() ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", line 347, in updateValues ??? SaffireMixerBase.updateValues(self) ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line 105, in updateValues ??? ctrl.setValue(vol) TypeError: setValue(self, int): argument 1 has unexpected type 'dbus.Double' Abgebrochen (Speicherabzug geschrieben) ....? $ < any hit will be appreciated, either, if I can do something on my own or where to direct a bug report etc... thanks for reading, -suse (Thinkpad T520, Focusrite Saffire Pro10) From hz0885 at gmail.com Fri Dec 31 14:15:50 2021 From: hz0885 at gmail.com (Zero) Date: Fri, 31 Dec 2021 15:15:50 +0100 Subject: [arch-general] ffado-mixer error after latest "pacman -Syu" In-Reply-To: References: Message-ID: <634571ea-7dcd-37d9-cbca-2da8430507d7@GMail.com> On 12/31/21 13:26, Susanne Schneider via arch-general wrote: > hi, > when trying to start ffado-mixer I receive the following message: > > > > ?? ...?? $ ffado-mixer > Traceback (most recent call last): > ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line > 460, in updatePanels > ??? self.addPanel(idx) > ? File "/usr/lib/python3.10/site-packages/ffado/panelmanager.py", line > 339, in addPanel > ??? mixerwidget.initValues() > ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", > line 102, in initValues > ??? self.selectCorrectMode() > ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", > line 61, in selectCorrectMode > ??? self.large.initValues() > ? File > "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line > 137, in initValues > ??? self.updateValues() > ? File "/usr/lib/python3.10/site-packages/ffado/mixer/saffirepro.py", > line 347, in updateValues > ??? SaffireMixerBase.updateValues(self) > ? File > "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line > 105, in updateValues > ??? ctrl.setValue(vol) > TypeError: setValue(self, int): argument 1 has unexpected type > 'dbus.Double' > Abgebrochen (Speicherabzug geschrieben) > ....? $ > < > > any hit will be appreciated, either, if I can do something on my own > or where to direct a bug report etc... > > thanks for reading, You could try to change that line 105 File "/usr/lib/python3.10/site-packages/ffado/mixer/saffire_base.py", line 105, in updateValues ??? ctrl.setValue(vol) into ctrl.setValue(int(vol)) Maybe open a bug report at Arch libffado and/or ffado.org ~Z