Bug#818862: Similar issues with kernel 4.6 and 4.7

[Andreas Beckmann]

On 2016-08-19 09:56, Eduard Bloch wrote:
> Hallo,
> * Andreas Beckmann [Thu, Aug 18 2016, 02:21:38AM]:
>> Nevertheless, I managed to come up with a command that reproduces your
>> failure:
>>
>>     m-a build -t -O -k /usr/src/linux-headers-4.6.0-1-amd64 -f nvidia
> 
> Nice, I can test it now. And also add -d (my old "debug" mode).
> And I see something suspicious in the diff:
> 
>  ++ return 0
> -+ build build KVERS=4.6.0-1-amd64 KSRC=/usr/src/linux-headers-4.6.0-1-amd64 KDREV=4.6.4-1 kdist_image
> ++ build build KVERS=4.6.0-1-amd64 KSRC=/lib/modules/4.6.0-1-amd64/build KDREV=4.6.4-1 kdist_image
> 
> This is the call from m-a passed to you and it is OK. This points to the
> same directory.
> 
>  dh_testroot
> -/usr/bin/make clean SYSSRC="/usr/src/linux-headers-4.6.0-1-amd64" 
> +/usr/bin/make clean KERNEL_UNAME="4.6.0-1-amd64" 
> 
> And this is what YOUR build system made out from it. The kernel version
> AND directory were passed previously to your build script, why is this
> information lost in the call?

the variables have to be transformed into something the NVIDIA build system understands ...


>> On 2016-08-16 20:02, Eduard Bloch wrote:
>>> I have no idea how you manage to build the current modules even for Sid.
>>
>> We use -l, not -k.
> 
> Shouldn't make a difference. (I should know it, I wrote m-a, originally
> it was even made for nvidia compiling as first use case, and it's just a
> tool investigating environment and preparing information).
> 
>> And let the buildsystem figure out the details from /lib/modules
>>
>> I don't think there is an easy way to make the -k option work for the
>> split Debian header packages (e.g. -common and -amd64) with the nvidia
> 
> What is the problem with splitted headers? They are interconnected with
> symlinks, there should not be any difference.
> 
>> kernel module (and their conftest.sh script). But it seems to work for
>> the locally built kernel (no split headers) I have residing in my module
>> testbuild chroot.
> 
> What about regular users, they are supposed to use chroots for
> everything too?

regular users ... use the -dkms package :-)
(advanced users may use -source)
No need for chroots at all :-)

I think you used the only parameter variant that does not work :-)

>> PS: Setting only SYSSRC was an error which made us maintain our own
>> conftest.h for about 10 years since the upstream conftest.sh didn't work
>> with the split Debian header packages. Because we never told it about
>> SYSOUT as well.
> 
> Those are internal details I have no real insight in. I see symptoms and
> report them, just that.

The NVIDIA build system is "special" since it wants to do many things on its own that would be better delegated to kbuild ...

There are three variables understood by NVIDIA, with defaults (simplified):

KERNEL_UNAME ?= $(shell uname -r)
SYSSRC       ?= $(firstword $(wildcard /lib/modules/$(KERNEL_UNAME)/source /lib/modules/$(KERNEL_UNAME)/build))
SYSOUT       ?= $(if $(filter %/source,$(SYSSRC)),/lib/modules/$(KERNEL_UNAME)/build)

Setting SYSSRC=/usr/src/linux-headers-4.6.0-1-amd64
on its own is just wrong. from the content of that directory I cannot see how I could conclude that the missing bits are in /usr/src/linux-headers-4.6.0-1-common

What would work probably for split headers is 
SYSSRC=/usr/src/linux-headers-4.6.0-1-common
SYSOUT=/usr/src/linux-headers-4.6.0-1-amd64

But of course SYSSRC=/usr/src/linux-headers-4.6.0-custom-nonsplit should work, too.

With a path in /usr/src there is nothing I can do.
With a path in /lib/modules I can fall back to just passing KERNEL_UNAME 
and let NVIDIA figure out the paths from /lib/modules/$(KERNEL_UNAME)/{source,build}
(which is what you observed in your debug output)

Andreas