[OE-core] [PATCH 4/5] bootimage.bbclass: Improve EFI & PCBIOS+EFI ISO support
Darren Hart
dvhart at linux.intel.com
Thu Sep 12 20:28:39 UTC 2013
On Thu, 2013-09-12 at 15:14 -0500, Jason Wessel wrote:
> On 09/12/2013 01:09 PM, Darren Hart wrote:
> > On Thu, 2013-09-12 at 12:19 -0500, Jason Wessel wrote:
> >> Using the latest mkisofs it is possible to generate 3 different types
> >> of ISO images, which can be used in various scenarios.
> >>
> >> 1) PCBIOS Only ISO
> >> - This option remains unchanged by this commit
> >> - Uses syslinux menus
> >> - Can be directly copied with dd to a USB device
> >> - Can be burned to optical media
> >>
> >> 2) EFI Only ISO
> >> - Uses grub 2 menus
> >> - Can be burned to optical media
> >> - If you want to use this image on a USB device
> >> extra steps must be taken in order to format the USB
> >> device with fat32, and copy an EFI loader which will
> >> in turn load the iso image
> >>
> >> 3) PCBIOS / EFI ISO
> >> - This is a hybrid image ISO that will work for case 1 or 2
> >> as above with the same restrictions and boot menu types
> >> depending on what type of firmware is installed on
> >> the hardware or depending on if EFI or "Legacy Boot" is
> >> enabled on some UEFI firmwares.
> >>
> >> [YOCTO #4100]
> >>
> >> Signed-off-by: Jason Wessel <jason.wessel at windriver.com>
> >> ---
> >> meta/classes/bootimg.bbclass | 37 ++++++++++++++++++++++++++++++++++---
> >> 1 file changed, 34 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/bootimg.bbclass b/meta/classes/bootimg.bbclass
> >> index 2ed7017..b4301e8 100644
> >> --- a/meta/classes/bootimg.bbclass
> >> +++ b/meta/classes/bootimg.bbclass
> >> @@ -35,6 +35,7 @@ EXCLUDE_FROM_WORLD = "1"
> >>
> >> HDDDIR = "${S}/hddimg"
> >> ISODIR = "${S}/iso"
> >> +EFIIMGDIR = "${S}/efi_img"
> >> COMPACT_ISODIR = "${S}/iso.z"
> >>
> >> BOOTIMG_VOLUME_ID ?= "boot"
> >> @@ -109,19 +110,49 @@ build_iso() {
> >> mkisofs_opts="-R -z -D -l"
> >> fi
> >>
> >
> > Am I missing a patch? I don't have this mkisofs_opts in my
> > bootimg.bbclass....
> >
>
> Yes
>
>
> > How are $mkisofs_opts and ${MKISOFS_OPTIONS} related? Do we need both?
> >
>
> Yes.
>
> I built this patch set on top of the zisofs support I posted a day or
> so ago. I'll include that patch in the series next time, else it
> would create merge conflicts.
OK, thanks.
>
>
> The piece from the other patch is:
>
> + if [ "${COMPRESSISO}" = "1" ] ; then
> + # create compact directory, compress iso
> + mkdir -p ${COMPACT_ISODIR}
> + mkzftree -z 9 -p 4 -F ${ISODIR}/rootfs.img ${COMPACT_ISODIR}/rootfs.img
> +
> + # move compact iso to iso, then remove compact directory
> + mv ${COMPACT_ISODIR}/rootfs.img ${ISODIR}/rootfs.img
> + rm -Rf ${COMPACT_ISODIR}
> + mkisofs_opts="-r"
> + else
> + mkisofs_opts="-R -z -D -l"
> + fi
> +
>
So my objection here is the two variables are VERY similar in name and
there is no way to distinguish between them. Would it make sense to
either append to MKISOFS_OPTIONS above or to rename mkisofs_opts to
something like mkisofs_compression_opts to distinguish them.
>
> The zisofs is a big win for some folks because it will cut their image
> size in 1/2 so they can use single layer media instead of dual layer
> media for example.
Nice.
>
>
>
> >> - if [ "${PCBIOS}" = "1" ]; then
> >> + if [ "${EFI}" = "1" ] ; then
> >> + # Build a EFI directory to create efi.img
> >> + mkdir -p ${EFIIMGDIR}/${EFIDIR}
> >> + cp ${ISODIR}/${EFIDIR}/* ${EFIIMGDIR}${EFIDIR}
> >> + cp ${ISODIR}/vmlinuz ${EFIIMGDIR}
> >> + GRUB_IMAGE="bootia32.efi"
> >> + if [ "${TARGET_ARCH}" = "x86_64" ]; then
> >> + GRUB_IMAGE="bootx64.efi"
> >> + fi
> >> + echo "EFI\\BOOT\\${GRUB_IMAGE}" > ${EFIIMGDIR}/startup.nsh
> >> + if [ -f "${ISODIR}/initrd" ] ; then
> >> + cp ${ISODIR}/initrd ${EFIIMGDIR}
> >> + fi
> >> + build_fat_img ${EFIIMGDIR} ${ISODIR}/efi.img
> >> + fi
> >> +
> >> + # Three ways to build the media
> >> + if [ "${PCBIOS}" = "1" -a "${EFI}" = "1" ]; then
> >
> > Per the Dash as BinSh wiki, the -a syntax is discouraged, best practices
> > seem to be the use of && and || instead:
> >
> > if ([ "${PCBIOS}" = "1" ] && [ "${EFI}" = "1" ]); then
> >
>
>
> Noted for the future :-)
POSIX shell compatibility can be a bit of a hot-button with recipes.
> >
> >> + # 1) Build EFI + PCBIOS hybrid
> >> + mkisofs -A ${BOOTIMG_VOLUME_ID} -V ${BOOTIMG_VOLUME_ID} \
> >> + -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> >> + -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
> >> + ${MKISOFS_OPTIONS} \
> >> + -eltorito-alt-boot -eltorito-platform efi \
> >> + -b efi.img -no-emul-boot \
> >> + ${ISODIR}
> >
> > Has this been verified on any 32 bit PCBIOS platforms?
>
>
> Yes, on tunnel creek based hardware.
>
>
> > It was my understanding the many 32 bit PCBIOS systems had very buggy
> > el-torito support and didn't deal well with multiple el-torito images on
> > the same disk. Although... looking at the command above, I'm not sure
> > you're doing this with mutliple images. Do you have the syslinux and the
> > efi image combined in the same efi.img?
>
>
> My testing showed it worked for both EFI only and EFI+PCBIOS. In the
> case of the EFI+PCBIOS image there are two eltorito images, but in the
> case of the EFI only, there is only one, so at least you have two
> options. The Fedora install media uses the EFI+PCBIOS style image, so
> if that booted on the hardware you had problems with, this will too.
>
>
> >
> > Has this been verified to work on USB media?
>
>
> The image only works on USB media with the PCBIOS.
>
>
> > It was explained to me that, at least for some implementations, if the
> > boot device selection code will not look for ISO9660 on anything that
> > doesn't have a block size of 2048, making it give up on a USB device
> > before even attempting to find the ISO9660 FS.
>
>
> Is there some magic argument to mkisofs that would cause this to
> change the block size? Given that the ISO's I created with EFI would
I don't think so. This was something Saul and I crashed into during our
efforts. Maybe there is something, but I haven't seen it. I was thinking
this block size was device dependent.... can it be changed in software?
> not work directly as a USB image I suspect I have one of the of those
> implementations. Of course it can be worked around by copying the ISO
> onto a partition and using a different loader to deal with it.
>
> I guess my point here is that some further work is probably needed
> down the road, but the first pass works for the important cases (like
> real optical media).
Agreed.
> >
> >
> >> + elif [ "${PCBIOS}" = "1" ] ; then
> >> + # 2) Build PCBIOS only media
> >> mkisofs -V ${BOOTIMG_VOLUME_ID} \
> >> -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> >> -b ${ISO_BOOTIMG} -c ${ISO_BOOTCAT} $mkisofs_opts \
> >> ${MKISOFS_OPTIONS} ${ISODIR}
> >> else
> >
> > This should also verify that we are building for EFI. !PCBIOS != EFI. If
> > none of these options eval to true, an error should be printed
>
>
>
> This case cannot actually happen, thanks to you and Richard (which I got from git blame)
>
> # Include legacy boot if MACHINE_FEATURES includes "pcbios" or if it does not
> # contain "efi". This way legacy is supported by default if neither is
> # specified, maintaining the original behavior.
> def pcbios(d):
> pcbios = base_contains("MACHINE_FEATURES", "pcbios", "1", "0", d)
> if pcbios == "0":
> pcbios = base_contains("MACHINE_FEATURES", "efi", "0", "1", d)
> return pcbios
Hah, well OK then ;-) Still, these sort of implicit things often cause
issues during bug analysis, but this one isn't a big deal. So, fine.
> One or the other will always be set.
>
> >
> >> - bbnote "EFI-only ISO images are untested, please provide feedback."
> >> mkisofs -V ${BOOTIMG_VOLUME_ID} \
> >> -o ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso \
> >> + -eltorito-alt-boot -eltorito-platform efi \
> >> + -b efi.img -no-emul-boot \
> >> -r ${ISODIR}
> >> fi
> >>
> >> - isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
> >> + if [ "${PCBIOS}" = "1" ]; then
> >> + isohybrid ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.iso
> >> + fi
> >
> > A comment would be good around the isohybrid block describing what it is
> > doing and why it only applies to PCBIOS.
>
>
> The isohybrid is what allows you to boot the via a USB with a PCBIOS
> by populating the MBR. The EFI firmware skips it entirely, but sure
> I'll add a comment.
Right, you and I know that, but someone that hasn't spent much time on
this might appreciate the heads-up.
Thanks Jason.
--
Darren
>
>
> Cheers,
> Jason.
>
> >
> >>
> >> cd ${DEPLOY_DIR_IMAGE}
> >> rm -f ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.iso
> >
> >
> > Thanks Jason, this is long overdue. Your effort here is very much
> > appreciated.
> >
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
More information about the Openembedded-core
mailing list