[meta-intel] [PATCH V2 3/5] classes: Add uefi-comboapp bbclass

[Patrick Ohly]

On Thu, 2017-07-06 at 18:30 -0700, California Sullivan wrote:
> +python do_uefiapp() {
> +    import glob, re
> +    from subprocess import check_call
> +
> +    build_dir = d.getVar('B')
> +    deploy_dir_image = d.getVar('DEPLOY_DIR_IMAGE')
> +
> +    cmdline = '%s/cmdline.txt' % build_dir
> +    linux = '%s/%s' % (deploy_dir_image, d.getVar('KERNEL_IMAGETYPE'))
> +    initrd = '%s/initrd' % build_dir
> +
> +    stub_path = '%s/linux*.efi.stub' % deploy_dir_image
> +    stub = glob.glob(stub_path)[0]
> +    app = re.sub(r"\S*(ia32|x64)(.efi)\S*", r"boot\1\2", os.path.basename(stub))
> +    executable = '%s/%s' % (deploy_dir_image, app)

There's a conceptual problem here: the UEFI combo app is different for
each image, but the path created here for it isn't. That means two
different images end up with conflicting files.

I'm going to fix this together with making the class usable for refkit.
In refkit, we had the ability to create multiple combo apps per image.
We used that to create one for removable media and one for fixed media
(after installation), with different boot=PARTUUID=xxx parameters. This
way, an installed image never ended up booting from the install media.

I'll add that aspect back to the uefi-comboapp bbclass.


> +do_uefiapp_sign[depends] += "${PN}:do_uefiapp_deploy \
> +                             sbsigntool-native:do_populate_sysroot"

Why should do_uefiapp_sign run after do_uefiapp_deploy? The way it is
now, /boot/EFI/BOOT in the rootfs gets populated by do_uefiapp_deploy
with the unsigned app, which isn't how it should be.

I'll try it the other way around.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.