Repository navigation
unable to sign dkms modules due to libssl1 dependency #134
Description
Activity
Kernels are currently built on Ubuntu 20.04. We can't switch to 22.04 because that causes similar problems, just for older systems (in fact we only recently reverted such a change). At some point I'll probably have to look into building individual kernels for specific distributions, but it might take a while until I can find the time to do that.
Reacted by samvde and AdamAre there any CI jobs that build the .deb packages? I didn't see anything in the root directory that looks like it, but I'm only familiar with GitLab's CI system, not GitHub's implementation, so I may just be looking in the wrong place.
I'd be willing to contribute towards updating the automation if that would be helpful. I also run an apt repo that supports multiple versions of Debian and have some notes on that which I could share if it'd make things easier for you.
So our setup is a bit weird, because we only host the repository metadata ourselves, the actual packages are hosted on GitHub releases to take some load off the server.
The kernel packages are built on linux-surface. Once thats done, the CI uploads them as a GitHub release and then pushes placeholder files that link to the newly created release to the repo.
On the repo, a CI job that runs on a schedule then downloads the packages, generates / updates the repository metadata, and pushes it to a different branch. That branch is then automatically downloaded by the server and served as
pkg.surfacelinux.com.Reacted by Adam- added a commit that references this issue
on Sep 17, 2023 Hi,
Is there a solution that doesn't require downgrading a security-related package ?
ThanksCan't this be solved by linking
sign-filestatically?
E.g.:diff --git a/scripts/Makefile b/scripts/Makefile index fe56eeef09dd..b487bb3c7c9c 100644 --- a/scripts/Makefile +++ b/scripts/Makefile @@ -29,7 +29,7 @@ HOSTCFLAGS_sorttable.o = -I$(srctree)/tools/include HOSTLDLIBS_sorttable = -lpthread HOSTCFLAGS_asn1_compiler.o = -I$(srctree)/include HOSTCFLAGS_sign-file.o = $(shell $(HOSTPKG_CONFIG) --cflags libcrypto 2> /dev/null) -HOSTLDLIBS_sign-file = $(shell $(HOSTPKG_CONFIG) --libs libcrypto 2> /dev/null || echo -lcrypto) +HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic ifdef CONFIG_UNWINDER_ORC ifeq ($(ARCH),x86_64)
- added a commit that references this issue
on Jun 30, 2024 Look like it's causing a build failure unfortunately. :(
https://github.com/linux-surface/linux-surface/actions/runs/9998610572/job/27637889211#step:7:1163Not sure why, because it works for me locally on Debian. Maybe try removing -ldl from pkg-config output? Or adding static -lc?
Yeah, unfortunately I haven't had the time to look into how it could be fixed yet.
I think adding
-lcfixed it... There's stillwarning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linkingwhich has me worrying that the workaround doesn't work out in the end, but at least a v6.9.9 build is now running.Edit:
-lcbreaks the final executable. I'll try statically linking everything for sign-file next.Explicitly linking libdl dynamically seems to work. Didn't do a thorough test, but at least it seems to fix the dlopen errors when building on Ubuntu 20.04, and the resulting executable runs on 20.04, and on recent Debian.
HOSTLDLIBS_sign-file = -Wl,-Bstatic $(shell $(HOSTPKG_CONFIG) --static --libs libcrypto | sed 's/-ldl//' 2> /dev/null || echo -lcrypto) -Wl,-Bdynamic -ldlI think the reason my original patch works on current systems but not on 20.04, is because glibc 2.34 merged libdl into libc, and 20.04 still has 2.31.
Reacted by Maximilian LuzAhh, for some reason I was also testing on 22.04 and not 20.04... On 20.04 I'm able to reproduce the crash and can confirm that your patch works. Fingers crossed it works on GitHub actions now as well. Thanks!
- added 2 commits that reference this issue
on Aug 4, 2024 I think this can be closed?
Can confirm that this works on Debian 12 with libssl3. Thank you. ❤
It doesn't solve the problem with
/sbin/vboxconfignot signing their kernel module after they compile it, but that seems to be a problem with virtualbox because running/usr/lib/linux-kbuild-6.1/scripts/sign-fileproduces the usage text as expected.- added a commit that references this issue
on May 24, 2026
I got the following error when compiling dkms drivers on the latest surface kernel:
/lib/modules/6.1.6-surface/build/scripts/sign-file: error while loading shared libraries: libcrypto.so.1.1: cannot open shared object file
I use debian testing, and indeed they no longer ship this library. I solved it by installing libssl1.1_1.1.1n-0+deb11u3_amd64.deb as ships with bullseye.
I am not sure where sign-file comes from, but I would assume it would be best to make it compatible with libssl3.