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

[Patrick Ohly]

On Wed, 2017-06-14 at 11:04 -0700, Cal Sullivan wrote:
> 
> 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.

If the current core-image-minimal-initramfs is so specific to the
image-live.bbclass, then it shouldn't be the default for all image
classes but rather get chosen specifically only when appropriate.

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

There's probably room for a initramfs-image.bbclass which does the
common work, like setting IMAGE_FSTYPES. Then bb.data.inherits_class()
could be used to check for initramfs images.

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

Hmm, systemd-bootdisk.wks (the default in meta-intel) seems to rely on
EFI_PROVIDER getting inherited. I had the impression that whatever image
class is used, that class was expected to inherit EFI_PROVIDER.

See
https://github.com/intel/intel-iot-refkit/commit/d1f14adc47d7c90f528c34c00140522615b4ca49

I think what broke without that change was building refkit-image-common
with wic when using Poky as distro, because artifacts required by
the .wks file were not getting generated.

So to me, EFI_PROVIDER still looks like something that is not (or should
not be) specific to image-live.bbclass.

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