Hi all,

Ubuntu Yakkety comes with Kernel 4.8 and dkms can rebuild the kernel modules of nvidia and bbswitch just fine on the distribution kernel.

As soon as I want to use Liquorix 4.8-1 or 4.8-2, the kernel build breaks on both modules with "error: code model kernel does not support PIC mode"

I really don't understand what is going on under the hood. I can build the modules if I add to their Makefiles "EXTRA_CFLAGS := -fno-pie -fno-stack-protector", but I don't know why the original Ubuntu kernel does not need that and liquorix needs that. After searching around I think it has something to do with Ubuntu Yakkety using new default compiler flags that enables PIE mode by default.

I wonder if it is possible to change the liquorix kernel in a way that is works on Ubuntu Yakkety without breaking other distributions. There are many background infos between the discussions on bugs.launchpad.net/ubuntu/+source/linux/+bug/1574982 with a kernel patch mentioned on comment #39

I would be happy if somebody with kernel knowhow could take a look if it's feasable to work around this Ubuntu behaviour.

Thank you for your great work!
Back to top

I'm having issues with this too and I'm not really sure how to do what you even did to try to fix it. It would be cool if there were a fix for this too.
Back to top

I don't know how much building knowhow you have, so please forgive me if I am too detailled and tell you things that are obvious to you.

You have to edit the sources of the affected modules. The sources are in /usr/src, like /usr/src/bbswitch-0.8/ or /usr/src/nvidia-340-340.98. There you need to edit either the "Kbuild" file or if that doesn't exist, the "Makefile". Search for a good place like a part where EXTRA_CFLAGS are already set up and below that part you can just add the line

Please note the "+=", this will add your flags to whatever has been set before, so chances are good it won't break anything. Of course take care to not put it into some if clause or such, or maybe it won't add them because that part is skipped.
Then rebuild the module with dkms like for example

The change in modules sources will be overwritten as soon as there is an update installed for this module. After the installation of this update the dkms build will fail again. You then have to re-add the change and rebuild the module again before you reboot.
Back to top

Thank you so much! It worked perfectly. I had no idea how to do that, and the most I've really done was do a basic compile from source, not something that complex. Thanks for the thorough directions :). And would I run the same command again on another driver update or is the setting saved in the "Kbuild" file? Thanks again for the help :)
Back to top

You're welcome.

> And would I run the same command again on another driver update or is the setting saved in the "Kbuild" file?
That's what I've described in my last paragraph. tl;dr: No, your changes get overwritten, you have to redo that at every driver update.
Back to top

Oh shoot my bad, I must've glossed over it. Thanks so much for the help. Hopefully this issue gets fixed in newer kernel updates because I'm not too sure how many other people using liquorix would be able to figure it out or find the help I got from you. For the past few days I just had no idea so I just stuck to the 4.7.whatever for the time being.
Back to top

Indeed, this has to be fixed. According to the homepage, Liquorix is a "Distribution Kernel Drop-in Replacement" and it's "Compatible with Debian Testing and newer as well as latest Ubuntu."

At the moment, IMHO this goal is not completely reached because of this issue.

I hope this thread gets developer attention soon.
Back to top

I disagree, if liquorix can be installed in ubuntu current, the goal is reached. An ubuntu dkms package designed explicitly and specifically to run on the stock ubuntu kernel not working with liquorix is NOT a valid criteria for such a conclusion.

dkms packages are designed to work with specific stable kernels, which is one reason I never, ever, use dkms.

Now, if a direct install of the nvidia driver were to fail on liquorix (either download directly or install via something like sgfxi or its ubuntu equivalent if that is working at the moment), then you'd have a point, if that install worked on other kernels of the same major version, like 4.8 or whatever.

There seems to be a fairly serious ongoing misunderstanding of what a dkms distribution package of a non free driver actually means or what it is in the first place.
Back to top

That is a legitimate opinion of course.

My point just is, that installing the proprietary nvidia driver is something that e.g. Kubuntu even suggests to users in a graphical way (kcm_driver_manager). It's a package that Ubuntu delivers to users and every Ubuntu User having Nvidia video card uses when he wants to have decent video performance.

The other point is, that if one says it's a drop in replacement, then the user thinks he can just replace it and everything works as flawlessly before. If there are limitations of the "drop-in replacement" point, then maybe they should be mentioned.

And my last point is, that bbswitch from the bumblebee project is a free and open source driver and it's affected, too, so your whole argument about non-free stuff does not cover the issue completely. Maybe there are more kernel modules that don't compile? I only use these, but surely there are more out there.

Of course it's your project (assuming you're the project owner) so you are free to decide just how you want and it's all correct. This is your baby and I can only ask and suggest.
Back to top

There may or may not be valid issues re these flags (I'm not the liquorix person, I just maintain the forums), but your assumptions about dkms and kernels simply are not related to reality.

Let me give you an example, and this is a very common occurrance:

1. ubuntu releases a kernel with the current ubuntu, so say, it ships with 4.8 kernel. All other modules are likewise packaged and work with 4.8, so minor kernel updates, like 4.8.0 to 4.8.1, continue to work fine, and rebuild modules when required, since the kernel version is still compatible with the driver.

2. shortly thereafter, current main kernel project moves to 4.9.

3. liquorix then moves to 4.9.

4. Since the same gcc version is used to compile 4.8 and 4.9, and since no other dependencies are involved, liquorix keeps working on this ubuntu release, that is, the kernel and headers install without any issues. The goal of support is met.

5. nvidia releases a new set of drivers, legacy and current, that support 4.9, because the previous version, the one in the ubunty dkms nvidia package, does not support 4.9 kernels.

6. since ubuntu is maintaining its release, say, 16-4, with patched kernels, but not with major new kernel versions, ubuntu is doing their job as maintainers, but that doesn't then mean that their dkms now magically supports a kernel that it doesn't support.

Note further, that liquorix is only a replacement for current short term ubuntu release, NOT long term support releases, whose gcc and other dependency versions will NOT be compatible with future liquorix kernels.

The bumblebee example you gave appears to be an ubuntu project, which may simply have failed to handle this situation, hard to say.

None of this means that damentz can't alter the kernel config for liquorix if that seems like a good idea, but maintaining support for existing ubuntu dkms drivers is impossible after you move to the next major kernel version no matter what. Major kernel versions are released 4x a year.

It's difficult to understand this stuff if you've been trained by ubuntu to be unaware of such longstanding and non abstract issues with driver vs kernel support.

With this said, there are often many kernel major releases that maintain support for the same kernel api, but the kernel changes apis constantly, despite what the maintainers of it pretend, I've done sgfxi for ages now, and I can assure you, major kernel versions should always be expected to break existing non free drivers until shown to not do so.

Sometimes, as in the case of the current 340.x driver, for example, you need to apply a patch to the driver to get it to run on newer kernels, something sgfxi does. dkms can also I believe do this, I think, but the patches have to be included in the package, which of course they wouldn't be since the dkms package is made to work with the kernel in ubuntu, not liquorix.
Back to top