Thank you for your thorough explanations, I think I understand that and I agree fully. But I have 2 remarks:

1) About the major kernel version mismatch in combination to Ubuntus dkms packages: Ubuntu 16.10 Yakkety ships kernel 4.8 and a working dkms package for this kernel. And liquorix ships kernel 4.8, too. According to your explanation this means such an incompatibility as you describe is no issue here, but your words sound as if that would be an issue.

2) Regarding support for feature releases (or short term releases as you call them) only: Ubuntu 16.10 Yakkety is no LTS version, it's the latest feature release. So according to your explanation, I run the best version to use Liquorix, but your words sound as if the distribution version is the problem.

I can't explain these discrepancy. Can you dig into that?
Back to top

No, you misunderstood. What I'm explaining is the overall situation.

In about 2 months your ubuntu release will still have 4.8, but liquorix will be on 4.9.

At no point is liquorix compatibility with distro dkms packaged drivers a given, that's impossible since damentz has no way of knowing what distros do in their packaging of drivers in dkms packages.

The core assumption you're making about a package made specifically for the ubuntu kernel working with liquorix is the actual question, and that assumption is simply not correct.

If you ran say, sgfxi, then you'd never be aware of this issue. Or if you installed the nvidia driver directly from nvidia, which is what sgfxi does as well, and selected the dkms option, then that would work as expected, until the kernel version changed, and maybe didn't work with the old driver, at which point, you'd install the new driver once it was released.

I believe the ubuntu release cycle is 6 months, thus, there will be between 1 and 2 major kernel versions released within any short term ubuntu release, and this is why the dkms driver is NEVER a real option, though there are many releases, well, ok, not many, some, where nvidia driver has worked on 2 major kernel releases after initial release, but that is a coincidence in general, it just means that the kernel guys didn't break the apis needed by the driver, something they take perverse joy in doing.

Your flaw is believing the dkms package in ubuntu made for the ubuntu kernel has any necessary connection to the liquorix kernel, that's simply not correct.

I think even ubuntu has some non free driver installer, though they seem to come and go with some regularity, but usually they have one, and if it's properly maintained, and gets new drivers promptly, that would also work, though I wouldn't put money on it, sgfxi will generally 'just work' as well, as long as the current nvidia for the card version supports the current linux kernel.

This is really a simple point, and not that hard to understand once you grasp that a dkms package is made for a kernel, the two are one thing, with two parts. You can't use half of that one thing out of context, that's not how it works.

And none of this has anything really to do with damentz deciding to implement or not implement these specific flags, that is literally totally unrelated technically, since the issues I point to here do not change one iota in that case, dkms still is not a viable option if you use the ubuntu dkms packaged nvidia driver with liquorix, though that will work at times but then not work later, or whatever. At which point you'd use a direct installed driver and go on your happy way.

As the sgfxi developer, I can assure you, I've used cutting edge kernels and nvidia drivers installed via sgfxi for about 10 years now, and the few times I don't run new kernels is because there is no nvidia support for them in their current release, or legacy releases, then I wait until there is support to install a new kernel. Same goes for laptops and kernels and suspend support, which comes and goes with various kernel releases.
Back to top

Yes, now I understand, thank you. You reject the dkms system in general. And you have good reasons for that. Which in my opinion just do not apply for the problem we have here.

But there is an easy way to go on without agreeing on dkms in any way: I just don't use it to make my point clear.

fails. The nvidia-installer.log says:



full log: pastebin.com/tCYZhsmd

It works fine when using the ubuntu kernel.
Back to top

What's different between Ubuntu's kernel and Liquorix is a configuration option that's preventing the nvidia module being built without any overriding options. You could say that Debian is the one that is papering over this issue by changing the build flags of the nvidia build configuration, or nvidia is at fault for not keeping up to date with the latest GCC switches.

Apparently Ubuntu was aware of this recent change in GCC and has a wiki describing all the packages that were to break when they changed their toolchain and default options: wiki.ubuntu.com/SteveBeattie/PIENotes.

@techAdmin, I'll have to disagree with you on DKMS. At this point, there is no real implementation differences between Debian and Ubuntu on DKMS modules and how they build.

Labelling DKMS as part of the problem is a red herring, when in fact, DKMS is huge win for convenience and predictability. It literally is just a mechanism to rebuild modules for kernel whenever they change so the user doesn't have to. By ignoring this feature, you're crippling the advantages that sgfxi brings. In fact, I've been installing nvidia drivers by hand for the last year because DKMS is not enabled.

The real problem is that Ubuntu may ship outdated packages - with Ubuntu 16.10, they're briefly in sync with what Debian Unstable ships. So that's not the issue, the configuration of Liquorix is preventing builds of untampered nvidia drivers.

@windseeker, I'm interested if there was an option I enabled when I migrated the configuration from 4.7 to 4.8 that broke nvidia builds from the raw package. I'll review the changes again and compare against Ubuntu's 4.8 kernel if needed to find out what I need to turn off or on. Liquorix is not a security kernel, it's performance, so if I have to reduce security to increase interoperability, I'll so do if it doesn't harm the usage of non production type systems (desktops, laptops).
Back to top

I'm able to confirm that the Ubuntu 4.8 kernel can build the raw nvidia package without any modification or patches. I think this patch specifically is what makes this work: kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc2/0002-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch

I'm going to try a new spin and see if I can replicate this success on Debian. Yesterday I tried building the raw nvidia package myself too and I had to hadd the -fno-pie switch to make it work.
Back to top

@windseeker, could you try the latest kernel that just got pushed out? (4.8-3 / 4.8.0-3.1)

Through my own non-comprehensive tests, I built the latest nvidia driver (375.10) without needing to apply any patches or custom build flags. Changelog is on the tagged release: github.com/damentz/liquorix-package/releases/tag/4.8-3
Back to top

Thank you so much! dkms build works like a charm with unmodified module sources and the resulting module works great for me
Back to top