Arch Linux User Repository

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!

@graysky - noted that you are unfamiliar with dkms.

However I checked all of your (the default) configs related to config DEBUG_INFO_BTF.

AFAICT - ALL appear to be correctly set and in compliance with its dependencies listed here:

https://github.com/torvalds/linux/blob/master/lib/Kconfig.debug

Refer to ^lines 339 through 365. I saw no reason to change those configs.

Hoping against hope, I did opt to change the linux-ck build with CLANG, as opposed to the default gcc.

No improvement: compiled without error, but the exact same 4 'dkms install' module errors (I previously documented) re-appeared during installation.

IMHO, the default kernel configs are set correctly - and the choice of the compiler is not relevant to the 4 (out of 4) 'dkms install' module errors I have been seeing of late.

@air-g4p that's not what I mean by the dkms.conf being old but anyway - fill your boots :)

@artafinde - glad to learn things work correctly on your end.

However, since you earlier assumed: I think maybe the DKMS modules are old and not updated for latest kernels?

I provided the evidence that your assumption is not true on my fully updated, and re-booted, laptops.

What would make you now believe that building in a clean chroot would correct anything?

I build linux-ck with time makepkg -sric as I have been doing for many years!

Cheers