January 2023 - openSUSE Support - openSUSE Mailing Lists

Printer driver HP Color Laser 178nw
by Jogchum Reitsma 17 Feb '23

17 Feb '23

Hi, I am trying to install a HP Color Laser 178nw Cups (and also lsusb) sees the printer, but I can't find a driver for it. The list of printer cups, and also the HP support website, is long, but I no Color Laser 178nw. On the HP support site no driver can be found at all, regardless the choice of OS. The openprinting.org site also shows no Color Laser 178nw. It was bought very recently, so I wouldn't think it's a too old model. Anyone an idea how to get this beast to work? Thanks i advance, Jogchum

8 16

[support] wiki page watching
by Felix Miata 30 Jan '23

30 Jan '23

I started new page https://en.opensuse.org/SDB:InstallNewerKernel on 27 Jan. I don't recall doing anything to cause it to not be watched, yet none the several edits by Svyatko that followed ever caused an email notification. Is this a normal result of creating a new page? When I went back to work it, the watch this page box was always checked. Is there a simple way to check whether watching is enabled on the individual article or talk pages, without having to find the watchlist page and edit it? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

1 0

Intel Ideapad i915 backlight broke after latest TW updates
by Marco Calistri 27 Jan '23

27 Jan '23

[ 4.686103] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 23.876210] ideapad_acpi VPC2004:00: Keyboard backlight control not available Hello, After latest Tumbleweed updates my backlight/brightness has messed up. I used to lean on an "after.local" script in order to set brightness for my Lenovo Z470 at startup: #!/bin/sh echo -n 700 > /sys/class/backlight/intel_backlight/brightness Now this script is useless because the brightness doen't get adjusted anymore. Is there someone which already faced/resolved same issue? Thanks and regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230125 Kernel: 6.1.8-1-default - XFCE: (4.18.0)

1 1

Including Shutter into the main repo(?)
by Marco Calistri 21 Jan '23

21 Jan '23

Hi, I was needing a snipping tool with the ability to record the "mouse-over tool-tips" into the screenshot and so far I couldn't find nothing with this feature. At least until today, when I read about and have installed Shutter by the community repo rievan. Repository : home:rievan (openSUSE_Tumbleweed) Nome : shutter Versione : 0.98-30.7 Arch. : noarch Fornitore : obs://build.opensuse.org/home:rievan Dimensione installata : 13,9 MiB installato : Sì Stato : aggiornato Pacchetto sorgente : shutter-0.98-30.7.src URL upstream : http://shutter-project.org/ Sommario : The feature-rich screenshot tool Descrizione : Shutter is a feature-rich screenshot program for Linux based operating systems such as Ubuntu. You can take a screenshot of a specific area, window, your whole screen, or even of a website – apply different effects to it, draw on it to highlight points, and then upload to an image hosting site, all within one window. Shutter is free, open-source, and licensed under GPL v3. I think that Shutter is so far the best snipping tool that I never used (IMHO), and I'm asking if you could include it into the main Tumbleweed repository. Thanks for your kindest attention! Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230118 Kernel: 6.1.6-1-default - XFCE: (4.18.0)

2 3

Sending document from Libreoffice crashes Kontact
by Axel Braun 20 Jan '23

20 Jan '23

Hi, since month I have the reproducible case that, when sending a document from LO (File -> Sent -> Email Document) Kontact/KMail crashes when hitting the send button (and not sending the mail). After restarting Kontact at least the mail is still availabe, and as the document is then attached to the mail the mail can be sent. In the respective KDE bug report https://bugs.kde.org/show_bug.cgi?id=456082 the developer cant reproduce this. Can anyone reproduce the bug? If so, it might be oS specific? Tumbleweed Cheers Axel

3 2

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 14 Jan '23

14 Jan '23

On Thu, 12 Jan 2023 17:24:34 +1030, Simon Lees wrote: > Don't shoot the messenger, that's just the content of the bugreport. No shooting intended from here for sure! I'm very grateful for your sharing the contents of the bug report, and the history. > At a guess i'd say its related to the way someone would like it to be > implemented for package hub as they are probably using the same package. So I guess same question: What options do I, as a lowly user, have to somehow move this along, and/or get it changed, and/or get some kind of workaround? I know I can build from source, but I really prefer the advantages of distro-provided packages if at all possible, not to mention the nice /etc/alternatives and related support that OpenSuse provides. Would it make sense, for example, to raise this on the opensuse-python list? Or is there some other action I could take to help facilitate? Apologies that I lack the organizational/political knowledge here - I've been a fan of OpenSuse from the v7 days and have always used it as my primary, but that confers zero knowledge about the people behind the decisions! Thanks for any insight or pointers anyone can provide! Glen

3 4

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

On Thu, 12 Jan 2023 17:35:47 +1030, Simon Lees wrote: > Most developers are using openSUSE Tumbleweed where Python 3.8, 3.9 and > 3.10 are all co install-able and there is a different mechanism to set > the default python and handle migrations. This was done post the release > of Leap 15, so it was never implemented there and 3.6 will remain the > default because that is what we promised SUSE customers. I expect that > ALP will have a similar setup to tumbleweed and handling multiple python > versions will be easier. Okay, understood. > Python 3.9 and 3.10 have never been officially supported in Leap 15.4 (I > believe there are plans to have atleast one for 15.5) so if this was > done to make package hub work properly for SUSE it will be hard to > convince them to change it again. Okay, I think I understand that. If you think it would be worth asking anyway, and can provide a point of contact, I'm happy to write an email. Let me know. > On the other hand branching the package and removing the conflicts and > building a version for yourself is not hard. I can probably help walk > you through the process a little later. I would be SUPER GRATEFUL for that. I of course know that you must be super busy and would never expect it, but, absolutely, if you'd be willing to tell me how, I'd love to learn the technique(s) and do the work. Please do email me directly whenever you have time, that would be a huge help for me, and my users. THANK YOU THANK YOU! And now crashing for real, thank you all! Glen

1 0

Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly. However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown: # zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the installed python39-setuptools-44.1.1-7.3.1.noarch requires 'python39', but this requirement cannot be provided not installable providers: python39-3.9.10-150300.4.8.2.x86_64[repo-oss] python39-3.9.10-150300.4.8.2.x86_64[repo-sle-update] python39-3.9.13-150300.4.13.1.x86_64[repo-sle-update] python39-3.9.14-150300.4.16.1.x86_64[repo-sle-update] Solution 1: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch deinstallation of libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies I have even tried downloading the 8 "main" Python310 packages and installing via rpm... libpython3_10-1_0-3.10.8-150400.4.15.1.x86_64.rpm python310-3.10.8-150400.4.15.1.x86_64.rpm python310-base-3.10.8-150400.4.15.1.x86_64.rpm python310-curses-3.10.8-150400.4.15.1.x86_64.rpm python310-dbm-3.10.8-150400.4.15.1.x86_64.rpm python310-devel-3.10.8-150400.4.15.1.x86_64.rpm python310-pip-22.0.4-150400.3.3.1.noarch.rpm python310-setuptools-57.4.0-150400.2.14.noarch.rpm # rpm -Uvh [lp]* error: Failed dependencies: python39 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python39 = 3.9.15 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python39 = 3.9.15 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python(abi) = 3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch python(abi) = 3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python39-base >= 3.9.15 is needed by (installed) libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 python39-base = 3.9.15 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 /usr/bin/python3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch /usr/bin/python3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch /usr/bin/python3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 I've listed out the contents of the existing Python3.9 packages, as well as the manually-downloaded Python3.10 packages. All seem to be properly structured, in that they all install with separate names and/or in separate directories, just as expected. Nevertheless it appears that any attempts to install Python3.10 make the servers try to uninstall Python3.9, which implies that, despite the separate layouts and structures, the two versions cannot be installed side-by-side. I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4? Thank you! Glen

5 20

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

Hi Simon - I sent my other email and then saw this: On Thu, 12 Jan 2023 16:26:48 +1030 , Simon Lees wrote: >Bug 1195831 - python310 doesn't offer a migration path >With the submitted python310 in Staging there is no submission path >offered to do a removal of python39 and replace it with the newer >version. This would lead to an orphaned package on migrations and >customers not receiving the newer python310. >I don't think that python310 can follow the guidelines and do a Provides >and Obsoletes. An alternative might be to introduce a meta package for >this development interpreter like it is done for rust: >https://build.suse.de/package/view_file/SUSE:SLE-15-SP4:GA/rust/rust.spec?e… >or introducing a python39-obsolete, which Recommends the installation of >python310. >There might be other solutions to this as well, but we definitely >require some fix for this migration/orphaned package issue. >------------------------------------------------------------------- >An obsolete is not a conflict however, so this change doesn't explain >them not being co install-able. So it seems that this bug is the same problem I'm having? I read and appreciated your explanation about the bug system. Is it possible to perhaps add me to that bug, or at least add the information I've sent to the bug to help the maintainers fix this? >As with many fun things in life, its a Legacy software issue. Currently >we are still using a bugzilla instance from the Novell era. It has some >unfortunate settings that are very hard to change, many that any bug >thats listed for SUSE Partners becomes closed. That bugzilla instance >has so many patches that its very hard to work on or update. I fell afoul of this type of thing on the list system as well. When the change to the list system was made, my primary address somehow ended up banned systemwide (and no, I had not offended anyone ever or even come close to it as far as I know!) but I was unable to subscribe myself to or remove myself from ANY OpenSuse lists - and I had no idea who to contact to fix that. I ended up just creating a new freemail address just so I could get these support requests through - but there are certainly problems in the Mailman3 system as well, FWIW... Thanks again for any information or assistance! Glen

1 0

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

Hi Simon - Thank you for your reply... On Thu, 12 Jan 2023 16:43:20 +1030, Simon Lees wrote: >On 1/10/23 09:08, Glen Barney wrote: >> I have a number of 15.4 servers, which have been upgraded from previous >> recent Leap versions. These servers have the legacy Python 2.7, the >> current Python 3.6, and the newer Python 3.9 package groups all >> installed, side by side, and all working properly. >> However.... attempts to install Python 3.10 fail, with what appear to be >> dependency conflicts against Python 3.9. >It seems more like there is a conflict in something like python-tools or >python-setuptools, maybe you can remove the 3.9 version manually and >that will make the resolver happier. On my tumbleweed system I certainly >still have both installed but that is setup differently. Alas, I've tried various combinations without luck. And this is an operational development server on Leap 15.4, so I can't switch to TW in this case. To try to narrow this down further, I just created a freshly-loaded default install of 15.4 on a brand new (virtual) machine. The default install loaded Python 3.6, as expected. I then tried this: # zypper in python39 python310 And got this: Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed python310-3.10.8-150400.4.15.1.x86_64 obsoletes 'python39' provided by the to be installed python39-3.9.15-150300.4.21.1.x86_64 Solution 1: do not install python39-3.9.15-150300.4.21.1.x86_64 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64 Choose from above solutions by number or cancel [1/2/c/d/?] (c): This doesn't make sense to me, because if I download the RPMs and list them out, everything seems co-compatible: # rpm -q -l python39-3.9.15-150300.4.21.1.x86_64.rpm /usr/lib64/python3.9 /usr/lib64/python3.9/lib-dynload /usr/lib64/python3.9/lib-dynload/_sqlite3.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/lib-dynload/nis.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/sqlite3 /usr/lib64/python3.9/sqlite3/__init__.py /usr/lib64/python3.9/sqlite3/__pycache__ /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.pyc /usr/lib64/python3.9/sqlite3/dbapi2.py /usr/lib64/python3.9/sqlite3/dump.py # rpm -q -l python310-3.10.8-150400.4.15.1.x86_64.rpm /usr/lib64/python3.10 /usr/lib64/python3.10/lib-dynload /usr/lib64/python3.10/lib-dynload/_sqlite3.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/lib-dynload/readline.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/sqlite3 /usr/lib64/python3.10/sqlite3/__init__.py /usr/lib64/python3.10/sqlite3/__pycache__ /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.pyc /usr/lib64/python3.10/sqlite3/dbapi2.py /usr/lib64/python3.10/sqlite3/dump.py Simiarly for pip... # rpm -q -l python39-pip-20.2.4-7.8.1.noarch.rpm | grep -v -e 3.9 -e 39 /etc/alternatives/pip # rpm -q -l python310-pip-20.2.4-150400.1.19.noarch.rpm | grep -v 10 /etc/alternatives/pip /etc/alternatives/pip3 /usr/bin/pip /usr/bin/pip3 And setuptools... # rpm -q -l python39-setuptools-44.1.1-7.3.1.noarch.rpm | grep -v -e 3.9 -e 39 /etc/alternatives/easy_install /usr/bin/easy_install /usr/bin/easy_install- # rpm -q -l python310-setuptools-57.4.0-150400.2.14.noarch.rpm | grep -v 10 (no output at all, everything in a 3.10 subdirectory) And python-tools... # rpm -q -l python39-tools-3.9.15-150300.4.21.1.x86_64.rpm | grep -v -e 3.9 -e 39 (no output) # rpm -q -l python310-tools-3.10.8-150400.4.15.1.x86_64.rpm | grep -v 10 (no output) My goal here is to have Python 3.10 installed alongside 3.9, so that developer users can migrate their code having both platforms available. It seems like the packages should co-exist nicely - Python seems built to allow versions to co-exist nicely - and yet even the basic packages here refuse to be installed together. This is what I'm trying to understand and work around. Thank you for any insight you can provide! Glen

1 0

getting systemd-status-mail to work
by Axel Braun 11 Jan '23

11 Jan '23

Hi, I'm trying to get the recently announced systemd-status-mail to work I'm using the following configuration: ---- # cat /etc/default/systemd-status-mail # ADDRESS is the mail account to which the status mails should be send ADDRESS=myaddress(a)gmx.de # Set HOSTNAME if the system does not set it or if you need to override # the system default #HOSTNAME=myhostname # Valid values for MAILER: "sendmail" or "mailx" MAILER="mailx -Sverbose -Ssmtp-use-starttls -Ssmtp-auth=login -Ssmtp-auth-user="myaddress(a)gmx.de" -Ssmtp-auth-password="TopSecret" " # RELAYHOST specifies the mail relay used by mailx if specified RELAYHOST=smtp.gmx.net ---- So far so good, when it comes to send the mail (journalctl) Dez 11 00:04:45 systemd[1]: transactional-update.service: Triggering OnFailure= dependencies. Dez 11 00:04:45 systemd[1]: transactional-update.service: Consumed 22.964s CPU time. Dez 11 00:04:45 systemd[1]: Starting Send status mail for transactional-update.service... Dez 11 00:04:45 systemd[1]: systemd-status-mail(a)transactional-update.service.service: Deactivated successfully. Dez 11 00:04:45 systemd[1]: Finished Send status mail for transactional-update.service. That looks good, but no mail did arrive. Nothing in the journal, nor anything in /var/log that looks useful. Any idea how to nail that problem? Thanks Axel

5 11

[TW] How do I unsubscribe from an opensuse list?
by Bob Williams 10 Jan '23

10 Jan '23

I am trying to unsubscribe from updates(a)lists.opensuse.org but I'm not sure of the correct incantation. I have tried sending an empty message to updates+unsubscribe(a)lists.opensuse.org updates+leave(a)lists.opensuse.org but both messages are waiting for the list admin to approve, which doesn't seem right. ISTR a long time ago, list messages always included a footer or sig section that contained this information. -- Bob Williams No HTML please. Plain text preferred. https://useplaintext.email/

2 2

apparmor warning about /usr/share/apparmor/cache
by mh＠mike.franken.de 09 Jan '23

09 Jan '23

Hi *, starting with Tumbleweed snapshot 20230105 I get apparmor.systemd[978]: Warning from stdin (line 1): Cache: failed to add read only location '/usr/share/apparmor/cache', does not contain valid cache directory for the specified feature set on apparmor start, and indeed /usr/share/apparmor/cache does not exist, but also didn't exist before. Any hint? TIA. Bye. Michael.

3 3

QT6 Charts devel files
by Jogchum Reitsma 09 Jan '23

09 Jan '23

Hi, Trying to compile a Qt6 Charts application, I see that the Qt6 Charts header files are missing. I've installed QT6Charrts, but I can't find the corresponding -devel package in Yast. There are a lot less include dirs in qt6 compared with qt5: l /usr/include/qt6 | wc -l 38 l /usr/include/qt5 | wc -l 57 How can I get the missing -devel files? best regards, Jogchum

1 1

15.4 kernel 5.14.21-150400.24.38-default not usable on OS/2 LAN
by Felix Miata 08 Jan '23

08 Jan '23

5.14.21-150400.24.38-default boots, but I can't use it, because OS/2 connectivity is a must. 5.14.21-150400.24.33-default solves the problem, keeps OS/2 connected. What changed this time? The vers=1.0 hit in the error message doesn't seem could apply, since it's already being used: /etc/fstab includes: //os2/G /smbmnt/os2/G cifs ro,credentials=/etc/samba/os2.cred,noserverino,sec=lanman,vers=1.0,servern=OS2,domain=PEERS,port=139,dir_mode=0555,file_mode=0664,noauto 0 0 # alias | grep mountos2 alias mountos2='mount //os2/G' # mountos2 mount error: Server abruptly closed the connection. This can happen if the server does not support the SMB version you are trying to use. The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0. mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) With the older kernel and working as expected, the journal contained the following: ## kernel 24.33 - OK # journalctl -b | grep -i -C3 cifs > Jan 01 03:47:59 at-spi-bus-launcher[1378]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:48:06 kernel: FS-Cache: Loaded Jan 01 03:48:06 kernel: Key type dns_resolver registered Jan 01 03:48:06 kernel: FS-Cache: Netfs 'cifs' registered for caching Jan 01 03:48:06 kernel: Key type cifs.spnego registered Jan 01 03:48:06 kernel: Key type cifs.idmap registered Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\E Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\G Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\I Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\J Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 ... Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 ... Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 With the 5.14.21-150400.24.38 kernel, I get the following excerpts instead from a full journal at https://susepaste.org/29524759 : Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:53 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:36:00 systemd[1]: Starting Cleanup of Temporary Directories... Jan 01 03:36:00 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. Jan 01 03:36:00 systemd[1]: Finished Cleanup of Temporary Directories. Jan 01 03:37:57 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:37:59 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:13 systemd-logind[843]: New session 3 of user root. Jan 01 03:38:13 systemd[1]: Started Session 3 of User root. Jan 01 03:38:13 kdm[1021]: :0[1021]: pam_unix(xdm:session): session opened for user root by (uid=0) -- Jan 01 03:38:16 at-spi-bus-launcher[1499]: dbus-daemon[1499]: Successfully activated service 'org.a11y.atspi.Registry' Jan 01 03:38:16 at-spi-bus-launcher[1516]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:38:37 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:39 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:46:41 kdm[1021]: :0[1021]: pam_unix(xdm:session): session closed for user root Jan 01 03:46:41 at-spi-bus-launcher[1516]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Jan 01 03:46:41 at-spi-bus-launcher[1516]: after 157 requests (157 known processed) with 0 events remaining. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

5 5

DRM does not support specified resolution for console any longer
by mh＠mike.franken.de 07 Jan '23

07 Jan '23

Hi *, for a while now I get kernel: i915 0000:00:02.0: [drm] User-defined mode not supported: "1600x1200": 60 160961 1600 1704 1880 2160 1200 1201 1204 1242 0x20 0x6 on system boot. video=1600x1200 at the kernel command line stopped working from this time on. System is Operating System: openSUSE Tumbleweed 20230106 Kernel Version: 6.1.3-1-default (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15,0 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Manufacturer: Dell Inc. Product Name: XPS 13 9310 2-in-1 This leads to a very small, i.e. unreadble console font size. What am I doing wrong or what do I have to change to get this working again? TIA. Bye. Michael.

1 0

Firefox moves window to the current desktop when opening links
by ASSI 06 Jan '23

06 Jan '23

Since one of the updates from around the holidays Firefox has started to move the whole window to the current desktop (KDE Plasma / kwin5) when I click on a link (e.g. in Emacs) instead of just opening a new tab where I put it. How do I get the old behaviour back? Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

7 9

Does /etc/environment still work after the latest update?
by Fusion Future 06 Jan '23

06 Jan '23

I once found /etc/environment was renamed to /etc/environment.rpmfile or something after a recent update, and even after renaming the file back to /etc/environment, environment variables still do not take effect.

4 7

15.4 kernel 5.14.21-150400.24.38-default not usable
by Felix Miata 02 Jan '23

02 Jan '23

5.14.21-150400.24.38-default boots, but I can't use it, because OS/2 connectivity is a must. 5.14.21-150400.24.33-default solves the problem, keeps OS/2 connected. What changed this time? The vers=1.0 hit in the error message doesn't seem could apply, since it's already being used: /etc/fstab includes: //os2/G /smbmnt/os2/G cifs ro,credentials=/etc/samba/os2.cred,noserverino,sec=lanman,vers=1.0,servern=OS2,domain=PEERS,port=139,dir_mode=0555,file_mode=0664,noauto 0 0 # alias | grep mountos2 alias mountos2='mount //os2/G' # mountos2 mount error: Server abruptly closed the connection. This can happen if the server does not support the SMB version you are trying to use. The default SMB version recently changed from SMB1 to SMB2.1 and above. Try mounting with vers=1.0. mount error(112): Host is down Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) With the older kernel and working as expected, the journal contained the following: ## kernel 24.33 - OK # journalctl -b | grep -i -C3 cifs > Jan 01 03:47:59 at-spi-bus-launcher[1378]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:48:06 kernel: FS-Cache: Loaded Jan 01 03:48:06 kernel: Key type dns_resolver registered Jan 01 03:48:06 kernel: FS-Cache: Netfs 'cifs' registered for caching Jan 01 03:48:06 kernel: Key type cifs.spnego registered Jan 01 03:48:06 kernel: Key type cifs.idmap registered Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\E Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\G Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\I Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 Jan 01 03:48:06 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:48:06 kernel: CIFS: Attempting to mount \\mazda\J Jan 01 03:48:06 kernel: CIFS: VFS: Send error in QFSAttributeInfo = -95 ... Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:54:04 kernel: CIFS: VFS: Invalid date, month 0 day: 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 03:58:04 kernel: CIFS: VFS: bogus file nlink value 0 ... Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 Jan 01 04:18:25 kernel: CIFS: VFS: bogus file nlink value 0 With the 5.14.21-150400.24.38 kernel, I get the following excerpts instead from a full journal at https://susepaste.org/29524759 : Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:23:52 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:52 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:52 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:23:53 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:23:53 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:23:53 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:36:00 systemd[1]: Starting Cleanup of Temporary Directories... Jan 01 03:36:00 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully. Jan 01 03:36:00 systemd[1]: Finished Cleanup of Temporary Directories. Jan 01 03:37:57 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:57 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:37:58 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:37:58 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:37:58 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:37:59 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:13 systemd-logind[843]: New session 3 of user root. Jan 01 03:38:13 systemd[1]: Started Session 3 of User root. Jan 01 03:38:13 kdm[1021]: :0[1021]: pam_unix(xdm:session): session opened for user root by (uid=0) -- Jan 01 03:38:16 at-spi-bus-launcher[1499]: dbus-daemon[1499]: Successfully activated service 'org.a11y.atspi.Registry' Jan 01 03:38:16 at-spi-bus-launcher[1516]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Jan 01 03:38:37 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:37 kernel: CIFS: Attempting to mount \\os2\E Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\G Jan 01 03:38:38 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:38 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:38 kernel: CIFS: Attempting to mount \\os2\I Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:38:39 kernel: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: VFS: Use of the less secure dialect vers=1.0 is not recommended unless required for access to very old servers Jan 01 03:38:39 kernel: CIFS: Attempting to mount \\os2\J Jan 01 03:38:39 kernel: CIFS: VFS: cifs_mount failed w/return code = -112 Jan 01 03:46:41 kdm[1021]: :0[1021]: pam_unix(xdm:session): session closed for user root Jan 01 03:46:41 at-spi-bus-launcher[1516]: XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0" Jan 01 03:46:41 at-spi-bus-launcher[1516]: after 157 requests (157 known processed) with 0 events remaining. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

1 0