This is a feature request for YP1.7. [oe-core recipes-bsp seems hard to place in your bugzilla schema.] grub-efi 2.x is built and packaged very differently than grub-bios 2.x (aka grub-pc aka grub). (I am not talking about grub 0.97 aka grub-legacy) The deploy of the composite image is fine but I see no reason it can't package up the modules and scripts as grub-bios does. This allows the user to install a full function version of grub on their target if they choose to or create alternative composite images later.
I did take a crack at this and I think I know why the original shortcut was taken. grub-efi and grub-bios want to export to the host sysroot the same install scripts that grub-bios does. bitbake (or an oe-core class) does not let that happen even if the files are identical. This makes it impossible to share a workspace with builds that use grub-bios and grub-efi which is not acceptable. I looked at how Debian does this and there is one grub source package that builds grub-common grub-pc and grub-efi. Possible resoultions: 1) merge grub-bios and grub-efi recipies and build both whenever either is needed. 2) make grub-bios and grub-efi both depend on a new grub-common and do all host sysroot exports from the new recipie. (duplicates grub code 3 times and I am not sure this works) 3) rename scripts or place into subdir for sysroot and change use to use the one needed. Not going to happen: 4) extend bitbake to allow sysroot export duplication if exact same file 5) per-package dependeniecs (sysroots) :) Right now I lean toward #1. However I think the same conflict would exist between any new grub and legacy grub (0.97). Only #3 would help there.
Hongxu can you work with the reporter to re-do you grub, grub-efi patch and ensure that most if not all of Bill's points have been addressed. If things get bogged down, ask for help.
I have not looked at this in a while. We never really started to use Grub on TI platforms. My motivation at the time I wrote this bug was to create an fully contained grub with config and modules etc for netbooting from EFI on Minnowboard. I was trying to get Minnowboard into a test lab at the time. I was able to do this but I think it involved going into the work dir and hacking things up. I will be happy to look at what you come up with. On the bright side: OE now has per-package staging (my #5 above) so this might be a lot easier now.
OE-core has fixed in following commit: commit 6fd0bc313c6035b7de5b7a62cbbcd1d6f546c7f9 Author: Hongxu Jia <hongxu.jia@windriver.com> Date: Wed Jan 17 03:25:58 2018 -0500 grub/grub-efi: fix conflict While installing grub and grub-efi, there are conflict files in ${sysconfdir} ${datadir} ${bindir} ${sbindir}. - Since all of the conflicted files are tools which is common for grub and grub-efi, we split them (except grub-editenv) to grub-common in grub. - The package grub-common runtime depends grub-editenv - The package grub-editenv runtime provides grub-efi-editenv - Remove SYSROOT_DIRS_BLACKLIST - The recipe grub-efi does not generate the duplicated files and use runtime depends grub-common to instead Debian and Fedora do the similar thing. Debian use a common package grub-common for both of pc bios and efi, and use package grub-pc-bin for pc bios, grub-efi-amd64-bin for efi. Both of grub-pc-bin and grub-efi-amd64-bin requires grub-common. https://packages.debian.org/sid/grub-common https://packages.debian.org/jessie/grub-pc-bin https://packages.debian.org/jessie/grub-efi-amd64-bin Fedora use a common package grub2-tools for both of pc bios and efi, and use package grub2 for pc bios, grub2-efi-modules for efi. Both of grub2 and grub2-efi-modules requires grub2-tools. https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-tools-2.02-0.34.fc24.x86_64.html https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-2.02-0.34.fc24.x86_64.html https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-efi-modules-2.02-0.34.fc24.x86_64.html [YOCTO #11639] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>