When Will Opensuse Use DKMS?

Looking at the posts here in the past week, there are several users who’ve had ATI drivers broken by the latest kernel updates. This kind of thing is killing Linux adoption. It’s not just slowing it, it’s killing it.

I speak from experience, helping people install Linux on their own machines in the past. If they have NVidia, that’s bad enough, but it can be addressed by using the One-Click from the Build service. (Also, while I’m on the “soapbox,” when we give advice here, we really, really need to steer people to that, rather than download-and-build or download and “zypper,” because it DOES help address kernel update issues.)

The reason why this is in Soapbox is because it is, by definition, a “strong opinion.” Folks, if someone installs OpenSuse and gets it working, only to have it die the first time they do a security update, that ain’t exactly a strong recommendation.

I’m able to figure these things out, and to eventually get them working, but for a while there – honestly – I’d whimper when I’d see “Updates Available” pop up with a kernel update. The build service has solved that for me with NVidia, but it apparently hasn’t done so with ATI.

DKMS is supposed to be the answer, but I’m surprised that more distros don’t support it by default. For those who don’t know, Dynamic Kernel Module Support supposedly rebuilds any needed drivers for you anytime there’s a kernel update. That would solve a lot of problems, assuming that it lives up to its promise. But I hope the Opensuse (and other distro developers) are taking a serious look at a solution for this.

I have not looked into DKMS, but that sounds like it would really be a step in the right direction if they can make it work.

You’re right. Something has to be done. Most users do not want to run the open source drivers, but every time a new kernel update breaks their system, we lose users. This is not acceptable. As a more advanced user, I can always fix my system after an update, but it’s a pain in the butt and why should we have to suffer through that every time? I applaud the kernel team’s work and they are constantly putting out new versions with more features and support, but I dread seeing one in my updates. I have other things I would rather do with my time than fix my video drivers.

Precisely. At this point, we usually get other arguments, like: “I don’t care how widely Linux is adopted,” or “Linux isn’t competing with Windows/MAC/whatever, it’s just a good F/OSS alternative …”

The problem is, at present, NVidia says that only about 5% of their downloads are for Linux. (I don’t have figures for ATI.) Especially in a weak economy, it’s hard for a business to justify throwing developers at a problem for that small of a market share. So, it’s a chicken-and-egg scenario: Linux will never been widely adopted on desktops until it can do multimedia, wireless and video without issues, but until it’s widely adopted the vendors don’t have much incentive to give it a lot of support. In fact, it’s possible that the day could come that they just say, “Linux isn’t worth bothering with,” and then where will we be?

DKMS, if it lives up to its billing, looks like a good stopgap measure.

As a more advanced user, I can always fix my system after an update, but it’s a pain in the butt and why should we have to suffer through that every time? I applaud the kernel team’s work and they are constantly putting out new versions with more features and support, but I dread seeing one in my updates. I have other things I would rather do with my time than fix my video drivers.

Well said. I agree with that 100%.

A quick search on software.opensuse.org brings up a result: DKMS. So it would appear that someone using openSUSE has tried DKMS.

Also, there is an openFATE ticket for it located here:
https://features.opensuse.org/308323

So for those that want it included in the distribution, the means for its inclusions are already there, it just needs some momentum.

It’s not all it’s cracked up to be. In fedora, I ended up removing it along with the repo driven drivers for nvidia and just doing it manually.

Oh yes, almost forgot why: Auto update borked the drivers.

Well. That doesn’t sound good. It is in its infancy though. Give it some time and it might turn out to be just what we need. Maybe it needs more people testing it and filing bug reports. Maybe they could use more programming help. I dunno. If it was to mature enough to work, it would go a long way to helping keep those new users running and not running away.:wink:

Maybe. Just maybe, there is a way to code the updater to check a user’s video drivers and the availability of an updated driver and tell the user,

(A) A new video driver is available and will be applied with this kernel update. Would you like to update the kernel?

(B) No video driver is available. If you update your kernel, the open source driver will be applied with the kernel update. Would you like to break the video driver and update the kernel now?

Well, that’s not good. To be fair, maybe the OpenSuse developers haven’t included it yet because it’s not ready. But I will say this – I installed DKMS under CentOS so that I wouldn’t have to rebuild the VirtualBox driver after each kernel update, and so far, it seems to be working fine.

How long ago did you try it with Fedora?

It’s my understanding (and my experience) that if you add the NVidia or ATI repositories to the Software Manager, it does automatically pull in the driver update(s) with the updated kernel. At least, it’s supposed to. It may very well be that all of the broken ATI stuff being posted in the forum lately is because this isn’t happening properly.

(B) No video driver is available. If you update your kernel, the open source driver will be applied with the kernel update. Would you like to break the video driver and update the kernel now?

That may be the best answer, if DKMS won’t work. Maybe if the OpenSuse developers could let us decide which kernel updates to apply? A lot of times, they’re for arcane subsystems that I don’t even use.

In fact, if the updater would just give an easy way to reject a kernel update, without nagging for that particular update in the future, that might solve the problem, at least for more tech-savvy users. I could see that the update is for NFS, for example (which I don’t use) and I could simply decide that I’m not interested.

Possibly not long enough. IIRC there was a kernel update and the updater shouldn’t allow it unless the video driver is in place to match. Trouble was the video driver wasn’t there.

Some advices:

  • If using Fedora and you don’t need top end graphics, just run with the default Nouveau, it is pretty darn good.
  • Don’t run updates as soon as they are available, wait a day or two.
  • Otherwise keep a graphics driver in your /home/user

For me, I just did a console login, then ssh’d in to it and removed the offending packages. Reboot to level 3 and run the nvidia, done.

Alternatively, if there were a way to allow multiple versions to coexist, then if there is a stuff-up, you can at least boot the previous version in GRUB. That might mollify those unfortunates who get a black screen after an update has happened and give them a chance to experiment with fixes. A couple of other distros I use are not as eager and reckless as openSUSE to delete the current kernel package when an update comes out.

I’m told that setting multiversion = <kernel packages> in /etc/zypp/zypp.conf does this but I haven’t had a chance to test this yet.

i investigated that multiversion thing briefly… you can check here:

openSUSE Lizards » Install Multiple Kernel Versions using the YaST Qt Package Manager

i got the multiversion packages from his repo and the appropriate zyppr packages from the zyppr repo and got crashes starting software management (error msgs indicated calling a qt module that was not present).

perhaps you can do better with it ken, i’d agree it would make at least the break-in period for a DKMS implementation a lot less painful.

I think this is fixable, but they have to get the right people on the job. Broken video driver modules have been a problem for years. I have been here since 9.1 and I imagine it has been an issue for longer than that.

When a newbie first installs openSUSE, it pops up and tells him/her that there are updates available. How are they to know that when they let it update, it will leave them stuck at the command line login??? We advance users know this, but they do not. When it happens, what do you think they will do? Format and Reinstall. This is not acceptable.

This is fixable, but the guys and gals that can code it, just look at it as a minor problem. To many of us, it is minor. We can be up and running again in a matter of a few minutes, because we know how to reload our drivers. To a newbie, this is a disaster that they don’t know how to get out of. They go back to Windows, then they show up here and make a post about how openSUSE sucks.

You know what? They’re right. It doesn’t have to be that way. Get a team together and get this fixed. As a bare minimum, just fix it so that it defaults back to the previous version and they still have their desktop. This is an easy fix and could be implemented in a day. Fixing it right could take a week. It has been overlooked and taken for granted for years and there is no excuse for it.

You want the newbies to stop leaving? That’s easy. Fix the basics.:wink:

How would I go about fixing this?

Tomorrow morning is Monday. I would get my coders together for a meeting. Lay it all out and say, “Here is the deal. If this is not fixed by Friday, you are all fired.” I would be willing to bet that they would find a way.lol!

It is interesting that Linux doesn’t have anything like Windows’ “snapshots,” where you can easily roll back an update. (We did one on a production machine just last week; easy as pie.) I realize that most Linux distros are just compilations that are made by a limited number of people, but it still surprises me (as Mr. Phillips points out elsewhere) that this hasn’t been considered a priority.

As a serious, true-blue Linux lover (and of OpenSuse in particular), it just goes all over me when I see so many people in the forum complaining, “Can’t Log In After Update” – and it’s simply because they have ATI or NVidia graphics and updated the kernel.

There’s got to be an answer. If it’s isn’t DKMS, then something like you suggest.

Yes, this is my current hobby horse at the moment. Ubuntu leaves the previous kernels in /boot. RHEL leaves the previous kernels in /boot. Do you think they might be more cautious? Is the pope catholic? Sure, it gets cluttered in /boot after a while, but better to have a beginner ask how can I remove old kernels in /boot rather than openSUSE sux! I’m going back to <whatever>.

(In fact RHEL goes better, it leaves the last N versions around, including the one in use and autoremoves the rest. I assume N is configurable, as these things tend to be.)

From reading the comments in that multiversion thread kindly pointed out to me by j_xavier, proper multiversion support might be in 11.3. One can hope.

So does CentOS (not surprising, since it’s based on RHEL). On those rare occasions when I need to reboot it, the Grub menu can indeed be rather large.

Of course, they have their own bugs, minor things. For example, very occasionally, they’ll forget to reassign some of the symbolic links for the new kernel (in particular, for the kernel source).

But your point is well-said and well-made. If Ubuntu and RH see the problem, why can’t Suse?

From reading the comments in that multiversion thread kindly pointed out to me by j_xavier, proper multiversion support might be in 11.3. One can hope.

One certainly can.

Another thought on this problem.

What if the system was installed with the default setup that would not allow kernel updates? This would keep newbies out of trouble. Have a flag that could be changed in a file to turn this off and on. We would know how to change it and we could do our updates. If a newbie wanted a new kernel, they would have to search for the info to turn the flag off. That info would also warn them that doing the update will have the potential to hose their system.

This way, they would at least know before hand that they might get into trouble and could make the preparations ahead of time.

That might not be a bad idea, given that most updates are for things that newbies neither care about nor even use. Almost by definition, a newbie isn’t going to be running a server, and since Suse activates the firewall by default, kernel updates just aren’t that critical to them.

In fact, just at first glance, that’s a good idea, at least in my opinion. You’d still have updates for Firefox, KDE, and all of the other stuff that the newbie uses; only kernel updates would be skipped.

If and when the user decides that they need a kernel update, they could do a little research and find out how to turn the flag on or off. By that time, they should have enough information to make an informed decision. In fact, the config file that requires editing to turn the flag on or off could have all the info they need. Links to the forums, instructions, what repos they need, etc.

This and a way to fall back to an earlier version, in my opinion, would be a multi-threaded approach and would prevent a lot of problems.

As the old saying goes, “An ounce of prevention is worth a pound of cure.” How many new users would stick with openSUSE if they never had this problem?:wink: