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

[Patrick Ohly]

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?

> >> 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.

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?

-- 
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.