Re: sstate can result in inconsistent kernel and modules

[Jan Kiszka <jan.kiszka@siemens.com>]

On 17.10.22 08:20, Moessbauer, Felix Jonathan (T CED INW-CN) wrote:
>> -----Original Message-----
>> From: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
>> Sent: Monday, October 17, 2022 2:00 PM
>> To: Moessbauer, Felix Jonathan (T CED INW-CN)
>> <felix.moessbauer@siemens.com>; isar-users@googlegroups.com; Schmidt,
>> Adriaan (T CED SES-DE) <adriaan.schmidt@siemens.com>
>> Cc: Schild, Henning (T CED SES-DE) <henning.schild@siemens.com>
>> Subject: Re: sstate can result in inconsistent kernel and modules
>>
>> On 16.10.22 07:48, Moessbauer, Felix Jonathan (T CED INW-CN) wrote:
>>> Dear ISAR users,
>>>
>>> I just discovered the following bug on a re-build using the sstate cache:
>>>
>>> The installed kernel version in the image is 5.19.6-1, while the kernel
>> modules are built for 5.19.0-2.
>>> The reason is that the modules are extracted from the sstate cache, but
>> bitbake does not know about the "exact" kernel revision used for building.
>>>
>>> Actually, I don't know how to easily solve that issue, as bitbake does not
>> know about the exact Debian package versions.
>>> But what could be done is to check for version incompatibilities in the final
>> rootfs.
>>> Or we disable the sstate cache for module builds (but I don't know how to
>> do that).
>>
>> How was this inconsistency created? Did you select a different kernel version
>> from the same isar-bootstrap generated apt database? Because if the latter
>> changes, all recipes and cached artifacts downstream should change as well.
> 
> This happened on a Debian bookworm build where kernel updates happen quite often.
> The custom modules have been extracted from the cache, but the target rootfs got a more recent kernel.
> By that, the modules (built for 5.19.0-2) where installed in an image with kernel 5.19.6-1, hence could not be loaded.
> 
> I don't know if there is an apt upgrade running right after assembling the rootfs, or if simply the target rootfs could not be extracted from the cache.
> 
> Maybe, the module recipe should add a runtime depends on the exact version of the kernel used for building.
> This would at least break the build, instead of failing silently.

If we have a an update of the repo, isar-bootstrap should change, and
all packages built after should get their caches invalidated. Looks like
there is something broken along that line.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux