Arch Linux User Repository

I'm also having the same issues as Air-G4P, with Nvidia-DKMS failing after having successfully built and installed linux-ck, linux-ck-headers, both via AUR helper and manually with makepkg.

Identical error of resolve_btfids

After some research, I found a solution, posted by Logs, on the Linux-CK thread on the BBS forums. It can be resolved by uncommenting the following line in the PKGBUILD.

@graysky - Thank you for your suggestion.

If I understood you correctly, I did copy my modprobed.db to my build directory containing the 6.0-1 PKGBUILD, added that file to the source array, appended the 256sum and modified the make line to the statement you referenced below.

The PKGBUILD I used is here: http://ix.io/4cFF

The only relevant modifications I made were on lines: 97, 111 and 194.

The build did succeed, without any reported error. However I still suspect time makechrootpkg -c -r $CHROOT is silently ignoring the reading/use of the 'modprobed.db' file as my build time still exceeded 5.5+ hours and my ~/chroot/user folder is (again) 20 GiB.

If you had another build process idea in mind, please let me know.

Cheers

I think you will have to copy the file into the chroot. By design it shouldn't be able to read outside. Why not just copy the database into the same dir as the PKGBUILD, and include it in the source array. Change the line like this to call it:

make LLVM=$_LLVM LLVM_IAS=$_LLVM LSMOD="../modprobed.db" localmodconfig

@graysky - 5.19.14-1 built and 'dkms install' completed without error, but only when building in a clean chroot using makechrootpkg -c -r $CHROOT.

The chroot build fails unless _localmodcfg= is left empty, which of course, causes very long build times.

Is there any way to force the chroot to use _localmodcfg=/home/<userID>/.config/modprobed.db?

Cheers

@artafinde - I appreciate your insightful feedback.

If you meant by ignoring the package not found build errors when running extra-x86_64-build: do not use use extra-x86_64-build, I agree because I cannot get past those build errors. If you meant something else, please let me know.

The build and installation did succeed with sudo ccm s, however ccm silently ignored my: PKGBUILD _localmodcfg=/home/<userID>/.config/modprobed.db.

CCM not reading modprobed.db explains why I was treated to another 5+ hour build joyride and why my ccm build folder grew to 20 GiB!

Thanks and cheers...

@air-g4p: the error you mention 'packages not found linux-ck and linux-ck-headers' can be ignored. The extra-x86_64-build assumes you are building for Arch repos and executes secondary tools to compare the package with the one from the repos. Is this case it's not able to find them in repos (makes sense).

For the second issue it's also expected to not work since the chroot doesn't have your modprobed-db. You'll need to hack the script or check if graysky's clean-chroot-manager supports modprobed-db. Yeah it does take time but if you build it once with generic you can reuse it on your laptop ;)

@artafinde - I'm interested to learn if you see the same clean chroot build behavior(s).

If I run extra-x86_64-build, that fails early in the build process with something like 'packages not found linux-ck and linux-ck-headers.'

I've been using graysky's modprobed-db for many years without issue, so I always include: _localmodcfg=/home/<userID>/.config/modprobed.db in the PKGBUILD to reduce compilation time.

However, when I run makechrootpkg -c -r $CHROOT with ^that PKGBUILD, it fails with 'cannot find /home/<userID>/.config/modprobed.db'. I have never seen this failure when running time makepkg -sric.

The only way I can get makechrootpkg -c -r $CHROOT to successfully build and install is to leave _localmodcfg= empty.

However, this massively increases compilation time. On my old laptop, linux-ck compilation time increased from an average of about 1.5 hours to more than 5 hours!

In any event, the Good News is that the build and installation was a success!!

Please let me know when you have a chance.

Thanks and cheers...

air-g4p: Glad it helped. I was thinking maybe the dkms.conf (or the relevant Makefile for each extra module) wasn't not up to date with 5.19.x kernels. Anyway all well and keep building with clean chroot! :D

@artafinde - My apologies if you perceived my response as snarky.

I only think of 'old' as related to code/configs as being deprecated or obsolescent, which as a prominent example, most unfortunately, I am forced to observe, daily, as in: POTUS Joe Biden...

If you have another definition of 'old' as it relates to the 3 dkms.conf files I sent you earlier: http://ix.io/4bt5, you never explained why they are 'old'. I would be interested to learn about your POV.

In any event, for reasons I still do not understand, building in a clean chroot worked (on my newer laptop, at least); meaning linux-ck compiled and 'dkms installed' without error, as opposed to the multiple 'dkms install' failures I experienced via 'time makepkg -sric'.

Thank you for your input artafinde!