Bug#818862: Similar issues with kernel 4.6 and 4.7

Eduard Bloch edi at gmx.de
Fri Aug 19 07:56:13 UTC 2016


Hallo,
* Andreas Beckmann [Thu, Aug 18 2016, 02:21:38AM]:
> On 2016-08-17 00:07, Eduard Bloch wrote:
> >> module-assistant build --text-mode --force --kvers-list 4.7.0-rc7-amd64 nvidia-kernel
> > 
> > a) minor detail, the readme does not mention --force, although it should not be required.
> 
> It's just helpful to rebuild again and again looking for your problem...
> 
> > c) I tried a similar command with 4.6.0-1-amd64 (Sid kernel) and it did NOT work. Now
> 
> I just had a good burger for dinner and it DID work.
> But it still didn't tell me the command you used.
> 
> 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?

> 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?

> 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.

Regards,
Eduard.



More information about the pkg-nvidia-devel mailing list