[meta-intel] [PATCH RFC 0/4] First pass at combo app and secure boot support

[Cal Sullivan]

On 06/13/2017 11:24 PM, Patrick Ohly wrote:
> On Tue, 2017-06-13 at 14:15 -0700, Cal Sullivan wrote:
>> On 06/12/2017 01:57 AM, Patrick Ohly wrote:
>>> On Fri, 2017-06-09 at 18:30 -0700, California Sullivan wrote:
>>>> While its possible to use wic with it thanks to the uefiapp_deploy
>>>> function, the init scripts in the initramfs we currently ship are made
>>>> for live images, and will attempt to mount and boot a rootfs.img, which
>>>> will fail.
>>> Why does it fail? Aside from the different content of bootx64.efi, I'd
>>> expect the rest of the disk image to be unchanged, so I can't imagine
>>> why it might fail.
>> Refkit uses its own initramfs which uses the initramfs-framework
>> scripts. These handle mounting and booting a root partition correctly.
>> Core-image-minimal-initramfs uses initramfs-live-boot, which only seems
>> to work with a rootfs.img placed in the EFI FAT partition.
> Yes, I know. But why does choosing the UEFI combo app as bootx64.efi
> influence the rootfs.img? In other words, why is it not where the
> initramfs-live-boot expects it?
Ah, I understand your question now.
Choosing the UEFI combo app doesn't influence the rootfs.img. The issue 
is that rootfs.img is something made by image-live.bbclass (well, its 
the rootfs filesystem renamed to rootfs.img), which we don't have when 
building a wic image. Wic images in OE-core don't seem to be using an 
initrd or initramfs at all right now, so they don't have this issue.

>
>>>> The second issue is that this class is dependant on an INTIRD_IMAGE.
>>>> This means that the class cannot be added via IMAGE_CLASSES in a global
>>>> context (such as local.conf), as it would create a circular dependency.
>>>> So, in order to apply this while using wic alone, we would need to
>>>> conditionally inherit it on every non-initrd/initramfs image target
>>>> through bbappends, which would be a little messy. I've already tried
>>>> that workaround successfully, but I'm currently brainstorming solutions
>>>> looking for something cleaner.
>>> This is presumably a result of changing INITRD_LIVE? It might be better
>>> to not rely or affect image-live.bbclass at all.
>>>
>>> Also note that the comment about that particular change is about aspects
>>> ("copying to rootfs", "swupd bundle support") which might not be
>>> applicable anymore.
>>>
>> This is due to the do_uefiapp[depends] section containing
>> ${INITRD_IMAGE}:do_image_complete. Inheriting the class directly, the
>> INITRD_LIVE addition shouldn't do anything, as we don't inherit
>> image-live in that case.
> do_uefiapp shouldn't be needed in an initramfs image, even when
> uefi-comboapp.bbclass happens to be inherited for all images. That's the
> real issue that needs to be solved, the circular dependency is just a
> side effect.
Right. It seems like right now we don't have a uniform way to 
differentiate them, however. Checking IMAGE_FSTYPES could work, as an 
initramfs image will generally not have wic or hddimg, but that may be 
more of a workaround than a solution. I think OE-core could use a way to 
easily differentiate between the two, and variables similar to 
IMAGE_CLASSES, but only applying to one or the other.
> Apparently EFI_PROVIDER is some kind of configuration option which tells
> image creation code about the boot loader. I've not found documentation
> about that mechanism. Is that something that could also be used for UEFI
> combo app, with or without wic?
>
EFI_PROVIDER is inherited when building live images. If we have both wic 
and hddimg (or live) in IMAGE_FSTYPES, then it does work thanks to this, 
but its not behavior we should rely on.

Thanks,
Cal