dkms_common.postinst.in supports passing ARCH while dkms_autoinstaller.in does not

[kinghrothgar]

I am on the latest proxmox (debian), and the package arch does not match the actual kernel arch (amd64 vs x86_64).

I am installing the latest available dkms and dh-dkms packages (3.1.5-2). When I install build and install a dkms package (https://github.com/wisdpi/wp-ut5_dkms, realtek-r8152-dkms), the dkms modules for the correct arch (amd64) are built:

$ dkms status
realtek-r8152/2.19.2, 6.8.12-4-pve, amd64: installed (Original modules exist)

This is because the correct package arch is passed to dkms_common.postinst.in by the realtek-r8152-dkms's postinst script.

However, when a new kernel is installed, -a amd64 is not passed to dkms in the resulting in the module being built for x86_64, resulting in the module not being loaded into the new kernel as it needs a module for amd64:

dkms status
realtek-r8152/2.19.2, 6.8.12-4-pve, amd64: installed (Original modules exist)
realtek-r8152/2.19.2, 6.8.12-9-pve, x86_64: installed (Original modules exist)

I am not sure if something needs to be changed here or at the debian package level, but as far as I can tell as is, I can not get my dkms package to automatically build the correct arch automatically on kernel upgrade.

[scaronni]

@anbe42 can you please have a look at this? I'm not sure I can help where with the Debian specifics. Thanks!

[anbe42]

@kinghrothgar Please try the dkms-test-dkms package. Does this behave correctly, i.e. does it build for the correct architecture in your two scenarios?

[kinghrothgar]

@anbe42 that package builds for the wrong arch also on package install, not just on kernel update. The realtek-r8152-dkms package has a postinst script that does ARCH=$(dpkg --print-architecture) and passes it to dkms via the -a argument. That is why it works on package install, but not on kernel upgrade. I suspect this is a hack from the original author because of the issue raised here.

$ dkms status
dkms_test/1.0, 6.8.12-9-pve, x86_64: installed

I verified this on both the latest proxmox and debian stables using the 3.1.5-2_all.deb packages

[anbe42]

What does uname -m (uname -a) report on your machine?

I just tried in a minimal Debian/sid amd64 chroot:

apt-get install linux-headers-amd64
apt-get install dkms-test-dkms
apt-get install linux-headers-cloud-amd64

So the first module gets built by common.postinst, the second by kernel_postinst.d/dkms.

# dkms status
dkms_test/1.0, 6.12.19-amd64, x86_64: installed
dkms_test/1.0, 6.12.19-cloud-amd64, x86_64: installed

Makes no difference.

Then I tried

# dkms build -k 6.12.19-amd64 -a amd64 dkms_test/1.0
[...]
# dkms build -k 6.12.19-amd64 -a foo dkms_test/1.0
# dkms status
[...]
dkms_test/1.0, 6.12.19-amd64, amd64: built
dkms_test/1.0, 6.12.19-amd64, foo: built
dkms_test/1.0, 6.12.19-amd64, x86_64: installed
dkms_test/1.0, 6.12.19-cloud-amd64, x86_64: installed
# md5sum /var/lib/dkms/dkms_test/1.0/6.12.19-amd64/*/module/dkms*.ko*
8d83e95f06722a798fdc5026359dd73c  /var/lib/dkms/dkms_test/1.0/6.12.19-amd64/amd64/module/dkms_test.ko.xz
8d83e95f06722a798fdc5026359dd73c  /var/lib/dkms/dkms_test/1.0/6.12.19-amd64/foo/module/dkms_test.ko.xz
8d83e95f06722a798fdc5026359dd73c  /var/lib/dkms/dkms_test/1.0/6.12.19-amd64/x86_64/module/dkms_test.ko.xz

At least for this trivial module, the -a argument is irrelevant.

[anbe42]

Did you actually experience module loading issues? If KERNELDIR=... was the solution, the ARCH mismatch was not the problem.

I think the correct KERNEL ARCH value is x86_64 (unless proxmox does something very special with their kernel) and the 15 year old postinst script just does bullshit by passing -a amd64 (the DPKG ARCH).

BTW: Shipping something in /tmp in a .deb package is insane. Take a look at dh_installudev for proper handling of your rules file.

[kinghrothgar]

BTW: Shipping something in /tmp in a .deb package is insane. Take a look at dh_installudev for proper handling of your rules file.

None of that shit is mine :/ It's a repository created by the company who made my USB NIC that is definitely just a hacked together fork of a fork. Once I understand all this better, I'm gonna make my own fresh repo and ditch that one.

I will verify soon in a fresh test environment again now that I understand everything better and how to test it, but I believe when it was built for x86_64 the module was not getting loaded.