Fresh install of Tumbleweed, fully updated, just trying to learn how to get through a local build of the kernel to test a fix for iMac12,2 backlight control.
I get this error a couple of minutes after starting “make” in the folder I copied from /usr/src/linux-$(VERSION) into a folder in my ~/Documents.
CC kernel/bpf/cgroup_iter.o
CC kernel/bpf/bpf_cgrp_storage.o
CC kernel/bpf/cgroup.o
CC kernel/bpf/reuseport_array.o
CC kernel/bpf/sysfs_btf.o
CC kernel/bpf/bpf_struct_ops.o
CC kernel/bpf/cpumask.o
CC kernel/bpf/bpf_lsm.o
CC kernel/bpf/relo_core.o
AR kernel/bpf/built-in.a
AR kernel/built-in.a
make: *** [Makefile:2049: .] Error 2
This is lines 2042-2049 in the Makefile:
# Preset locale variables to speed up the build process. Limit locale
# tweaks to this spot to avoid wrong language settings when running
# make menuconfig etc.
# Error messages still appears in the original language
PHONY += $(build-dir)
$(build-dir): prepare
$(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1 $(single-goals)
Any clues as to what this is about would be helpful. Because this error is so cryptic, I don’t even know what to search for online.
Fairly new to openSUSE, I’ve been living in Fedora for quite a while.
There is a completely different error that comes up if I run “make” instead of “make -j$(nproc)” or “make -j4”, and searching online has also not yielded working answers to that either, so far.
CALL scripts/checksyscalls.sh
DESCEND objtool
make[3]: 'install_headers' is up to date.
DESCEND bpf/resolve_btfids
make[3]: 'install_headers' is up to date.
CERT certs/x509_certificate_list
make[2]: *** No rule to make target '.kernel_signing_key.pem', needed by 'certs/signing_key.x509'. Stop.
make[1]: *** [scripts/Makefile.build:495: certs] Error 2
make: *** [Makefile:2049: .] Error 2
This is artefact of how kernel package is built. It uses SUSE key for module sigining and the name of this key file remains in the configuration.
Short term your options are
Copy your custom key under this name
Reset option CONFIG_MODULE_SIG_KEY to the default value so that new random key will be generated every time you build your kernel
Disable module signing.
Long term you may consider opening bug report and requesting this option to be reset to the default value before package is assembled. Of course it could be intentional, but then we at least will know it
As for your earlier question - first you say you used make, later you say make works and it is make -jXX that has problems. Upload the complete command invocation and its full output to https://susepaste.org/
And this topic has nothing to do with hardware and should have been posted in Programming section. I noticed it only by accident
No, there were errors in both cases, they just happened in a slightly different way/place. The command that used more cores took only a few minutes to arrive at the error, but the simpler “make” command takes about 10 minutes or so to get to its error output.
It went basically like this:
make clean
make mrproper
make menuconfig
(changed nothing, just saved to create a .config file)
make -j$(nproc)
(output of nproc is "4", so the same as "make -j4")
("Error 2")
make clean
make
(more errors, but also the same "Error 2" at the end)
It’s not clear to me whether the more generic “Error 2” that happens when using the “-jXX” flag indicates something in addition to the “cert” issue, or is actually still just the end of the same error reporting regarding the “cert” issue in both cases, and the other error lines just don’t come out for some reason when using “-jXX”.
I guess we’ll see, when I can figure out how to either make it use a temporary signing key or disable the signing.
Thanks for the redirect/move to a more correct section of the forums. Wasn’t sure where to post since this does involve an attempt to test a hardware fix/patch.
I haven’t even attempted making the source change yet, so that can’t have anything to do with any errors at this point.
Well. That took longer than I expected. But it seems to have completed successfully. Will now try to boot into the new default kernel to see if it really worked, before attempting the patch.
Just had to change this line in the “.config” file:
That is not the default value. I am not sure what the result will be, but it looks like module signing will be enabled but modules will not be signed. Which will either completely prevent loading of any module or in the best case will taint kernel loading its own modules.
Result seems to be that module signing is disabled. Everything seems to work fine. I’m running the kernel that resulted after I made the source change suggested here:
And then did the build and “sudo make modules_install install”.
But it hasn’t resulted in getting backlight control back for this iMac model.
Obviously I don’t know what I’m doing. What is the default value you were referring to, if not an empty string?
That also bypassed the “cert” error I was getting originally. I don’t think the signing was disabled this time.
Still not having any luck getting the backlight control working, or even getting the “radeon_bl0” device to show up as it does when I boot with a Linux Mint ISO with kernel 5.15.
The quest continues. Thanks for the pointers for getting past the error(s).
Something changed in the 6.1/6.2 time period and I’ve sent a message to someone with a Red Hat email address who may have much more of an idea how to fix it.
Found the solution, which for now is to use the boot parameter/option “acpi_backlight=native” on 5.x/6.x kernels.
I had tried this previously, but was probably using the boot option incorrectly, or mistakenly using “acpi_video=native” instead of “acpi_backlight=”. So it never worked.
Using the “YaST Boot Loader” app I was able to make the correct option part of the default boot option string.
The same boot option also restores backlight control when booting from a Fedora 38 ISO (kernel 6.2.9), or Linux Mint 21.2 (kernel 5.15). This is important to note since backlight control code changed during the 6.1/6.2 kernel release period.
This boot parameter should theoretically restore backlight control on any iMac12,1 or iMac12,2 model, with 6750M, 6770M, or 6970M cards (but that last one is unconfirmed). It will be necessary until a fix to use this backlight mode by default on these models can be integrated back into the kernel.
According to reports I’ve read, this seemed to work fine up until around kernel 5.4, and then kernels around 5.7/5.8 started having this problem.
