Install kernel-headers in the image

[Yes21]

With this (well tested) PR,

• good version (4.14.71) of kernel-headers are installed in the image (/usr/src),
• good symlinks are created in /lib/modules/...
• wireshark-common is installed, but already asks the f... question,
• tshark is also installed.

With this PR, Luke shouldn't anymore has problems with v4l2loopback ...

[pilotnbr1]

awesome! ill test it!

[Yes21]

Ok, I'm impatient to see if all will be ok for you.

[pilotnbr1]

@Yes21 I just looked at the code. Did you test this?

When I attempted requesting new headers like that I would get headers for the latest kernel, not our kernel. I am going to wait to test this as I think I have already done this and it doesnt work. When I did this you get folders for kernel 4.14.79 and you will also see empty folders (unless you purge them) for 4.14.71.

[Yes21]

Because you were installing kernel-headers after apt-get update ... Now I'm doing it before apt-get update, and it I've tested that it works.

[pilotnbr1]

Ahhh! Ill give it a try! Awesome!

[pilotnbr1]

So good news, the kernel header portion worked! That problem was driving me nuts. Good job @Yes21

Its hard for me to tell but it also looked like some of the other things like mavlink built with fewer errors because it could find the headers. I don't stare at the terminal while it builds for hours on end, believe it or not lol. But when I was paying attention it seemed like it was happier.

The bad news is that the OSD did not appear for me. So something is wrong.

The other problem is that in the builder when v4l2 tries to make it outputs this error- /usr/bin/make -C /lib/modules/uname -r/build M=/home/pi/v4l2loopback modules_install make[1]: *** /lib/modules/4.15.0-39-generic/build: No such file or directory. Stop. Makefile:47: recipe for target 'install' failed

So in the builder it is not getting "uname -r" correctly passed as 4.14.71

The good news is that in the live pi terminal v4l2loopback makes! It does coming up with a warning of "clock skew detected" . I think if it makes in the builder then that will go away or be fine but I will still look into that error. Everytime I research one thing I learn 5 others lol

[pilotnbr1]

I am running a test build right now with this line removed. I am wondering if it took out something needed by the osd...

DEBIAN_FRONTEND=noninteractive sudo apt-get -yq autoremove

These were the packages it removed on the last build PACKAGES REMOVED BY AUTOREMOVE bind9-host distro-info-data geoip-database libavahi-core7 libbind9-140 libdaemon0 libdns162 libgeoip1 libisc160 libisccc140 libisccfg140 liblwres141 libpcsclite1 libpng12-0 lsb-release python-apt-common python3-apt

[Yes21]

The bad news is that the OSD did not appear for me. So something is wrong.

That's normal because @RespawnDespair didn't already revert one of my not working PR

[Yes21]

I am running a test build right now with this line removed. I am wondering if it took out something needed by the osd... DEBIAN_FRONTEND=noninteractive sudo apt-get -yq autoremove

Don't worry, you aren't responsible for the OSD not working.

I'm responsible with this PR. Just wait until @RespawnDespair reverts it ...

[Yes21]

If you can't wait, you can remove all the "-j $J_CORES" from this file "stages/04-Wifibroadcast/01-run-chroot.sh". And OSD wil work again !

[RespawnDespair]

If you would, i don't have access to my pc, i can approve PR's on my mobile but editing source is another matter. If you make a pr reverting the original changes i'll approve it.

[pilotnbr1]

No worries! I don’t build directly off the master repo.

I see your changes and add or subtract them off the builder script on my local computer. Once I am happy I test it and if it works then upload to the master repo.

I also have jelles builder cloned into my own github account.

[pilotnbr1]

@RespawnDespair I’ll send a pr reverting that.

[Yes21]

The other problem is that in the builder when v4l2 tries to make it outputs this error- /usr/bin/make -C /lib/modules/uname -r/build M=/home/pi/v4l2loopback modules_install make[1]: *** /lib/modules/4.15.0-39-generic/build: No such file or directory. Stop. Makefile:47: recipe for target 'install' failed

I've now the same problem as you with 4.15.0-39 when trying to install rtl8812au drivers with make.

Like you, I'm sure something is broken with this cross-compiled image. After the apt-get update command (which shouldn't be needed), the system believes it was build with latest kernel version. That's not a normal behavior !

uname -r is saying "4.14.71-v7+", but I'm sure that this information is missing else where ...

We have to find a way to fix that, or to not have to run apt-get update.

[Yes21]

As we can see in /proc/version file : Linux version 4.15.0-39-generic (buildd@lgw01-amd64-054) (gcc version 7.3.0 (Ubuntu 7.3.0-16ubuntu3)) #42-Ubuntu SMP Tue Oct 23 15:48:01 UTC 2018

the system believes now that it is in 4.15.0-39-generic version.

I sure it's caused by apt-get update.

I will run again the script without apt-get update, and see ...

[pilotnbr1]

I also tried commenting out apt-get update and nothing changed.

I think the question is where is uname looking to get its value? And then how can we provide that value or file.

[Yes21]

I also tried commenting out apt-get update and nothing changed.

I can confirm that. But that's really incredible !! We have to understand why, when and how does the system believe it has been upgraded to latest kernel.

The way uname gets kernel version is very complicated. You can find here an interesting link about the subject ...

[pilotnbr1]

@Yes21 Did you try building completely from nothing? I started my test from stage 3 forward.

I am thinking we should try comment out apt-get update and start the build from the very beginning... It just takes so long...

[Yes21]

@pilotnbr1 I did it like you from stage 3 :-)

Without apt-get update, many packages are not installed (like wireshark-common and tshark) and the image is not working (no video, no OSD). I can't understand why these packages (and many others) are not installed without apt-get update.

I am thinking we should try comment out apt-get update and start the build from the very beginning

I will try this, and try to identify all uninstalled packages, and try to understand why they were not installed. But as apt-get update doesn't seem to be the cause of uname -r returning bad kernel version, I don't know if commenting it out will solve our problem.

Ps : You were right, that's an interesting game to find The error. But like you i'm learning much doing this ...

[pilotnbr1]

I am going to add

echo uname -r

to different places in the builder to see when it changes... trying to debug this

[pilotnbr1]

I can report that at the beginning of stage 3 uname -r returns the 4.15 version value.... Still starting the builder at stage 3

[Yes21]

Good idea to add echo uname-r

Can you identify when it changed from 4.14 to 4.15 ?