**** BEGIN LOGGING AT Mon Nov 02 02:59:57 2020 Nov 02 07:05:54 wryun: (if you ever read the logs :p ) : you'd better take the last dundell-testing build, as we are facing kernel issues with the newer gatesgath builds Nov 02 07:42:42 Tofe, what are the kernel issues? Nov 02 07:54:07 ka6sox: it's still the same kernel module loading issue, which I quite don't undersand. I get a "Exec format issue" when doing modprobe or insmod, and nothing in dmesg Nov 02 07:55:29 It's a build from scratch, identical defconfig, same linux version as for dunfell. Dunfell works fine, gatesgarth has the issue. And only on pinephone (aarch64), I tested tissot and it was fine... Nov 02 10:05:55 Morning Nov 02 11:50:40 morning Nov 02 11:58:27 Tofe: now that we have xz PACKAGECONFIG in kmod we could also retry with xz, but probably won't help with the current issue :/ Nov 02 12:03:57 JaMa: I was thinking about debugging kmod.insmod and have a more precise status about the error Nov 02 12:11:48 yes or using 26 version from dunfell (or better to test kernel+modules built in gatesgart in dunfell image) Nov 02 12:21:48 Yes, trying kernel+modules on dunfell should be fairly easy, it's just a copy/paste to the sdcard Nov 02 12:22:23 I looked at insmod, and it just does a mmap, then do the syscall directly after Nov 02 12:22:37 so a debug probably won't bring much Nov 02 16:24:45 Tofe: mmap on the gzip data or kmod unpack it first? Nov 02 16:51:14 JaMa: it unpacks first :) Nov 02 16:51:23 Wait, I'll have to re-read Nov 02 16:58:34 Yes, I think so. But anyway, even if I gunzip the .ko.gz first, I get the same issue with insmod Nov 02 17:43:43 ok, I was just wondering if it correctly detects and uses gzip (as you had issues with xz before), mmaping gzip data while claiming it's xz compressed would definitely be bad format :) Nov 02 18:33:00 JaMa: same result with dunfell rootfs + kernel/modules from gatesgarth Nov 02 18:33:13 so it's the kernel and/or the modules, not userland **** ENDING LOGGING AT Tue Nov 03 03:00:33 2020