4.16.2 + nvidia

wolfi323 · April 22, 2018, 1:44am

No, that’s done automatically if you install/uninstall a kernel with rpm or zypper.

After you manual uninstall an kernel that is on your boot menu, I think that you need to generate it:
grub2-mkconfig -o /boot/grub2/grub.cfg.

Also this is done automatically if you install/uninstall a kernel with rpm or zypper.

Regarding purge-kernels: this is only run on the next boot after installing a kernel, so it is to be expected that you have 3 kernels installed temporarily until you actually reboot.

If there’s an error when running purge-kernels, please post it for further help.
If you cannot catch it during bootup, run “sudo systemctl status purge-kernels.service”. (you may have to manually start purge-kernels.service though, it is only started automatically on first boot after a new kernel got installed)

A manual cleanup should be fine anyway though.

another_roadrunner · April 22, 2018, 5:08am

Wolfi, maybe I am wrong, but when I clean up my kernels, I remove kernels with zypper and zypper only remove kernel, it not run anything else like when a kernel is installed (mkinird or grub2-mkconfig).
Maybe this happens when the system boot, after a kernel is removed.

enziosavio · April 22, 2018, 9:11am

systemctl status purge-kernels.service

If you look at boot times see that service when installing a new kernel.
I notice because it takes even 30 seconds more, than you have 10 seconds of start normally

another_roadrunner · April 22, 2018, 11:20am

Sorry, but I was talking about manual uninstalling (not installing) a kernel. (post #39 and #40)
So, if I have 2 kernels in my boot, and I delete the second one, I don’t need a mkinitrd and a grub2-mkconfig…?
You said that this service (purge-kernels.service) take care of all?
Sorry, but I would like to understand this process as well.

enziosavio · April 22, 2018, 11:45am

OT)
The Google translator is a broken cart

I write one thing and find another …

another_roadrunner · April 22, 2018, 11:52am

That happened to me too (many times).

wolfi323 · April 22, 2018, 12:02pm

No, this should happen right after the kernel installation/uninstallation.
Just purge-kernels.service would only run on the next boot.

No.

mkinitrd is irrelevant if you uninstall a kernel, as it only recreates/updates the initrd’s for the installed kernels.
If you uninstall a kernel, the initrd will be removed anyway.

grub2-mkconfig should be run whenever a kernel is installed or uninstalled (via rpm or zypper at least) though.

You said that this service (purge-kernels.service) take care of all?

No.
purge-kernels.service is run on first boot after a kernel update (to be precise, it only starts during boot if the file /boot/do_purge_kernels exists, see “systemctl cat purge-kernels.service”), and uninstalls no longer needed kernels (as specified in zypp.conf) via “rpm -e”.
It does not run mkinitrd or grub2-mkconfig at all, but the bootmenu is updated by the kernel packages’ postinstall scripts.

rpm -q --scripts kernel-default

another_roadrunner · April 22, 2018, 12:43pm

Thank you.

After I read your post and the scripts

rpm -q --scripts kernel-default
I think that I undestood (at least more that I knew one hour ago ;)).

another_roadrunner · April 25, 2018, 3:32pm

Kernel 4.16.3 and nvidia “hard way” - no problem.
BTW - with new update - a package was “downgraded” from v.42.3 to version v.15.

wolfi323 · April 25, 2018, 4:22pm

Well, a problem like with the 4.16.2 kernel update is rather the exception than the norm.

BTW - with new update - a package was “downgraded” from v.42.3 to version v.15.

Likely some branding package…

another_roadrunner · April 25, 2018, 5:09pm

I know that. For me TW is rock stable.
Anyway that was a nvidia’s problem not a problem of openSUSE or kernel 4.16.2.
But I have seen how many views had the threads about nvidia and I thought it is a matter of great interest.

That was only a joke. I think this was an automatic message not from a person (and a machine did not know that 42.x > 15 is an upgrade not a downgrade).

wolfi323 · April 25, 2018, 5:17pm

Erm, no.

The problem was that kernel-devel was updated to 4.16.2, but the kernel itself not (because it failed to build). I.e. the snapshot shipped with kernel-devel 4.16.2 and kernel-default 4.16.1, making it impossible to build kernel modules for the new kernel (otherwise this should be rather irrelevant).
That totally was a problem of openSUSE this time.

An nvidia problem is that the last stable release (390.48) does not support kernel 4.16 at all yet.
(Fixed in the latest 396 beta though, and I suppose the next 390.xx release will support it as well)

another_roadrunner · April 25, 2018, 5:26pm

That’s what I mean.
I forgot about the other problem.
For me the most important issue was the first one. Because I learned how to patch it and I moved from “repository way” to “hard way”.

wolfi323 · April 25, 2018, 5:59pm

But this thread was about the “other” problem, no?

For me the most important issue was the first one. Because I learned how to patch it and I moved from “repository way” to “hard way”.

Ok. I just want to mention again here that the openSUSE packages in the nvidia repo do contain a patch and work fine on kernel 4.16 meanwhile (since 2 weeks)…

another_roadrunner · April 25, 2018, 7:06pm

Yes, but I messed things up a bit.
Have you still many bullets left? :shame:
Joke. Do not shoot again.

I know that. But now, after I understand how it works, I prefer to install nvidia in “hard way”. It is not as scary as I thought.

wolfi323 · April 25, 2018, 7:19pm

It was merely an explanation for my previous comment (that it was rather an openSUSE problem)…
I didn’t mean to attack you in any way.

I know that. But now, after I understand how it works, I prefer to install nvidia in “hard way”. It is not as scary as I thought.

And that’s fine.

But other people may read this thread, so I thought it would be a good idea to point that out again.

another_roadrunner · April 25, 2018, 7:25pm

I did not think that at all.

chestnet · April 27, 2018, 1:02am

I am curious what repository URL are you using? I’ve had to install the hard way because the repository I know of is old.

As of


11:00 PM
Thursday, April 26, 2018  
Coordinated Universal Time (UTC)      

http://download.nvidia.com/opensuse/tumbleweed/x86_64/

Index of /opensuse/tumbleweed/x86_64

    ..
    nvidia-computeG03-340.106-12.1.x86_64.rpm 18MB 2018-04-11 14:43
    nvidia-computeG04-390.48-9.1.x86_64.rpm 15MB 2018-04-11 14:43
    nvidia-gfxG03-kmp-default-340.106_k4.16.0_1-12.8.x86_64.rpm 3.6MB 2018-04-11 14:43
    nvidia-gfxG04-kmp-default-390.48_k4.16.0_1-9.1.x86_64.rpm 8.2MB 2018-04-11 14:43
    nvidia-glG03-340.106-12.1.x86_64.rpm 28MB 2018-04-11 14:43
    nvidia-glG04-390.48-9.1.x86_64.rpm 28MB 2018-04-11 14:43
    nvidia-uvm-gfxG03-kmp-default-340.106_k4.16.0_1-12.8.x86_64.rpm 3.6MB 2018-04-11 14:43
    x11-video-nvidiaG03-340.106-12.1.x86_64.rpm 19MB 2018-04-11 14:43
    x11-video-nvidiaG04-390.48-9.1.x86_64.rpm 28MB 2018-04-11 14:43
    _buildenv 16KB 2018-04-11 14:43
    _statistics 4.0KB 2018-04-11 14:43

another_roadrunner · April 27, 2018, 5:26am

As far that I know the repository works.
And 390.48 is the last stable driver from nvidia.
396.18 is beta.
There was a problem with repository and 4.16 kernel but the driver was patched and everything is fine.

PS. 2018.04.11 - is after that problem, and for sure nvidia-computeG04-390.48-9.1.x86_64.rpm is patched.

wolfi323 · April 29, 2018, 12:08am

It’s not “old”.
The last update to the packages was indeed done on Apr. 11th, that was when the patch for Kernel 4.16 has been added.

The kernel version in the kmp packages is irrelevant, the kernel module gets compiled for the current kernel on the system anyway, the kmp packages contain only source code and no binary kernel module (since years actually).

In other words, that repo URL is correct, and the packages should just work.