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

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

Hello,

I've been looking a bit more at this. there is definitively another
issue here which is the first one I found:

x86_64-poky-linux-objcopy: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: file format not recognized

This is the main issue here.

$ file /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
/home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: MS-DOS executable PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
$ objdump -p /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub (.reloc): section flag STYP_GROUP (0x4) ignored
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub (.reloc): section flag STYP_COPY (0x10) ignored
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub (.reloc): section flag STYP_GROUP (0x4) ignored
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub (.reloc): section flag STYP_COPY (0x10) ignored
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
objdump: /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: file format not recognized

I tested with v253.7 and I properly get:

$ file /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
/home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows
$ ./build-st/tmp/sysroots-components/x86_64/binutils-cross-x86_64/usr/bin/x86_64-poky-linux/x86_64-poky-linux-objdump -h /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub

/home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:     file format pei-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         0000d7f0  0000000000004000  0000000000004000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .reloc        0000000c  0000000000012000  0000000000012000  0000dc00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00002ab0  0000000000013000  0000000000013000  0000de00  2**4
                  CONTENTS, ALLOC, LOAD, DATA
  3 .dynamic      00000100  0000000000016000  0000000000016000  00010a00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  4 .rela         00000630  0000000000017000  0000000000017000  00010c00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .dynsym       00000018  0000000000018000  0000000000018000  00011400  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .sdmagic      0000002a  000000000001a460  000000000001a460  00011600  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

I really believe the recipe is not generating a working efi.stub. Can
you check?


On 06/08/2023 14:56:16+0100, Luca Bocassi wrote:
> On Sun, 6 Aug 2023 at 14:50, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > 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?
> 
> The Arch wiki has good and concise documentation on how to do it:
> 
> https://wiki.archlinux.org/title/Unified_kernel_image#Manually
> 
> This is the equivalent fix that was merged in Dracut some months ago:
> 
> https://github.com/dracutdevs/dracut/commit/f32e95bcadbc5158843530407adc1e7b700561b1

> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#185570): https://lists.openembedded.org/g/openembedded-core/message/185570
> Mute This Topic: https://lists.openembedded.org/mt/100516497/3617179
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alexandre.belloni@bootlin.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com