Cuda on Notebook

Tried a new version of the multi-user.target commands:

systemctl set-default multi-user.target
systemctl reboot

zypper rm suse-prime
zypper in -f <your nvidia rpms>
zypper rm suse-prime
systemctl set-default graphical.target
systemctl reboot

Same failure: I guess I’m selecting too much things to be reinstalled and that leads to the “suse-prime forced comeback” (even though it is clearly removable so not necessary for those packages). Will give a new shot and come back in a few time

Moreover, answering your last message:

~> sudo /sbin/lspci -nnk | grep -EA3 "VGA|Display|3D"
00:02.0 VGA compatible controller [0300]: Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] [8086:3e9b]
        Subsystem: Acer Incorporated [ALI] Device [1025:1264]
        Kernel driver in use: i915
        Kernel modules: i915
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107M [GeForce GTX 1050 Mobile] [10de:1c8d] (rev a1)
        Subsystem: Acer Incorporated [ALI] Device [1025:1265]
        Kernel modules: nouveau, nvidia_drm, nvidia
01:00.1 Audio device [0403]: NVIDIA Corporation GP107GL High Definition Audio Controller [10de:0fb9] (rev a1)

As always, the damn nouveau river keeps on being installed, referenced and the first on the line… ouch! :frowning:

@johannesrs I suspect that hardware wants suse-prime, so if you install that and run the suse-prime tests and see what happens…

https://en.opensuse.org/SDB:NVIDIA_SUSE_Prime

Tried, but there is no xorg.conf on my system (what does not make any sense at all for me)… :frowning:

As a consequence, despite the commands issued I just loged out and in and there are no changes…

@johannesrs and you got rid of all the files indicated in the procedure?

What were the outputs from the commands, prime-select etc?

Ok, I forgot to remove the files in xorg.conf.d, so unninstalled, removed and installed again: no help. :frowning:

No changes after logouts and logins:

~> ll /etc/prime
total 8
-rw-r--r-- 1 root root 7 out 23 18:15 boot
-rw-r--r-- 1 root root 9 out 23 18:15 user
johannes@localhost:~> ll /etc/prime /etc/X11 /etc/X11/xorg.conf.d
/etc/prime:
total 8
-rw-r--r-- 1 root root 7 out 23 18:15 boot
-rw-r--r-- 1 root root 9 out 23 18:15 user

/etc/X11:
total 32
drwxr-xr-x 1 root root  428 out 19 07:54 xdm
-rw-r--r-- 1 root root 7003 mai 25  2018 xim
drwxr-xr-x 1 root root    8 out 19 07:48 xim.d
drwxr-xr-x 1 root root   78 set 19 14:17 xinit
-rw-r--r-- 1 root root 1353 mai 25  2018 Xmodmap
-rw-r--r-- 1 root root 1049 mai 25  2018 Xmodmap.remote
-rw-r--r-- 1 root root  530 out 19 23:33 xorg.conf.bz2
drwxr-xr-x 1 root root  134 out 23 18:13 xorg.conf.d
-rw-r--r-- 1 root root  219 out 19 08:06 xorg.conf.install.bz2
-rw-r--r-- 1 root root   14 out 19 23:33 xorg.conf.nvidia-xconfig-original.bz2
-rw-r--r-- 1 root root 4017 abr 22  2009 Xresources

/etc/X11/xorg.conf.d:
total 16
-rw-r--r-- 1 root root 406 out 19 08:09 00-keyboard.conf
-rw-r--r-- 1 root root 385 jul  1  2011 50-device.conf.bz2
-rw-r--r-- 1 root root 527 jul  1  2011 50-monitor.conf
-rw-r--r-- 1 root root 352 jul  1  2011 50-screen.conf.bz2
~> sudo prime-select boot nvidia
Default at system boot: nvidia
~> xrandr --listproviders
Providers: number : 1
Provider 0: id: 0x42; cap: 0xf (Source Output, Sink Output, Source Offload, Sink Offload); crtcs: 3; outputs: 1; associated providers: 0; name: modesetting
    output eDP-1
~> glxinfo | grep 'OpenGL renderer string'
OpenGL renderer string: Mesa Intel(R) UHD Graphics 630 (CFL GT2)

There should be additional files at the /etc/prime as well as at /etc/X11 and the conf.d directory, shouldn’t it?

@johannesrs It seems to me the whole nouveau not being blacklisted is the issue… why that is, have no idea…

@johannesrs The only other test would be to dump the rpm version and use the run file…

That’s all I ever use here on Tumbleweed…

It is a shame if necessary: it worked with bumblebee and 15.2 from the repos here, and with only the dgpus (no igpus on the work computers) at work…

I’ll give it a try however, before trying a new clean install gain. I’ll keep you posted! :slight_smile:

I can personally tell you that " Cuda + Nvidia + bumblebee + codecs “safe” way" works until Kernel 6 with recent TW.
Unfortunately I am way too busy at a new job to update the docs but I would love to see someone supporting bumblebee again.

Hi @SJLPHI , how are you?

Really? Gosh, I took my conclusions from your posts over there:

Those two were decisive for me and made me conclude that without major changes to the recipe it would not work. In the end, from the user PoV, optirun is simpler than __NV_PRIME_RENDER_OFFLOAD=1 __NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0 __GLX_VENDOR_LIBRARY_NAME=nvidia…

@malcolmlewis, first of all sorry for the time to answer you back this time. The idea of using the hard way worked in the end. The drawback still was that as I can’t deactivate secure boot on the bios, the installer complained about the unsigned driver and refused to install.

Unfortunately, I did not find an option for the cuda installer create a pair of keys to me, so I ended up having to accept to disable mokutil. It worked afterwards, but at the ugly price of having the boot informing twice about having an insecure system at boot time. :frowning:

How can I get rid of that message? How could I have generated the pair keys in a simple way?

Thank you for all help!

Best regards

@johannesrs See here for signing: https://download.nvidia.com/XFree86/Linux-x86_64/545.23.06/README/installdriver.html the whole document is worth a read, not just this section…

I am doing well, just getting beaten in a software engineer job haha. To be clear, the the method only works within Kernel 5. Does not work yet in Kernel 6 without someone investing time into it. Unfortunately I do not have the time to do this.

Also I still never got around to successfully running Prime. For signing @malcolmlewis is referring to the page if you manually installed Nvidia driver, if you used the repo you may wanto refer to UEFI (Unified Extensible Firmware Interface) | Reference | openSUSE Leap 42.1 section 14.1.3 and drivers.suse.com usage

I guarantee you that you will clutter up your EFI partition because it’s a bit tricky and takes some experience, just be sure you provision for breaking the system before trying.

Hi @malcolmlewis and @SJLPHI !

Yes, I found that instructions (I think the opensuse official help pages are even better: SDB:NVIDIA_the_hard_way:Installing_NVIDIA_with_Secure_Boot), however it seems to apply just for the nvidia driver “installator” itself, and not for the cuda “installator” (that installs the driver by default): I don’t find a way to pass such instructions in the last one.

It is not “bad”, but it is most definitely “ugly”.

So many details that make worder and hope you are right and that:

really happens in some way that we can keep the discrete cards. :wink:

Also, as I mentioned I tried too hard to install it from the repos on 15.5, so I gave up for the hard way (that worked in the first attempt provided that I disabled the mok, which is an ugly solution).

So no ideas on how to get rid of the “unsecure” messages on boot? At least not having to deal with two different “installators”, cuda and driver?

You can just sign the final kernel using the methods in my link. It’ll get rid of the messages, better yet you can boot secure boot.

I was looking at then, and they seem quite similar to what I found here: SDB:NVIDIA_the_hard_way#Installing_NVIDIA_with_Secure_Boot.

I stillhave some worries:

  1. the instructions are for the nvidia driver “installator”, and not for the cuda “installator” (that calls for the “internally available” driver “installator”): the flags to tell it to “automagically” generate the keys are definitelly not available, and I’m quite certain that the ones to just pass the keys to the “installators” are also unavailable in the cuda “installator”;

  2. I currently have an unsigned driver and mok disabled. Is it possible for me to generate those keys, import them and just then reactivate mok to lower the possibility of any issues?

Any of those being too much “unideal” and I have to learn to live with those messages.

Thanks a lot in advanc to you two (@malcolmlewis and @SJLPHI ) for all th help provided! :slight_smile:

@johannesrs Hi just extract the run file and use command line switches, as your user run ./cuda_12.3.0_545.23.06_linux.run --help to see :wink: Or just extract, run the installer and don’t install the driver and then manually install the driver with required options.

Hi @malcolmlewis , I’m almost (at work with other issues right now) certain that I looked in the cuda installer (not “installator”, finally remembered the correct word) help and did not find anything.

I was thinking the other way around, unninstall everything, then install just the driver and later only the cuda. But isn’t that too risky of once again having a system without either (it took a long time to get to the actual state)? And also, how can I run the driver installer only from the downloaded cuda installer? Is there a way to extract it from there, so I can “simply” issue the same options as in SDB:NVIDIA_the_hard_way:Installing_NVIDIA_with_Secure_Boot for newer driver versions?

Thanks a lot! :slight_smile:

@johannesrs So, you extrat the file thus (as your user);

mkdir extracted_cuda
./cuda_12.3.0_545.23.06_linux.run --extract=$(pwd)/extracted_cuda/
cd extracted_cuda
ls NV*
NVIDIA-Linux-x86_64-545.23.06.run

So you can just use the above run file (at multi-user.target) to install manually…

You can either stick with that version (re-install after a kernel update), or just use the nvidia-installer to update (no reboot/restart X required now [new feature]) if want to move to a later version with the current cuda install.

Hi @malcolmlewis !

Ok, extracting it now, then I’ll uninstall the actual cuda and nvidia drivers and reactivate mok.

After that, install the driver and afterwards only cuda, right?

Btw, so now there is no more signing over and over again due to new driver and/or kernel versions?? Really??

@johannesrs Hi, no just install the driver with the required options from multi-user.target…

Pass on the re-sign, I suspect probably, I don’t see a need for it here on a desktop, give me physical access to a machine and all bets are off…