fabianishere/udm-kernel-tools

Trouble building udm-kernel-tools

telnetdoogie opened this issue · 11 comments

After adding the v1.11.0-23 config, attempting to build udm-kernel-tools terminates with:

  HOSTCC  scripts/kallsyms
  HOSTCC  scripts/conmakehash
  HOSTCC  scripts/recordmcount
  HOSTCC  scripts/sortextable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/extract-cert
scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or directory
   21 | #include <openssl/bio.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
make[4]: *** [scripts/Makefile.host:90: scripts/extract-cert] Error 1
make[3]: *** [Makefile:1089: scripts] Error 2
make[3]: Leaving directory '/home/jhobbs/udm-kernel-tools/udm-kernel-tools/build/kernel-977c11883bd3fb422f6c0f68f86d2df92e7bb37c'
make[2]: *** [debian/rules.d/kexec-mod.mk:42: build/kernel-977c11883bd3fb422f6c0f68f86d2df92e7bb37c/v1.10.0.config] Error 2
make[2]: Leaving directory '/home/jhobbs/udm-kernel-tools/udm-kernel-tools'
make[1]: *** [debian/rules:32: build/modules/v1.10.0] Error 2
make[1]: Leaving directory '/home/jhobbs/udm-kernel-tools/udm-kernel-tools'
make: *** [debian/rules:29: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -aarm64 failed

...is this a problem with the provided commit ID from a previous incompatible kernel? Or a problem with my attempted build?

You are probably missing OpenSSL:

apt install libssl-dev

Also, here is the build produced by Github Actions for the last commit:

build-artifacts.zip

That's super helpful. Thanks! Where does that build normally show up after the build?

So, I've attempted to boot to the latest 4.19.152-edge2 with the new build created from that commit, but it looks like it creates a kernel panic:

# cat /sys/fs/pstore/*
[    0.634164] pci-pf-stub 0000:00:04.0: writing to VF config space
[    0.634226] pci-pf-stub 0000:00:05.0: writing to VF config space
[    0.653113] ahci 0001:00:00.0: writing to VF config space
[    0.660777] al_eth 0000:00:00.0: writing to VF config space
[    0.672502] al_eth 0000:00:01.0: writing to VF config space
[    2.355326] al_eth 0000:00:02.0: writing to VF config space
[    2.367051] al_eth 0000:00:03.0: writing to VF config space
[    7.952271] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
[    7.961121] Mem abort info:
[    7.963944]   ESR = 0x96000005
[    7.967027]   Exception class = DABT (current EL), IL = 32 bits
[    7.972998]   SET = 0, FnV = 0
[    7.976079]   EA = 0, S1PTW = 0
[    7.979246] Data abort info:
[    7.982178]   ISV = 0, ISS = 0x00000005
[    7.986039]   CM = 0, WnR = 0
[    7.989034] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000ddeb37e6
[    7.995695] [0000000000000020] pgd=0000000000000000, pud=0000000000000000
[    8.002509] Internal error: Oops: 96000005 [#1] SMP
[    8.007435] Modules linked in: ubnt_common(PFO)
[    8.011990] Process modprobe (pid: 347, stack limit = 0x0000000031cb2aab)
[    8.018826] CPU: 1 PID: 347 Comm: modprobe Tainted: PF          O      4.19.152-edge2 #1
[    8.026962] Hardware name: Annapurna Labs Alpine V2 UBNT (DT)
[    8.032729] pstate: a0000005 (NzCv daif -PAN -UAO)
[    8.037547] pc : ref_module+0x48/0x148
[    8.041347] lr : resolve_symbol.isra.33+0xa0/0x104
[    8.046159] sp : ffffff8009f53bc0
[    8.049526] x29: ffffff8009f53bc0 x28: ffffff8000b2a598
[    8.054861] x27: ffffff800a0b420c x26: ffffff8000b226c8
[    8.060194] x25: ffffff800a0bf098 x24: ffffff8000b223c0
[    8.065555] x23: ffffff8009f53d70 x22: ffffff80009df2b8
[    8.070886] x21: ffffff80009e4080 x20: ffffff80009e4378
[    8.076246] x19: ffffff8000b223c0 x18: 0000000000000080
[    8.081579] x17: 0000000000000000 x16: 0000000000000000
[    8.086939] x15: 5400160b13131717 x14: ff00000000000000
[    8.092273] x13: 0000000000000000 x12: 0000000000000007
[    8.097634] x11: 0000000000000030 x10: 0101010101010101
[    8.102966] x9 : 0000000000000003 x8 : 7f7f7f7f7f7f7f7f
[    8.108327] x7 : 6bff636064715e6d x6 : 0000000000008018
[    8.113660] x5 : 1800000000000000 x4 : 0080000000000000
[    8.119020] x3 : 0075000000000000 x2 : 08d8b878f4f51300
[    8.124355] x1 : ffffff80009e4080 x0 : 0000000000000000
[    8.129715] Call trace:
[    8.132187]  ref_module+0x48/0x148
[    8.135613]  resolve_symbol.isra.33+0xa0/0x104
[    8.140079]  load_module+0x12a4/0x22c0
[    8.143877]  __se_sys_finit_module+0xc4/0xd8
[    8.148171]  __arm64_sys_finit_module+0x24/0x30
[    8.152752]  el0_svc_handler+0xc8/0x1a8
[    8.156611]  el0_svc+0x8/0xc4
[    8.159603] Code: 1400000d f9400000 eb14001f 54000140 (f9401001)
[    8.165743] ---[ end trace e765544e91172262 ]---
[    8.173957] Kernel panic - not syncing: Fatal exception
[    8.179232] SMP: stopping secondary CPUs
[    8.183194] Kernel Offset: disabled
[    8.186706] CPU features: 0x0,20006008
[    8.190505] Memory Limit: none
[    8.197153] Rebooting in 3 seconds..

and when the UDMP comes back up:

# uname -a
Linux Hobbs-UDMP-Gateway 4.19.152-al-linux-v10.2.0-v1.11.0-23.3921-f2e3fac #1 SMP Fri Dec 10 16:59:46 UTC 2021 aarch64 GNU/Linux

So I'm assuming it's a no-go

I suspect the issue is that you are running a v1.10-based kernel, while the proprietary kernel modules from Ubiquiti are built against a newer v1.11 kernel.

We'll need to ask Ubiquiti for the new kernel sources, so that we can build for the correct kernel.

That's super helpful. Thanks! Where does that build normally show up after the build?

This is present for each GitHub Actions build, but it is only visible for maintainers as far as I know.

Thanks! again, super helpful... I did test the generated udm-kernel-tools on firmware 1.11.0-23, and that worked fine. Just need a newer kernel now I guess.
Should I tag a release of udm-kernel-tools for adding 1.11.0-23?

I usually wait for general availability of the firmware (which I expect somewhat soon) before creating a new release.
Do you prefer having a release sooner?

no, that's a good call... not much point having a 1.11.0-23 release without folks having access to the appropriate firmware.

FYI it was libssl-dev that was causing the error. Closing this issue, I have updated the maintenance doc with PR #55

Thank you, will have a look later today!