Re: [swupdate] bootloader_ebg_defconfig broken

[Stefano Babic]

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 <christi...@siemens.com>
> 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.

Regards,
Stefano

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Jan Kiszka]

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.

Jan

[Stefano Babic]

Hi Jan,

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.

[Jan Kiszka]

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