February 2022 - openSUSE Users - openSUSE Mailing Lists

polkit aka PolicyKit?
by joea- lists 08 Feb '22

08 Feb '22

What news about the Polkit vulnerability?

2 2

TW Yast Bootloader Options refreshes repos?
by Michael Hamilton 07 Feb '22

07 Feb '22

In recent weeks/months I've noticed that if I enter the Yast "Boot Loader Settings" "Bootloader-Options" tab, there is a long pause because yast immediately refreshes/downloads all the zypper repo data. Why does changing the boot loader options require a repo refresh? And while I'm on the subject of repos, I'm sometimes asked whether I want to accept new keys (like just five minutes ago). I always answer yes, but is there an easy way to tell what answer I should give? Or perhaps a way to get zypper to authoritatively check or re-check keys? Thanks. Michael

2 1

Samba updates crashes smbd
by Marc Chamberlin 06 Feb '22

06 Feb '22

I am running OpenSuSE 15.3, x64 I am a bit confused, I noticed on Mon Feb 1, that I received a number of updates, many of which involved samba bringing it to version 4.15.4-git.324.8332acf1a63150300.3.25.3-SUSE-oS15.0-x86_64. Today (Feb 5) I noticed that autofs on other systems was failing and I traced the problem back to samba which was failing to export shares because smbd had crashed. The smb.log file showed this error - [2022/02/05 18:45:01.852699, 0] ../../source3/smbd/server.c:1734(main) smbd version 4.15.4-git.324.8332acf1a63150300.3.25.3-SUSE-oS15.0-x86_64 started. Copyright Andrew Tridgell and the Samba Team 1992-2021 [2022/02/05 18:45:01.867593, 0] ../../lib/util/become_daemon.c:120(exit_daemon) exit_daemon: daemon failed to start: Samba failed to init printing subsystem, error code 13 Googling this error message lead me to this bug report - https://bugzilla.opensuse.org/show_bug.cgi?id=1191532 which seems to be all about fixing this error. The bug is marked resolved/fixed and the last entries (on Mon Feb 1) are about releasing the fix. So I assume that the release of this fix corresponds to the updates I got on that same day. Yet this is when this particular bug started showing up on my systems! I have dropped back to version 4.13.13-git.539.fdbc44a85983.20.2-SUSE-oS15.0-x86_64of samba and all is well again, both autofs and my printers are working again. So what gives? Did this update fix, or not fix this bug? I admit I do not grok about 95% of the bug report (didn't take the time to do so) but it seems pretty coincidental that the bug was was marked as resolved and then released on the very day I got updates that broke my smbd daemons. Please don't be harsh on me, I am simply trying to understand what is going on and would appreciate any suggestions/advise on what to do about updating Samba. Marc... -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the electronic signature is attached. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)

3 4

504 gateway timeout
by Joe Acquisto-j4 05 Feb '22

05 Feb '22

While attempting to login to change subscribed address, that is delete old one got 504 gateway timeouts every time https://lists.opensuse.org/accounts/openid/login/?openid=https%3A%2F%2Fwww.… My new address was confirmed, FWIW --------------------- j4computers llc Stone Ridge NY 12484 845-687-9595 www.j4computers.com ---------------------

3 2

[oS-en] [Solved] USB trouble af
by Carlos E. R. 05 Feb '22

05 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue is solved, but as it may help other people searching for issues, I post it. Actually, I solved it after writing the post, when I had a new idea to try ;-) Actual solution at the bottom. So the text below is as written before I solved the problem, so it is in the present tense. Convert mentally to "past", there are too many things to manually edit ;-) I have trouble today with USB. I noticed the keyboard not responding at times, too, but I don't think it is the keyboard at fault, because I disconnected it and the messages in the log did not stop: <0.3> 2022-02-04T16:02:10.505904+01:00 Telcontar kernel - - - [13512.013430] usb 3-2: device descriptor read/64, error -110 <0.3> 2022-02-04T16:02:26.429904+01:00 Telcontar kernel - - - [13527.937480] usb 3-2: device descriptor read/64, error -110 <0.6> 2022-02-04T16:02:26.737899+01:00 Telcontar kernel - - - [13528.245446] usb 3-2: new low-speed USB device number 69 using xhci_hcd <0.3> 2022-02-04T16:02:42.550312+01:00 Telcontar kernel - - - [13544.061549] usb 3-2: device descriptor read/64, error -110 <0.3> 2022-02-04T16:02:58.218032+01:00 Telcontar kernel - - - [13559.725587] usb 3-2: device descriptor read/64, error -110 <0.6> 2022-02-04T16:02:58.325919+01:00 Telcontar kernel - - - [13559.833895] usb usb3-port2: attempt power cycle <0.3> 2022-02-04T16:02:58.405913+01:00 Telcontar kernel - - - [13559.913695] debugfs: Directory '03' with parent 'devices' already present! <0.6> 2022-02-04T16:02:58.809916+01:00 Telcontar kernel - - - [13560.317578] usb 3-2: new low-speed USB device number 70 using xhci_hcd <0.4> 2022-02-04T16:03:08.435534+01:00 Telcontar kernel - - - [13569.946944] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:08.437901+01:00 Telcontar kernel - - - [13569.947312] debugfs: Directory '04' with parent 'devices' already present! <0.4> 2022-02-04T16:03:18.271274+01:00 Telcontar kernel - - - [13579.782227] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:18.481921+01:00 Telcontar kernel - - - [13579.989623] usb 3-2: device not accepting address 70, error -71 <0.3> 2022-02-04T16:03:18.481935+01:00 Telcontar kernel - - - [13579.990023] debugfs: Directory '06' with parent 'devices' already present! <0.6> 2022-02-04T16:03:18.678068+01:00 Telcontar kernel - - - [13580.185623] usb 3-2: new low-speed USB device number 71 using xhci_hcd <0.4> 2022-02-04T16:03:28.302733+01:00 Telcontar kernel - - - [13589.814221] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:28.305898+01:00 Telcontar kernel - - - [13589.814625] debugfs: Directory '07' with parent 'devices' already present! <0.4> 2022-02-04T16:03:38.141900+01:00 Telcontar kernel - - - [13599.650482] usb 3-2: Device not responding to setup address. <0.3> 2022-02-04T16:03:38.353902+01:00 Telcontar kernel - - - [13599.861695] usb 3-2: device not accepting address 71, error -71 <0.3> 2022-02-04T16:03:38.353914+01:00 Telcontar kernel - - - [13599.861989] usb usb3-port2: unable to enumerate USB device Telcontar:~ # lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 005: ID 05e3:0608 Genesys Logic, Inc. Hub <-- UPS? Bus 005 Device 002: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 005: ID 04d9:2020 Holtek Semiconductor, Inc. USB Keyboard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Telcontar:~ # Telcontar:~ # uname -a Linux Telcontar 5.3.18-150300.59.43-default #1 SMP Sun Jan 23 19:27:23 UTC 2022 (c76af22) x86_64 x86_64 x86_64 GNU/Linux Telcontar:~ # The only things connected to the USB now are the keyboard, the mouse, and an UPS. Looking at previous log entries I see: Telcontar:~ # zgrep "usb 3-2:" /var/log/messages-20220203.xz <0.6> 2022-01-27T11:36:21.240553+01:00 Telcontar kernel - - - [30257.429520] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-27T18:19:25.226068+01:00 Telcontar kernel - - - [39132.001180] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-28T11:43:40.193992+01:00 Telcontar kernel - - - [65096.224584] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-28T23:19:36.212612+01:00 Telcontar kernel - - - [82710.907141] usb 3-2: reset low-speed USB device number 3 using xhci_hcd <0.6> 2022-01-29T00:27:38.989871+01:00 Telcontar kernel - - - [ 6.552012] usb 3-2: new low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.598700] usb 3-2: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01 <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.603853] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4 <0.6> 2022-01-29T00:27:38.989925+01:00 Telcontar kernel - - - [ 7.608948] usb 3-2: Product: ELLIPSE <0.6> 2022-01-29T00:27:38.989930+01:00 Telcontar kernel - - - [ 7.614002] usb 3-2: Manufacturer: EATON <0.6> 2022-01-29T00:27:38.989930+01:00 Telcontar kernel - - - [ 7.618987] usb 3-2: SerialNumber: 000000000 <0.6> 2022-01-29T12:53:44.212043+01:00 Telcontar kernel - - - [14276.521334] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-29T19:53:50.190505+01:00 Telcontar kernel - - - [24902.096326] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-30T13:02:30.443420+01:00 Telcontar kernel - - - [ 6.492010] usb 3-2: new low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-30T13:02:30.443458+01:00 Telcontar kernel - - - [ 7.535702] usb 3-2: New USB device found, idVendor=0463, idProduct=ffff, bcdDevice= 0.01 <0.6> 2022-01-30T13:02:30.443493+01:00 Telcontar kernel - - - [ 7.540599] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=4 <0.6> 2022-01-30T13:02:30.443495+01:00 Telcontar kernel - - - [ 7.545485] usb 3-2: Product: ELLIPSE <0.6> 2022-01-30T13:02:30.443496+01:00 Telcontar kernel - - - [ 7.550328] usb 3-2: Manufacturer: EATON <0.6> 2022-01-30T13:02:30.443497+01:00 Telcontar kernel - - - [ 7.555128] usb 3-2: SerialNumber: 000000000 <0.6> 2022-01-30T20:13:37.216073+01:00 Telcontar kernel - - - [14716.037398] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-31T11:17:15.195212+01:00 Telcontar kernel - - - [40118.790690] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-01-31T18:56:33.207103+01:00 Telcontar kernel - - - [55638.682915] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-01T08:05:36.186233+01:00 Telcontar kernel - - - [85187.438786] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-01T17:56:27.206231+01:00 Telcontar kernel - - - [102700.937967] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-02T08:58:42.228372+01:00 Telcontar kernel - - - [136057.971264] usb 3-2: reset low-speed USB device number 2 using xhci_hcd <0.6> 2022-02-02T19:00:50.221197+01:00 Telcontar kernel - - - [152279.349753] usb 3-2: reset low-speed USB device number 2 using xhci_hcd Telcontar:~ # - --- Solution It was when pasting the test just above I noticed that usb 3-2 was "EATON", thus the UPS. I did not know before which was the culprit. So suspicions were a kernel update just before this happened, or broken hardware at the computer USB port because I had accidentally powered off the UPS while the computer was active. But then, being less dramatic, just the UPS chipset hanging. So I halted the computer, powered off the UPS at is buttton, then powered off the mains before the UPS. And on the next power up, the problem was gone :-) So the problem was that, chipset hung up at the UPS. - -- Cheers Carlos E. R. (from 15.3 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYf5/Hxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVo5cAnRNRcug7TIwEtUmCyf7c pUJDM/1+AKCN5ayWA8vRdxxnnD5BYtgO9IJCBw== =7tte -----END PGP SIGNATURE-----

1 0

VMWare Workstation Pro kernel module error
by Simon Connah 04 Feb '22

04 Feb '22

Hi, Sorry to send two messages to the mailing list in the past hour but I'm not sure what I am doing wrong. The full error log can be found here: https://gist.github.com/simonconnah/626bcc3ba426990757f900f3a59ad5cf Does anyone have any experience with this sort of issue? Thank you. Simon.

2 3

OpenSUSE Tumbleweed init.d directory?
by Simon Connah 04 Feb '22

04 Feb '22

Hi, I'm trying to install VMWare Workstation Pro 16.2.1 on a new install of Tumbleweed with all updates installed and when I run the installer it asks me this question: System service scripts directory (commonly /etc/init.d).: But I'm not sure what to put in there. Does anyone know by any chance? Thank you. Simon.

2 2

[oS-en] Leap 15.3: can't mount /home
by Carlos E. R. 03 Feb '22

03 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Unknown filesystem 'reiserfs' :-/ - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYcvG+hwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeQcAn1pPUk98DaNg71a+xWkt aO8+J/NUAJ9+K6U01YofXopVhWGaPh6VIt2Ygw== =nhEU -----END PGP SIGNATURE-----

6 29

[oS-en] Reiserfs ongoing problem
by Carlos E. R. 02 Feb '22

02 Feb '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a problem with my one remaining reiserfs partition on rotating rust. The problem I initially detected was that telling the machine to hibernate sometimes appeared to stall, and I had to force a power off (via physical power switch) to recover. In fact, I found out later, the kernel was simply syncing one partition, and this operation would take half an hour, which it is absurd. Later I found out that it was only one partition affected, and this partition was (is) reiserfs. Then I guessed that the slow operation was syncing the metadata (the time stamps) of the news (nntp) spool. Traditionally a news server touches (and use) the access timestamp each time a post is read, affecting one file per read. With the default mount options used nowdays this modification stays in RAM for long, many hours. So, the cronjob that scans the news spool now also calls sync on that filesystem, and when hibernating I call sync in advance. This improved things, but not completely. Thus I finally resorted to moving the news spool only to another reiserfs partition created on an SSD disk, which usually syncs in seconds, instead of half an hour. So I thought, problem solved. But later on I noticed that the sync operation prior to hibernating on the old reiserfs partition still takes long, but only on some days - even if nothing writes there now. This is astonishing. Look, last Monday: Telcontar:~ # hibernate 2021-12-13 04:26:18+01:00 Checking news to send 2021-12-13 04:26:22+01:00 Syncing rm: cannot remove '/var/lib/news/bin/cronscriptparafetchnews.enabled': No such file or directory 2021-12-13 06:06:09+01:00 synced. Now screensaver xscreensaver-command: no screensaver is running on display :0.0 touch /var/lib/news/bin/cronscriptparafetchnews.enabled Telcontar:~ # An hour and a half to sync a not used partition! (I know it is only one partition because I monitor it with gkrellm) Hibernation script: date --rfc-3339=seconds echo Checking news to send /var/lib/news/bin/cronscriptparaenviarnewspendientes date --rfc-3339=seconds echo Syncing rm /var/lib/news/bin/cronscriptparafetchnews.enabled strace -o /tmp/hibernate.strace sync date --rfc-3339=seconds echo "synced. Now screensaver" xscreensaver-command -lock sleep 3 #sudo chvt 10 #sleep 1 sudo /usr/local/sbin/beep sleep 1 #systemctl hibernate sudo /usr/bin/systemctl hibernate The structure of the mount is this: Telcontar:~ # mount | grep sdc9 /dev/sdc9 on /data/Lareiserfs type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/src type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /home/cer/terrasync type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /data/homedvl type reiserfs (rw,relatime,lazytime,user_xattr,acl) /dev/sdc9 on /usr/share/flightgear type reiserfs (rw,relatime,lazytime,user_xattr,acl) Telcontar:~ # The first one is the actual mount, the rest are bind mounts - fstab: LABEL=c_data_reiser /data/Lareiserfs reiserfs acl,user_xattr,barrier=flush,lazytime 1 3 /data/Lareiserfs/gamedata/flightgear /usr/share/flightgear none bind 0 0 /data/Lareiserfs/gamedata/terrasync /home/cer/terrasync none bind 0 0 /data/Lareiserfs/data_homedvl /data/homedvl none bind 0 0 /data/Lareiserfs/usr_src /usr/src none bind 0 0 Now I have added entries to my hibernate script to sync each reiserfs bind mount separately, find out which one it is, if any. - -- Cheers Carlos E. R. (from 15.2 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCYbiC3Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVNQ0An0UB/PrQobQOFtt1bA5b ll35Ej7FAJ9E6b3Mh88V1OcIbudlN0SwdavIhw== =hvzD -----END PGP SIGNATURE-----

5 11

15.3, updates a few moments ago, what are those update-test-.... updates? similar to early alpha/beta stages?
by cagsm 02 Feb '22

02 Feb '22

List, some simple 15.3 just applied some update-test-..... named updates. What gives? I am not on alpha or beta level repos or anything? bug? testing on whole userbase? 2022-02-01 20:17:34|install|update-test-affects-package-manager|5.1-33.2|x86_64||repo-sle-update|b30701eb358b95cabf7a724565bab263629b1dccdec9b50cb2113a0e34b9f6de| 2022-02-01 20:17:34|install|update-test-interactive|5.1-33.2|x86_64||repo-sle-update|f2211a27237a471cf6f558c22e63119d6e3a30af1d065be3697e53714d105ff3| 2022-02-01 20:17:34|install|update-test-optional|5.1-33.2|x86_64||repo-sle-update|b40ea677c146f8494f954531b5eac29bd88912386069039fbf7c397bdad7a41d| 2022-02-01 20:17:35|install|update-test-reboot-needed|5.1-33.2|x86_64||repo-sle-update|09f0465f6e500c6467f1c0e0865a268c0259386198a18c833b5f4049126212c2| 2022-02-01 20:17:35|install|update-test-security|5.1-33.2|x86_64||repo-sle-update|85b096976235af18d085a52cbfa1d31c40336e6120c396b3feafb264c09ef1ce| 2022-02-01 20:17:35|install|update-test-trivial|5.1-33.2|x86_64||repo-sle-update|e219dd6c3a92ccb691bafe7cfbd338d61160dc33e1470fe266e8f2dc57be4b60| ty

5 12