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