From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7154983062371041280 X-Received: by 2002:a05:6e02:190a:b0:2fc:5333:c879 with SMTP id w10-20020a056e02190a00b002fc5333c879mr4663474ilu.183.1666157804477; Tue, 18 Oct 2022 22:36:44 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a6b:1503:0:b0:6bc:6044:840e with SMTP id 3-20020a6b1503000000b006bc6044840els2308966iov.0.-pod-prod-gmail; Tue, 18 Oct 2022 22:36:43 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4/LQTiTVZ2Ikf8wN/JZPMv2EWKTCVnT4YS3FMyYQHD8DgCzJUeI49yz0apnK/lyWLAda6k X-Received: by 2002:a05:6602:3ca:b0:6a4:16a0:9862 with SMTP id g10-20020a05660203ca00b006a416a09862mr4612239iov.217.1666157803874; Tue, 18 Oct 2022 22:36:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666157803; cv=none; d=google.com; s=arc-20160816; b=uqFHTy2R1jTtvmRDxk9GIj4kl41TKC+g0bUejDIp0PiEZlL0Y/K3fnOoLqw0zqS8WZ 6Ano1RHzFDEVLMOnlO/m2OhnKUjrQOf67rQbxO9ICQ7esUBFAQXIGZ5ZEW4TCmAqXOMN vrQtbxFFgXTP3M3aTy1SESPgYS7Yr97COQDWicyg8JsOsTditAe5+IRb1GsVW87wtrho FpVl3dYWKnPEnfxVFSC6GjneMQF1fPdNuhiqDf//T4CGRPdmKuzJ9h1UNKT41C8AcvC8 ic+reSLgEMnMpzS0qlqpsgYMTZ3AvC6dkxAxH/SJWD9uDbh7/NXSgs4JRHT7pXO8Z6Qa ePEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from; bh=kiZL5Zxrzcjn7vvsBLMz6n+ZvEDUbX50nXJT+UCFGF0=; b=oQsi9NkhFsFH4S1bj0BmbN6IjbJuq39He9lWC0Dqdr32Ty2E0pk1oJXEJc0q1STA42 wQfSrIFvsRRmhS5uKuOCLlYcRvp0jPu7mDsqhb9MWWoDuALXveTyt9OP8W2b/LbAZErn /dbruboB5eEwjjG2xs7qRxhVp/0O/1Z71Xur/xAqQhcWdeKdq8uznX5tb4aP7cx9J/Ru wwk2lUvA9u+BXcb22+ZkdXgSN8VPZpkXt6v8N8FUNMqgy1jPnjCc9WxvcItA7yQAjcKS 9ELLHpMdASxSlWbRMSLWkovWZ5IH2JY9chwM0oxcKTPC6fVuFm9GfnEZX3MZThXM2sXL l8aA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id y5-20020a056e020f4500b002f93f7596c4si575968ilj.4.2022.10.18.22.36.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 18 Oct 2022 22:36:43 -0700 (PDT) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from hp.localnet (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 29J5aaxu023358 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 07:36:37 +0200 From: Uladzimir Bely To: "isar-users@googlegroups.com" , "MOESSBAUER, FELIX JONATHAN" Subject: Re: sstate can result in inconsistent kernel and modules Date: Wed, 19 Oct 2022 08:36:35 +0300 Message-ID: <4734502.OV4Wx5bFTl@hp> In-Reply-To: References: <7c301a59-7be2-2664-fc72-f5936276a43e@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: Cp6yFGP8YTFT In mail from =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0=BD=D0=B8= =D0=BA, 17 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2022 =D0=B3. 09:20:25= +03 user MOESSBAUER,=20 =46ELIX JONATHAN wrote: > > -----Original Message----- > > From: Kiszka, Jan (T CED) > > Sent: Monday, October 17, 2022 2:00 PM > > To: Moessbauer, Felix Jonathan (T CED INW-CN) > > ; isar-users@googlegroups.com; Schmidt, > > Adriaan (T CED SES-DE) > > Cc: Schild, Henning (T CED SES-DE) > > Subject: Re: sstate can result in inconsistent kernel and modules > >=20 > > On 16.10.22 07:48, Moessbauer, Felix Jonathan (T CED INW-CN) wrote: > > > Dear ISAR users, > > >=20 > > > I just discovered the following bug on a re-build using the sstate > > > cache: > > >=20 > > > The installed kernel version in the image is 5.19.6-1, while the kern= el > >=20 > > modules are built for 5.19.0-2. > >=20 Hello. Could you please clarify where did this '5.19.6.1' version could come from?= =20 Yesterday I tried to build qemuamd64-bookworm image with example-module in= =20 order to debug the issue you've described, but what I could see in the=20 resulted image is that both module and kernel versions were 5.19.0-2. So, I= =20 can't get why you could have even newer kernel version few days ago. Some=20 custom recipe for the kernel? Also, with sstate-cache enabled, attempt to rebuild the image took everythi= ng=20 from the sstate cache. So, as expected, id didn't even tried to update the= =20 mirrors. And I'm wondering what in your case could trigger the issue (e.g.,= =20 you might was debugging something and editing some recipes at that time). > > > The reason is that the modules are extracted from the sstate cache, b= ut > >=20 > > bitbake does not know about the "exact" kernel revision used for buildi= ng. > >=20 > > > Actually, I don't know how to easily solve that issue, as bitbake does > > > not > >=20 > > know about the exact Debian package versions. > >=20 > > > But what could be done is to check for version incompatibilities in t= he > > > final>=20 > > rootfs. > >=20 > > > Or we disable the sstate cache for module builds (but I don't know how > > > to > >=20 > > do that). > >=20 > > 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 n= ot > be loaded. >=20 > 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. >=20 > 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. >=20 > Felix >=20 > > Jan > >=20 > > -- > > Siemens AG, Technology > > Competence Center Embedded Linux