Package Base Details: linux-ck

Git Clone URL: (read-only, click to copy)
Submitter: graysky
Maintainer: graysky
Last Packager: graysky
Votes: 452
Popularity: 2.39
First Submitted: 2011-07-22 14:51 (UTC)
Last Updated: 2023-02-06 17:46 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 .. 303 Next › Last »

VGrol commented on 2022-12-01 02:42 (UTC) (edited on 2022-12-01 06:33 (UTC) by VGrol)

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.

air-g4p commented on 2022-10-09 14:41 (UTC)

@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:

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.


graysky commented on 2022-10-07 10:06 (UTC)

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

air-g4p commented on 2022-10-07 07:11 (UTC)

@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?


air-g4p commented on 2022-10-03 05:32 (UTC)

@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...

artafinde commented on 2022-10-02 08:36 (UTC)

@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 ;)

air-g4p commented on 2022-10-02 07:36 (UTC)

@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...

artafinde commented on 2022-09-30 16:06 (UTC)

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

air-g4p commented on 2022-09-30 15:22 (UTC)

@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:, 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!

air-g4p commented on 2022-09-30 14:44 (UTC) (edited on 2022-09-30 15:29 (UTC) by air-g4p)

@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:

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.