On Wed, Sep 05, 2018 at 10:32:32AM +0800, Lu.Jiang wrote: > 在 2018年09月05日 08:33, Tom Rini 写道: > >On Tue, Sep 04, 2018 at 10:33:43AM +0800, Lu.Jiang wrote: > >>在 2018年09月04日 10:26, Tom Rini 写道: > >>>On Tue, Sep 04, 2018 at 10:15:44AM +0800, Lu.Jiang wrote: > >>>>在 2018年09月03日 10:01, Lu.Jiang 写道: > >>>>>在 2018年08月31日 21:52, Tom Rini 写道: > >>>>>>On Fri, Aug 31, 2018 at 10:15:09AM +0800, Jiang Lu wrote: > >>>>>> > >>>>>>>When there is no useful efi in $kerneldir, try copy > >>>>>>>all efi from EFI/BOOT into boot image. > >>>>>>> > >>>>>>>Signed-off-by: Jiang Lu <lu.ji...@windriver.com> > >>>>>>>--- > >>>>>>> .../wic/files/wic/plugins/source/bootimg-efi.py | 12 ++++++++++++ > >>>>>>> 1 file changed, 12 insertions(+) > >>>>>>> > >>>>>>>diff --git > >>>>>>>a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py > >>>>>>>b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py > >>>>>>>index 0eb86a0..d435268 100644 > >>>>>>>--- a/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py > >>>>>>>+++ b/meta/recipes-support/wic/files/wic/plugins/source/bootimg-efi.py > >>>>>>>@@ -231,6 +231,18 @@ class BootimgEFIPlugin(SourcePlugin): > >>>>>>> else: > >>>>>>> raise WicError("unrecognized bootimg-efi loader: %s" > >>>>>>>% > >>>>>>> source_params['loader']) > >>>>>>>+ os.listdir("%s/EFI/BOOT/" % hdddir) > >>>>>>>+ found_efi = False > >>>>>>>+ for x in os.listdir("%s/EFI/BOOT/" % hdddir) : > >>>>>>>+ if x.endswith(".efi"): > >>>>>>>+ found_efi = True > >>>>>>>+ break; > >>>>>>>+ if not found_efi: > >>>>>>>+ cp_cmd = "cp %s/EFI/BOOT/*.efi %s/EFI/BOOT/" % > >>>>>>>(kernel_dir, hdddir) > >>>>>>>+ try: > >>>>>>>+ exec_cmd(cp_cmd, True) > >>>>>>>+ except: > >>>>>>>+ pass > >>>>>>> except KeyError: > >>>>>>> raise WicError("bootimg-efi requires a loader, none > >>>>>>>specified") > >>>>>>I'm not sure this is the right approach. If you don't have things set > >>>>>>up for automagic finding you should use bootimg-partition and > >>>>>>IMAGE_BOOT_FILES. I'm doing this right now for some EFI projects > >>>>>>because it's also bad form to dump everything into EFI/BOOT and some > >>>>>>things should end up in EFI/vendorname or similar. > >>>>>> > >>>>Hi Tom, > >>>> > >>>>By indicating IMAGE_BOOT_FILES for bootimg-partition, can perform copy > >>>>file > >>>>work. While we still need the code in bootimg-efi to re-generate grub.cfg. > >>>> > >>>>I prefer use bootimg-efi for this case, but we can add a new parameter to > >>>>distinguish kernel dir & bootloader dir(for efi files) > >>>I'm still not seeing why we need this, sorry. > >>> > >>>If we need files in the ESP in EFI/BOOT/ then in our root filesystem > >>>they're already in as /boot/efi/EFI/BOOT and we say that we populate > >>>things from /boot/efi and this also gets us things like > >>>/boot/efi/EFI/vendor and so forth populated and matches other Linux > >>>distributions. > >>> > >>>If we need something more complex, we have IMAGE_BOOT_FILES available > >>>and can and should be populating the deploy directory like other > >>>architectures and loaders do. > >>> > >>bootimg-efi performed following for grub boot partition: > >> > >>1.copy grub-efi-* from $KERNEL_DIR into $/boot/EFI/BOOT/ > >> > >>2.copy bzImage from $KERNEL_DIR into $/boot/ > >> > >>3.generate grub.cfg based select booting device. > >> > >>On target system, if we select booting device from running system as source > >>for booting-efi will meet issue. Because the *.efi & bzImage is not in the > >>same directory. > >> > >>As you suggested, we may invoke booting-partition by feeding > >>$IMAGE_BOOT_FILES to indicating file need copy, this could done work 1 & 2. > >>While we still need generated grub.cfg. > >One of the great strengths of wic is that it can cover a lot of > >different fairly complex use cases automatically, and still provide an > >expert "out" for when you're doing something fairly different but still > >want to leverage wic. While I don't understand the use case of turning > >a live system into a wic image, it sounds like what you're looking for > >is the case of "and we provide our own loader config file". You should > >be including grub.cfg into the IMAGE_BOOT_FILES list and generate this > >however you need it. Since you've already booted you should already > >have a correct EFI/ directory to look at (we ought to stop having > >top-level bzImage, that's not right, but that's orthogonal to this > >thread). > > The grub.cfg is generated in bootimg-efi.py. At least, it need include the > new generated uuid info for rootfs partition.
Or, you generate the grub.cfg outside of wic and tell wic what newly generated UUIDs to use, and just use bootimg-partition.py and IMAGE_BOOT_FILES. > So we still need a piece of code from bootimg-efi.py to generate grub.cfg at > runtime. > > The issue this patch try to fix is bootimg-efi assume bzImage & grub-*.efi > located at top level of $KERNEL_DIR. (aside, OE $DEPLOY_DIR_IMAGE becomes do_prepare_partition() kernel_dir) Yes, this particular bit of code very much assumes an OE environment as you don't normally see grub-efi-*.efi nor systemd-*.efi like that on the system, and a real problem is that we don't package and ship those files (I know for grub, I guess but didn't check systemd). > This is true for bitbake's deploy dir. However, it didn't apply to target. > We need provide a way for adding search path for *.efi. I disagree that we need to because in this case you only need to because the EFI binaries don't exist on the target in a normal way. All of that said, perhaps a different way to look at this would be that we could try doing both of: - packaging and shipping grub-efi-*.efi (and systemd-boot equivalents) - Similar to how plugins/imager/direct.py can fiddle with /etc/fstab add some option to fiddle the various known loader config files to whack 'root=PARTUUID=well-formatted-uuid' to the new UUID. Then you shouldn't need to generate a new grub.cfg and should be able to use IMAGE_BOOT_FILES to map things to where you want them to go and still get your grub.cfg file updated. -- Tom
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core