Re: [PATCH v3 2/3] deploy boot files via sstate-cache

["MOESSBAUER, Felix" <felix.moessbauer@siemens.com>]

On Mon, 2024-02-26 at 16:32 +0300, Uladzimir Bely wrote:
> On Wed, 2024-01-10 at 05:27 +0100, 'Jan Kiszka' via isar-users wrote:
> > On 09.01.24 15:04, Anton Mikanovich wrote:
> > > 09/01/2024 15:46, Jan Kiszka wrote:
> > > > Careful with renaming, I'm not sure of we aren't picking up the
> > > > DTBs
> > > > from there and also relying on the names as the firmware will
> > > > need
> > > > specific naming as well. This needs at least double-checking.
> > > > 
> > > > Jan
> > > > 
> > > It looks like there is no other solution, because different
> > > distros
> > > may
> > > have
> > > differencies in their dtb files.
> > > Downstreams are rely on Isar output paths, so we should at least
> > > create
> > > a item
> > > in RECIPE-API-CHANGELOG.md.
> > > 
> > 
> > This is about naming for the kernel or the firmware, not for the
> > layer.
> > Again: Careful! Also, it would likely be better to enhance
> > DEPLOY_DIR_IMAGE with the distro, rather than messing with the file
> > names.
> > 
> > Jan
> > 
> > -- 
> > Siemens AG, Technology
> > Linux Expert Center
> > 
> 
> Currently we have an internal solution that uses a subdirectory named
> according to the image built (e.g., 'isar-image-base-bootfiles').
> This
> saves original DTB namings, but we just have them in a separate dir.
> This, of course, also needs mentioning in RECIPE-API-CHANGELOG.md
> since
> imagers/CI may use the files for their purpose.
> 
> Anyway, there is another issue in the whole patchset. We make sstate
> do
> things it is not supposed to do. And if the user wants to completely
> disable sstate, they at least won't find kernel/DTB files in deploy
> dir. At most, imager can fail if it looks for them here.

Is this really true? Just because we deploy through sstate (which is
anyways proposed by yocto), does not mean that we MUST use the cache.

Unfortunately, the concept documentation of yocto is a bit imprecise
regarding this point:
https://docs.yoctoproject.org/overview-manual/concepts.html?highlight=sstate#setscene-tasks-and-shared-state

> 
> A simple way to reproduce the issue with disabled sstate:
> 
> 1. Run 'kas-container menu', configure stm32mp15x-bullseye target
> 
> 2. Run 'kas-container shell'
> 
> 3. Disable sstate
> 
> ```
> builder@25df5af8cc0a:/build$ echo 'INHERIT:remove = "sstate"' >>
> conf/local.conf

This is not the correct way to disable sstate. Instead, please use 
SSTATE_SKIP_CREATION="1". Also I'm unsure if disabling sstate cache is
even supported globally (at least in yocto it is not).

Felix

> ```
> 
> 4. Build the image
> 
> ```
> builder@25df5af8cc0a:/build$ bitbake isar-image-base
> ```
> 
> 5. Check `build/tmp/deploy/images` => there are no any kernel/initrd
> files, they exist only in `tmp/work/debian-bullseye-armhf/isar-image-
> base-stm32mp15x/1.0-r0/deploy/`
> 
> Some other targets (like phyboard-mira) even fail in imager, since it
> needs the files to be in deploy dir.
> 
> I guess, later we need to rework the functionality the following way:
> 
> 1. Don't use sstate for copying files, they should be directly
> deployed;
> 2. Split boot files extracted from rootfses with different distro and
> targets (e.g., `-base`, `-debug`, etc) - but with no sstate help.
> 
> 
> 

-- 
Siemens AG, Technology
Linux Expert Center