The path in startup.nsh for iso image is corrupted as follows:
fs0:\EFI\BOOT^Hootx64.efi

Using printf will emit correct path which is:
fs0:\EFI\BOOT\bootx64.efi

This happens because of echo command. Switching to printf
like the one used in efi_populate() function.

Signed-off-by: Pranav Tipnis <pranav.tipnis@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

wic will be needing this for its bootimg-efi plugin.

[YOCTO #9556]

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Found some more syntax cleanups needed for python3.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Use APPEND for grub's root device may cause confusion, for example, when
building efi + pcbios, there maybe be two root=/dev/ram0, one of them
would be carried to the installed target, and the target would fail to
boot. Use GRUB_ROOT to fix the problem, and remove SYSLINUX_ROOT from
APPEND will fix the problem.

[YOCTO #9354]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* Make it can build vm and live (e.g., iso + vmdk) together as we did
  for syslinux.
* GRUBCFG -> GRUB_CFG as other GRUB_FOO vars

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Fixed:
- Found potential conflicted var LABELS ...
  Set LABELS to "boot install" would build out broken images when build
  vm + live together, use set_live_vm_vars() to fix the problem.

- Use ROOT and LABEL in boot-directdisk.bbclass and image-foo.bbclass,
  they are not only used by syslinux.bbclass, but also grub-efi.bbclass,
  add "SYSLINUX_" prefix would mislead users.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

when we generate hddimage and use it to prepare SD card
using scripts/contrib/mkefidisk.sh as described here

http://elinux.org/Minnowboard:MinnowMaxYoctoProject

The content of startup.nsh contains

bootx64.efi

but this file is actually not in same dir as startup.nsh
its in /EFI/BOOT so for this to work entry in startup.nsh
should be

fs0:\EFI\BOOT\bootx64.efi

Otherwise the image is D-O-A

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.

To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.

The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.

Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

To generate a same image both in live image type and boot-directdisk image type
and make boot-direct image boot directly on the rootfs partition without using
an initramfs we need to have the ability to generate several grub.cfg files.

Signed-off-by: Nicolas Guyomard <nicolas.guyomard@open.eurogiciel.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>