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. -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
