Thank you for this report.

I have tried to unravel what bits of nVidia require what other bits - in vain.
Nothing seems to require nvidia-nsight, so your comment "is not a requirement" look sensible. (It is in SRPM nvidia-cuda-toolkit).
nvidia-nsight itself only requires Java.

On my system, which has no nVidia:
 $ ls -l /usr/lib64/libcrypto*
 ...
 lrwxrwxrwx 1 root root      14 Meh   1 10:53 /usr/lib64/libcrypto.so -> 
 libcrypto.so.3*
 -rwxr-xr-x 1 root root 3237248 Gor  11  2022 /usr/lib64/libcrypto.so.1.1*
 -rwxr-xr-x 1 root root 4934824 Meh   1 10:53 /usr/lib64/libcrypto.so.3*
 $ urpmf /usr/lib64/libcrypto.so.3
 lib64openssl3:/usr/lib64/libcrypto.so.3
 $ urpmf /usr/lib64/libcrypto.so.1.1
 $
So where the old version came from...

I tried, the system up-to-date:
 $ sudo urpmi --test x11-driver-video-nvidia-current
[chose kernel option 1]
  Pecyn                          Fersiwn      Rhifyn        Arch    
(cyfrwng "Core Release")
  dkms                           2.0.19       46.mga9       noarch  
  dkms-minimal                   2.0.19       46.mga9       noarch  
  egl-wayland-json               1.1.11       1.mga9        noarch  
  kernel-desktop-devel           6.3.8        1.mga9        x86_64  
  lib64nvidia-egl-wayland1       1.1.11       1.mga9        x86_64  
  vaapi-driver-vdpau             0.7.4        11.mga9       x86_64  
(cyfrwng "Nonfree Release")
  dkms-nvidia-current            525.116.04   5.mga9.nonfr> x86_64  
  nvidia-current-doc-html        525.116.04   5.mga9.nonfr> x86_64  (argymhellir)
  nvidia-current-utils           525.116.04   5.mga9.nonfr> x86_64  
  x11-driver-video-nvidia-curre> 525.116.04   5.mga9.nonfr> x86_64  
Parhau i osod 10 o becynnau? (Y/n) n

No sign of the bug, but all nVidia references are '525', the bug cites '535'. 
Where did you get that?

BTAIM It looks as if the reference to libcrypto 1.1 is questionable. Unless there are differences between openSSL 1 & 3 which require having both versions of the library.

CC: (none) => lewyssmith
Source RPM: nvidia-current-535.54.03-1.mga9.nonfree.src.rpm => nvidia-current-535.54.03-1.mga9.nonfree.src.rpm, nvidia-cuda-toolkit-12.1.1-1.mga9.nonfree.src.rpm

/usr/lib64/libcrypto.so.1.1 is from lib64openssl1.1-1.1.1u-1.mga8. I also
can not recreate the problem in a cauldron install.

Juan, please post the output of "urpmq --list-media active" and
"urpmq --list-url".

CC: (none) => davidwhodgins

Just for the record, I am now running dkms-nvidia-newfeature-530.xxx, and want to go to nvidia-current-535.xxx, in nonfree/updates_testing
(btw, siwtching between them is a pain...)

I just tried to install Xorg driver, see what it pulls automagically,
and add manually what not.

werewolf:~# urpmi x11-driver-video-nvidia-current
A requested package cannot be installed:
x11-driver-video-nvidia-current-535.54.03-1.mga9.nonfree.x86_64 (due to unsatisfied libcrypto.so.1.1(OPENSSL_1_1_0)(64bit))
Continue installation anyway? (Y/n) n

BTW, there is no compat ssl lib in Cauldron:
werewolf:~# urpmi lib64openssl1.1
No package named lib64openssl1.1

Info you asked for:

werewolf:~# urpmq --list-media active
Core Release
Core Updates
Core Updates Testing
Core Backports
Core Backports Testing
Nonfree Release
Nonfree Updates
Nonfree Updates Testing
Nonfree Backports
Nonfree Backports Testing
Tainted Release
Tainted Updates
Tainted Updates Testing
Tainted Backports
Tainted Backports Testing
Google Chrome

werewolf:~# urpmq --list-url
Core Release http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/release
Core Updates http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/updates
Core Updates Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/updates_testing
Core Backports http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/backports
Core Backports Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/core/backports_testing
Nonfree Release http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/nonfree/release
Nonfree Updates http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/nonfree/updates
Nonfree Updates Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/nonfree/updates_testing
Nonfree Backports http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/nonfree/backports
Nonfree Backports Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/nonfree/backports_testing
Tainted Release http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/tainted/release
Tainted Updates http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/tainted/updates
Tainted Updates Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/tainted/updates_testing
Tainted Backports http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/tainted/backports
Tainted Backports Testing http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/media/tainted/backports_testing
Google Chrome http://dl.google.com/linux/chrome/rpm/stable/x86_64


TIA.

Assigning to kernel team.

I couldn't find the requires in svn (or the 535 version), but after downloading
the package from nonfree/updates_testing ...
# rpm -q --requires  ./x11-driver-video-nvidia-current-535.54.03-1.mga9.nonfree.x86_64.rpm |grep crypt
libcrypto.so.1.1()(64bit)
libcrypto.so.1.1(OPENSSL_1_1_0)(64bit)
libcrypto.so.3()(64bit)
libcrypto.so.3(OPENSSL_3.0.0)(64bit)

Assignee: bugsquad => kernel

The library with the deps is libnvidia-pkcs11.so.535.54.03; the problem is that we seems no longer have an openssl-1.1, which IMHO is too early. The library
/usr/lib64/libcrypto.so.1.1 seen by Dave comes from package lib64openssl1.1-1.1.1u-1.mga8 which is a mga8 package, so upgrading from mga8 would have that library, but in a fresh mga9 doesn't.

We have an openssl1.1 in the svn, https://svnweb.mageia.org/packages/cauldron/openssl1.1/current/SPECS/openssl1.1.spec?revision=1788096&view=markup, but seems abandoned (to release 1.1l), while the openssl-1.1 in mga8 instead was upgraded to 1.1u.

Probably at some point the compat openssl1.1 broke building and we were no longer providing binaries. What we should do IMHO is merge the openssl-1.1u latest fixes from mga8 into mga9's openssl1.1 and reprovide binaries for it.

CC: (none) => ghibomgx

As a temporary workaround one might install the openssl 1.1 library from mga8's updates, e.g.: https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/media/core/updates/lib64openssl1.1-1.1.1u-1.mga8.x86_64.rpm

I noted this too, tmb comment:
https://ml.mageia.org/l/arc/qa-discuss/2023-06/msg00199.html

CC: (none) => fri

(In reply to Morgan Leijström from comment #7)
> I noted this too, tmb comment:
> https://ml.mageia.org/l/arc/qa-discuss/2023-06/msg00199.html

IMHO the openssl1.1 lib it is just missed from mga9, this either with or without this nvidia problem.

If we would filter the self-requires, adding libcrypto.so.1.1 in %__requires_exclude, since it's a library at /usr/lib64 level, IMHO would break lib deps.

IMHO, once the openssl1.1 (compat) would be restored in mga9, what we can do, as further "refinement", if we really want, would be to split out the single file "libnvidia-pkcs11.so.535.54.03" into a standalone sub-package (e.g. named x11-driver-video-nvidia-compat-openssl11, and adding its Requires to the -all subpackage); in this way it would bring its lib64openssl1.1 deps confined to that package and one could keep its system "lib64openssl1.1 free" in case he wants and when it's not strictly required.

(In reply to Giuseppe Ghibò from comment #6)
> As a temporary workaround one might install the openssl 1.1 library from
> mga8's updates, e.g.:
> https://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/8/x86_64/
> media/core/updates/lib64openssl1.1-1.1.1u-1.mga8.x86_64.rpm

I've rebuilt the lib64openssl1.1-1.1.1u-1.mga9 from openssl1.1 and should be available in core/updates_testing.

Good, using now R535 with that mga9 openssl with my GTX750 :)


Other tests today: Was running R470.  For some reason with R525 nor R530 did no longer work when i tested earlier today (no login GUI)
- but that seem irrelevant now as 535 is to be shipped with mga9 :)

Pretty weird it doesn't work on R470, as last time was working with all 5 drivers (modesetting, nouveau, 470, 525, 530 new). Does it work if you run Xorg from startx starting from init level 3? Or was there some wayland display manager (gdm?) in the middle?

It was running and working great with R470.
This morning I tried 535 but that fell on this then missing openssl.

Then i intended to again verify it works on 530 and 525. But both 530 and 525 failed booting. Yes they worked before but on elder kernel. No idea, but we are leaving both those versions of nvidia, and i dont fancy digging more;

There were some mishaps on the way: drakx11 and possibly me in combination messed something up.  It also does not help that drakx11 in command line mode sometimes think my 4k screen is "too small", and once it crashed with "Cant call method "attron" on an undefined value" yadayada, nor does it help that ctrl-alt-F2 is black (another reported bug) when the GIU login is broken and I intended to check journal and Xorg.log.

Irritated.

Gave up and just switched to R470 using drakx11 from runlevel 1, which did work, and then while booted into Plasma changed to 535 using MCC.

It is working.

Note, that OpenSSL 1.1 is EOL in september 2023
https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/

CC: (none) => linux

Yeah , we wont ship 1.1 in mga9

(In reply to Morgan Leijström from comment #12)
> It was running and working great with R470.
> This morning I tried 535 but that fell on this then missing openssl.
> 
> Then i intended to again verify it works on 530 and 525. But both 530 and
> 525 failed booting. Yes they worked before but on elder kernel. No idea, but
> we are leaving both those versions of nvidia, and i dont fancy digging more;
> 
> There were some mishaps on the way: drakx11 and possibly me in combination
> messed something up.  It also does not help that drakx11 in command line
> mode sometimes think my 4k screen is "too small", and once it crashed with
> "Cant call method "attron" on an undefined value" yadayada, nor does it help
> that ctrl-alt-F2 is black (another reported bug) when the GIU login is
> broken and I intended to check journal and Xorg.log.

IMHO with respect to last week (last working bins from 9 Jun) there is a regression somewhere here introduced with latest upgrades. Probably it is another bug, but I spotted the 'attron' report too, and also seems that systemd graphical.target doesn't work well anymore (while startx does). I don't think it's kernel related as I spotted also on kernels older than current. I wonder if that could be related to the libraries we recently stripped from xorg-server because declared unsupported upstream.

(In reply to Giuseppe Ghibò from comment #15)
> (In reply to Morgan Leijström from comment #12)
> > It was running and working great with R470.
> > This morning I tried 535 but that fell on this then missing openssl.
> > 
> > Then i intended to again verify it works on 530 and 525. But both 530 and
> > 525 failed booting. Yes they worked before but on elder kernel. No idea, but
> > we are leaving both those versions of nvidia, and i dont fancy digging more;
> > 
> > There were some mishaps on the way: drakx11 and possibly me in combination
> > messed something up.  It also does not help that drakx11 in command line
> > mode sometimes think my 4k screen is "too small", and once it crashed with
> > "Cant call method "attron" on an undefined value" yadayada, nor does it help
> > that ctrl-alt-F2 is black (another reported bug) when the GIU login is
> > broken and I intended to check journal and Xorg.log.
> 
> IMHO with respect to last week (last working bins from 9 Jun) there is a
> regression somewhere here introduced with latest upgrades. Probably it is
> another bug, but I spotted the 'attron' report too, and also seems that
> systemd graphical.target doesn't work well anymore (while startx does). I
> don't think it's kernel related as I spotted also on kernels older than
> current. I wonder if that could be related to the libraries we recently
> stripped from xorg-server because declared unsupported upstream.

I exclude xorg-server too. So looking elsewhere...

(In reply to Giuseppe Ghibò from comment #8)
> (In reply to Morgan Leijström from comment #7)
> > I noted this too, tmb comment:
> > https://ml.mageia.org/l/arc/qa-discuss/2023-06/msg00199.html
> 
> IMHO the openssl1.1 lib it is just missed from mga9, this either with or
> without this nvidia problem.
> 
> If we would filter the self-requires, adding libcrypto.so.1.1 in
> %__requires_exclude, since it's a library at /usr/lib64 level, IMHO would
> break lib deps.
> 
> IMHO, once the openssl1.1 (compat) would be restored in mga9, what we can
> do, as further "refinement", if we really want, would be to split out the
> single file "libnvidia-pkcs11.so.535.54.03" into a standalone sub-package
> (e.g. named x11-driver-video-nvidia-compat-openssl11, and adding its
> Requires to the -all subpackage); in this way it would bring its
> lib64openssl1.1 deps confined to that package and one could keep its system
> "lib64openssl1.1 free" in case he wants and when it's not strictly required.

An alternative solution to avoid shipping a library with a dependency to openssl1.1 that at some point would be retired, could be to soft link libnvidia-pkcs11.so.535.54.03 to libnvidia-libnvidia-pkcs11-openssl3.so.535.54.0 which is not linked to openssl1.1 but to openssl-3.0.

(In reply to Giuseppe Ghibò from comment #15)
> also seems that
> systemd graphical.target doesn't work well anymore (while startx does)

After I recently read that startx is the "old" way, i tried systemd graphical.target, which did not work, but telinit 5 brought me to graphical login.

(In reply to Morgan Leijström from comment #18)

> (In reply to Giuseppe Ghibò from comment #15)
> > also seems that
> > systemd graphical.target doesn't work well anymore (while startx does)
> 
> After I recently read that startx is the "old" way, i tried systemd
> graphical.target, which did not work, but telinit 5 brought me to graphical
> login.

I've an installation where this doesn't happens anymore. Last week was starting the graphical login now no longer, nor with telinit 5, or init 5 after having moved to init 3, after latest round of updates, including those of updates_testing, even preserving the older nvidia driver (so it's not the nvidia driver, nor the kernel). Now the system appears weaker, and only way is to startx, so there is something hidden.

(In reply to Giuseppe Ghibò from comment #17)
> (In reply to Giuseppe Ghibò from comment #8)
> > (In reply to Morgan Leijström from comment #7)
> > > I noted this too, tmb comment:
> > > https://ml.mageia.org/l/arc/qa-discuss/2023-06/msg00199.html
> > 
> > IMHO the openssl1.1 lib it is just missed from mga9, this either with or
> > without this nvidia problem.
> > 
> > If we would filter the self-requires, adding libcrypto.so.1.1 in
> > %__requires_exclude, since it's a library at /usr/lib64 level, IMHO would
> > break lib deps.
> > 
> > IMHO, once the openssl1.1 (compat) would be restored in mga9, what we can
> > do, as further "refinement", if we really want, would be to split out the
> > single file "libnvidia-pkcs11.so.535.54.03" into a standalone sub-package
> > (e.g. named x11-driver-video-nvidia-compat-openssl11, and adding its
> > Requires to the -all subpackage); in this way it would bring its
> > lib64openssl1.1 deps confined to that package and one could keep its system
> > "lib64openssl1.1 free" in case he wants and when it's not strictly required.
> 
> An alternative solution to avoid shipping a library with a dependency to
> openssl1.1 that at some point would be retired, could be to soft link
> libnvidia-pkcs11.so.535.54.03 to
> libnvidia-pkcs11-openssl3.so.535.54.0 which is not linked to
> openssl1.1 but to openssl-3.0.

I found a better solution for this problem. In fact linking libnvidia-pkcs11.so to libnvidia-pkcs11-openssl3 might not work if the application linked against  libnvidia-pkcs11.so (linked against libcrypt.so.1.1) is using something not provided anymore in libcrypto.so.3. Instead I splitten the libnvidia-pkcs11.so in a subpackage, so the openssl1.1 dependency goes in the subpackage. In this way we can either:

a) provide the libnvidia-pkcs11.so for backward compatibility. The lib64openssl1.1 might be inherited from previous mga8 distro (or elsewhere is case of needing).

b) lib64openssl1.1 it's not strictly needed anymore and we can drop the openssl1.1 package.

Attaching the spec diff.

Created attachment 13879 [details]
patch for nvidia-current spec file

Patch for the nvidia-current spec file to split libcrypt.so.1.1 dependency from main package.

Created attachment 13882 [details]
patch for nvidia-current spec file

Patch for the nvidia-current spec file to remove libcrypt.so.1.1 dependency from main package. New version.

This version is simplified. In this new version only one of either the libnvidia-pkcs11.so or libnvidia-pkcs11-openssl3.so is keepen, according to the corresponding libcrypto.so.X (X=1.1 or X=3) availability in the distro. I also added a flag so that it can be easily backported to mga8, just in the case.

(In reply to Giuseppe Ghibò from comment #22)
> Created attachment 13882 [details]
> patch for nvidia-current spec file
> 
> Patch for the nvidia-current spec file to remove libcrypt.so.1.1 dependency
> from main package. New version.
> 
> This version is simplified. In this new version only one of either the
> libnvidia-pkcs11.so or libnvidia-pkcs11-openssl3.so is keepen, according to
> the corresponding libcrypto.so.X (X=1.1 or X=3) availability in the distro.
> I also added a flag so that it can be easily backported to mga8, just in the
> case.

The version actually in nonfree/updates_testing adopted this release, and doesn't require anymore the openssl1.1 package.

(In reply to Morgan Leijström from comment #18)

> (In reply to Giuseppe Ghibò from comment #15)
> > also seems that
> > systemd graphical.target doesn't work well anymore (while startx does)
> 
> After I recently read that startx is the "old" way, i tried systemd
> graphical.target, which did not work, but telinit 5 brought me to graphical
> login.

Apparently sometimes the breakage happens in sddm: when you run in telinit 5, or graphical.target, sddm simply stucks and doesn't start X. If you for instance switch to xdm as display manager, this won't happen and it would work with any nvidia driver again. Haven't yet tried with gdm in this setup.

Probably sddm also requires some refresh (maybe can be synced with FC?) or some bugfix from git upstream, as it's much time it's not upgraded, though it's anyway the latest release 0.19.0.

(In reply to Giuseppe Ghibò from comment #24)

> Probably sddm also requires some refresh (maybe can be synced with FC?) or
> some bugfix from git upstream, as it's much time it's not upgraded, though
> it's anyway the latest release 0.19.0.

Speaking of sddm, apparently sddm-0.20.0 bump was just approved upstream:

https://github.com/sddm/sddm/pull/1734

OK, updated Nvidia to 535.54.03-2 and removed lib64openssl1.1
(no other openssl1.1 package was installed)

----

Per Comment 24 & 25 it smells to me it would be interesting to try sddm-0.20.0 in testing if not too much work, but probably not release it in mga9 yet, per comments on wayland in that link in comment 25.  Plasma wayland is unusable currently, as always, for some folks like me, anyway, still... :/

(In reply to psyca from comment #13)
> Note, that OpenSSL 1.1 is EOL in september 2023
> https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
(In reply to Thomas Backlund from comment #14)
> Yeah , we wont ship 1.1 in mga9
In packages to obsolete:
https://bugs.mageia.org/show_bug.cgi?id=30163#c7
"openssl 1.1.1 needs to removed"

It looks as if the problem should not be fixed by carrying forward openSSL1.1.
I have not studied Giuseppe's solutions, but if they ended up with a private library for the nVidia software, that might be OK. Clearly that s/w should be updated for SSL.

I looked in Mageia 8 at what required OpenSSL 1.1, and the list was huge. They must all have been converted to v3 for M9, since before this bug nothing required it any more - to the point where, correctly, it is not present.

(In reply to Lewis Smith from comment #27)

> (In reply to psyca from comment #13)
> > Note, that OpenSSL 1.1 is EOL in september 2023
> > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> (In reply to Thomas Backlund from comment #14)
> > Yeah , we wont ship 1.1 in mga9
> In packages to obsolete:
> https://bugs.mageia.org/show_bug.cgi?id=30163#c7
> "openssl 1.1.1 needs to removed"
> 
> It looks as if the problem should not be fixed by carrying forward
> openSSL1.1.
> I have not studied Giuseppe's solutions, but if they ended up with a private
> library for the nVidia software, that might be OK. Clearly that s/w should
> be updated for SSL.
> 
> I looked in Mageia 8 at what required OpenSSL 1.1, and the list was huge.
> They must all have been converted to v3 for M9, since before this bug
> nothing required it any more - to the point where, correctly, it is not
> present.

The nvidia-current-535.54.03-2.mga9, actually in nonfree/updates_testing/ has the lib64openssl1.1 dep removed now. From what I could see the remaining list of packages in mga9 requiring libopenssl1.1 is actually empty.

(In reply to Morgan Leijström from comment #26)

> 
> Per Comment 24 & 25 it smells to me it would be interesting to try
> sddm-0.20.0 in testing if not too much work, but probably not release it in
> mga9 yet, per comments on wayland in that link in comment 25.  Plasma

A quick build for upcoming sddm-0.20.0 is actually here (outside of core/updates-testing):

https://copr-be.cloud.fedoraproject.org/results/ghibo/mageia9-bonus/mageia-cauldron-x86_64/06097855-sddm/

> wayland is unusable currently, as always, for some folks like me, anyway,
> still... :/

You mean Plasma over Wayland in general, or Plasma over Wayland over nvidia?

The little experience i have, nvidia makes it worse.

May try that sddm later :)

Using that sddm-0.20.0 now :)
I will report any problems.

nvidia-current-535.54.03-2.mga9 is in release repo

Resolution: (none) => FIXED
Status: NEW => RESOLVED