On 18.04.22 18:56, Stefano Babic wrote: > Hi Jan, > > On 18.04.22 17:52, Jan Kiszka wrote: >> On 18.04.22 15:03, Stefano Babic wrote: >>> Hi, >>> >>> On 17.04.22 11:10, Stefano Babic wrote: >>>> Hi Mark, >>>> >>>> On 16.04.22 12:07, Mark Jonas wrote: >>>>> Hi, >>>>> >>>>> In my setup the test bootloader_ebg_defconfig is broken. >>>>> >>>>> RUN FileNotFoundTest >>>>> RUN CrapFileTest >>>>> RUN ImgNameErrorTest >>>>> RUN ValidImageTest >>>>> make[1]: *** [/mnt/scripts/acceptance-tests/CheckImage.mk:115: >>>>> ValidImageTest] Error 1 >>>>> make: *** [Makefile:494: acceptance-tests] Error 2 >>>>> >>>>> https://gitlab.com/toertel/docker-image-swupdate-contribute/-/jobs/2342017362 >>>>> >>>>> >>>>> >>>>> I bisected the problem with the following result. >>>>> >>>>> There are only 'skip'ped commits left to test. >>>>> The first bad commit could be any of: >>>>> b8897ed695e1cd954859142b14ec8546d2e7994a >>>>> 3a4e626b857c6f8526f0e2716e96d15955b00c79 >>>>> We cannot bisect more! >>>>> >>>> >>>> This is not due to some changes in SWUpdate or EFIBootGuard, but how >>>> the two projects are working now. Since 3a4e626b8, mostly added to >>>> help Debian's integration, the interface to the bootloader is >>>> *dynamic* instead of static. SWUpdate does not link to the bootloader >>>> interface, but loads it via dlopen() at startup. Expanding the output >>>> above, I can reproduce the issue you report, and I get : >>>> >>>> [INFO ] : SWUPDATE running : [print_registered_bootloaders] : >>>> Registered bootloaders: >>>> [INFO ] : SWUPDATE running : [print_registered_bootloaders] : >>>> uboot loaded. >>>> [INFO ] : SWUPDATE running : [print_registered_bootloaders] : >>>> none loaded. >>>> [INFO ] : SWUPDATE running : [print_registered_bootloaders] : >>>> grub loaded. >>>> [INFO ] : SWUPDATE running : [print_registered_bootloaders] : ebg >>>> shared lib not found. >>>> [ERROR] : SWUPDATE failed [0] ERROR core/swupdate.c : main : 778 : >>>> Default bootloader interface 'ebg' couldn't be loaded. >>>> >>>> Reason is that the shared library "libebgenv.so" cannot be found. The >>>> test environment you have (I have not seen "make install" when >>>> efibootguard is built) have installed outside the library path. >>>> >>>> See also Christian's : >>>> >>>> commit cbbd7a343a0263565baeb5549c7086a63114aca0 (denx/coverity_scan, >>>> coverity_scan) >>>> Author: Christian Storm <[email protected]> >>>> Date: Tue Mar 22 12:29:03 2022 +0100 >>>> >>>> CI: Adapt EFI Boot Guard build >>>> >>>> Runtime-dynamic bootloader selection requires >>>> the libebgenv.so shared library to be available. >>>> Also adapt to the official installation instructions. >>>> >>>> >>>> In fact, I can easy fix the error above if I set LD_LIBRARY_PATH to >>>> the path where the library is installed. Just be sure that the library >>>> can be found, and the issue disappears. >>>> >>>>> I had to skip b8897e because it does not compile. >>>>> >>> >>> Digging deeper, I have found why it this work on SWUpdate's pipeline. >>> The issue raises if efibootguard is installed on a different path, that >>> is running configure --prefix <>. In fact, the SONAME for the library >>> differs form standard. >>> >>> I set --prefix /usr/local, and I can easy reproduce the issue. Checking >>> ldconfig cache, I see: >>> >>> libebgenv-0.10.0.so (libc6,x86-64) => /usr/local/lib/libebgenv-0.10.0.so >>> >>> compared to libubootenv: >>> >>> libubootenv.so.0 (libc6,x86-64) => /usr/local/lib/libubootenv.so.0 >>> libubootenv.so (libc6,x86-64) => /usr/local/lib/libubootenv.so >>> s >>> >>> So it works just with the exact name. This fixes your build: >>> >>> diff --git a/bootloader/ebg.c b/bootloader/ebg.c >>> index 2cd6a65..a63f5f2 100644 >>> --- a/bootloader/ebg.c >>> +++ b/bootloader/ebg.c >>> @@ -198,7 +198,7 @@ static bootloader ebg = { >>> >>> static bootloader* probe(void) >>> { >>> - void* handle = dlopen("libebgenv.so", RTLD_NOW | RTLD_GLOBAL); >>> + void* handle = dlopen("libebgenv-0.10.0.so", RTLD_NOW | >>> RTLD_GLOBAL); >>> if (!handle) { >>> return NULL; >>> } >>> >>> But of course, we won't do this - the issue with SONAME should be solved >>> inside EFIBootguard. >>> >> >> There is a link libebgenv.so -> libebgenv-0.10.0.so installed, also if >> --prefix is set during configure (just re-tested for 0.10). Seems that >> is missing in your setup, thus your dlopen will fail. > > The link is set (this is /usr/local/lib): > > -rwxr-xr-x 1 root root 50744 Apr 18 14:53 libebgenv-0.10.0.so > -rw-r--r-- 1 root root 62468 Apr 18 14:53 libebgenv.a > lrwxrwxrwx 1 root root 19 Apr 18 14:53 libebgenv.so -> > libebgenv-0.10.0.so > > and in fact, if I set LD_LIBRARY_PATH, everything is fine. But the > different naming is not recognized by ldconfig (that searches in > /usr/local/lib), see above. I guess this is the reason why is not > running on Mark's build - in SWUpdate's CI, libebgenv is installed on > the default linux (x86-64) path, and there is not this issue.
OK, lib release numbering [1] chosen for libebgenv.so is actually requiring to open "libebgenv-0.10.0.so" - unless some other search path helps out. But even then the logic behind it remains "only the exact version is supposed to be compatible to what you want". Using the link (where it works) would just paper over it. Christian, that versioning choice is impractical for users. We need to switch to interface numbering and actually manage revisions. Jan [1] https://www.gnu.org/software/libtool/manual/html_node/Release-numbers.html -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/f56a4e38-b905-0dfc-c306-68eca5585004%40web.de.
