unable to sign dkms modules due to libssl1 dependency #134
Comments
|
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. |
|
Are 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 |
[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 #129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 #131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 #132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 #133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 #134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 #136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
|
Hi, |
|
Can't this be solved by linking 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) |
|
@quo Good idea, thanks! I'll give it a go in the next release. |
Since we build a single kernel package for Ubuntu and Debian, it often has a different compiler and libraries. Among other things, this leads to errors when building and signing external kernel modules via DKMS. In particular, linux-surface/kernel#134. Try to fix this by linking the sign-file binary statically, as suggested by @quo. Signed-off-by: Maximilian Luz <[email protected]>
|
Look like it's causing a build failure unfortunately. :( Not 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 Edit: |
|
For some reason statically linking everything works in my test container but not on github actions... there @quo Do you have any ideas what's going wrong? |
|
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. I 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. |
|
Ahh, 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! |
As suggested by quo at [1]. We need to statically link libcrypto, but dynamically link libdl. [1]: linux-surface/kernel#134 (comment)
As suggested by quo at [1]. We need to statically link libcrypto, but dynamically link libdl. [1]: linux-surface/kernel#134 (comment)
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.
The text was updated successfully, but these errors were encountered: