dkms compiles module for wrong kernel - why?

[Malvineous]

I originally posted this on the Arch forums thinking it was a dkms issue, but they closed the thread as apparently this is specific to Arch Linux ARM.

I'm trying to upgrade a headless RasPi running Arch ARM, and it's connected via a USB WiFi adapter. The WiFi driver is compiled as a dkms module. I have upgraded my kernel, but the dkms build failed. Thus I can't reboot or I will lose access to the machine, since there is no longer any WiFi driver present.

So I need to compile the dkms module while the old kernel is running, before rebooting into the new kernel.

For some reason, this does not work, and it keeps trying to compile against the running kernel instead of the new one. What am I doing wrong??

$this->bbcode_second_pass_code('', '
# dkms install mt7610u_sta/r28.2ecaea4 -k 4.14.72-1-ARCH

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area...
make -j1 KERNELRELEASE=4.14.72-1-ARCH -j1......(bad exit status: 2)
Error! Bad return status for module build on kernel: 4.14.72-1-ARCH (armv6l)
Consult /var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/make.log for more information.

# cat /var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/make.log
DKMS make.log for mt7610u_sta-r28.2ecaea4 for kernel 4.14.72-1-ARCH (armv6l)
Sun Sep 30 16:54:04 AEST 2018
make -C tools
make[1]: Entering directory '/var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/tools'
gcc -g bin2h.c -o bin2h
make[1]: Leaving directory '/var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/tools'
/var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/tools/bin2h
chipset = mt7610u
cp -f os/linux/Makefile.6 /var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/os/linux/Makefile
make -C /lib/modules/4.9.39-1-ARCH/build SUBDIRS=/var/lib/dkms/mt7610u_sta/r28.2ecaea4/build/os/linux modules
make[1]: *** /lib/modules/4.9.39-1-ARCH/build: No such file or directory. Stop.
make: *** [Makefile:404: LINUX] Error 2

# uname -a
Linux mimrock 4.9.39-1-ARCH #1 SMP Sat Jul 22 16:53:55 UTC 2017 armv6l GNU/Linux

# ls /lib/modules
total 64K
drwxr-xr-x 4 root root 4.0K Sep 30 10:57 .
drwxr-xr-x 77 root root 48K Sep 30 14:35 ..
drwxr-xr-x 4 root root 4.0K Sep 30 10:57 4.14.72-1-ARCH
drwxr-xr-x 2 root root 4.0K Sep 30 10:56 extramodules--raspberrypi
')

Why is make trying to look at the modules for 4.9.39 (the running kernel) instead of 4.14.72 (the new kernel)? How can I force it to build against the new kernel without rebooting? (Since once I reboot I will lose access to the system until the new module is built and installed, so I can't reboot and then compile it.)

I was going to include a link to the AUR repository for this but it appears to have been deleted. Not sure why because as far as I can see, the kernel still doesn't have MT7610U support yet.

[TheSaint]

I would take the option to work with a wired connection. Otherwise, you should keep two installation. One with minimal setup, for emergency. So the from the hold you may chroot to the newer and fix the issues.
Then you may update the old one once you solved the latest update.

[Malvineous]

I would much rather a wired connection but sadly that involves putting holes in walls and running cables which is a bit too much effort as this set up is only relatively temporary.

I ended up working around the issue with a symlink:

$this->bbcode_second_pass_code('', '
cd /lib/modules
ln -s 4.14.72-1-ARCH/ 4.9.39-1-ARCH
')
There's definitely a bug in dkms somewhere but this at least got it to start compiling!

[TheSaint]

Clever workaround
I meant to wire the machine for a temporary fix up.