Re: [OE-core] [PATCH v8] systemd: update to v254

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sun, 2023-08-06 at 14:34 +0100, Luca Bocassi wrote:
> On Sun, 6 Aug 2023 at 14:22, Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> > 
> > On 06/08/2023 14:15:27+0100, Luca Bocassi wrote:
> > > Where does that objcopy command come from? It looks awfully like it is
> > > hard-coding VMAs? That cannot possibly work reliably, the actual VMAs
> > > have to be calculated based on the components being added to the PE.
> > > I'd recommend to use 'ukify' as that makes it much easier, and
> > > actually we have an intern working to add a bbclass for that just now.
> > > But it's not needed, you can do the calculations by hand too, dracut
> > > used to do something similar and was fixed some months ago iirc.
> > 
> > This is from do_prepare_partition in scripts/lib/wic/plugins/source/bootimg-efi.py
> 
> https://git.yoctoproject.org/poky/plain/scripts/lib/wic/plugins/source/bootimg-efi.py
> 
>                 objcopy_cmd = "%s-objcopy" % target_sys
>                 objcopy_cmd += " --enable-deterministic-archives"
>                 objcopy_cmd += " --preserve-dates"
>                 objcopy_cmd += " --add-section
> .osrel=%s/usr/lib/os-release" % staging_dir_host
>                 objcopy_cmd += " --change-section-vma .osrel=0x20000"
>                 objcopy_cmd += " --add-section .cmdline=%s" % cmdline.name
>                 objcopy_cmd += " --change-section-vma .cmdline=0x30000"
>                 objcopy_cmd += dtb_params
>                 objcopy_cmd += " --add-section .linux=%s/%s" %
> (staging_kernel_dir, kernel)
>                 objcopy_cmd += " --change-section-vma .linux=0x2000000"
>                 objcopy_cmd += " --add-section .initrd=%s" % initrd.name
>                 objcopy_cmd += " --change-section-vma .initrd=0x3000000"
>                 objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub, hdddir)
> 
> Yeah that's a bug, and it needs to be fixed, those sizes can't be
> hard-coded like that, as soon as you build a slightly different stub
> it's going to break.

Given this is causing multiple breakages on the automated testing, the
systemd upgrade shouldn't have merged. It has. Technically I should
really just revert everything (the upgrade and the fixes on top) and
wait until someone has a fix for this. I'd prefer not to since we
obviously do want to upgrade eventually.

Is there anything we can do with this short term to make things work?
Can the offsets we need be read from somewhere?

Cheers,

Richard