summaryrefslogtreecommitdiffstats
path: root/classes/uefi-comboapp.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* uefi-comboapp.bbclass: install files under pseudoPatrick Ohly2017-11-171-2/+2
| | | | | | | | | | | | | | | | | do_uefiapp_deploy copies files into the /boot directory of the rootfs and thus, like do_rootfs, should run under pseudo so that the files end up being owned by root. This did not trigger the uid leak check, perhaps because the task runs later. For some (still unknown reason), sometimes the installed files did end up being owned by root, which tripped up a swupd test because the system update randomly included unexpected changes to bootx64.efi or rmc.db. With this change, they are owned by root consistently. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* uefi-comboapp.bbclass: Split signing functionality into its own bbclassCalifornia Sullivan2017-07-191-34/+5
| | | | | | | | | In the future more secure boot implementations will be offered, with each one needing the signing method. Instead of repeating a forty line block of code across several recipes, just use a configurable bbclass. Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* uefi-comboapp.bbclass: support multiple UEFI combo apps + fixesPatrick Ohly2017-07-191-23/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The original code in intel-iot-refkit allows to create more than one UEFI combo app and uses that to create one for removable media and one for fixed media (after installation), with different boot=PARTUUID=xxx parameters. This way, an installed image never ended up booting from the install media. uefi-comboapp.bbclass now supports the same feature, with create_uefiapp() as the API function that can be used to create additional UEFI apps and create_uefiapps as the method where the call can be added. In addition, several shortcomings are getting addressed: - A UEFI combo app must be stored under a name that is specific to the image for which it gets created, otherwise different image recipes end up overwriting (or using) files from other images. - Signing must be done after creating the apps and before deploying them, otherwise the unsigned apps get copied to the image when using do_uefiapp_deploy. - The common code for deployment is now in uefiapp_deploy_at. - $dest is used instead of ${DEST} because the latter might get expanded by bitbake. - Because do_uefiapp always had to run anew to produce the clean, unsigned input for do_uefiapp_sign, having two different tasks just added unnecessary complexity. Now all code is in do_uefiapp. - Old files matching the output pattern get removed explicitly, because they might not get overwritten when the optional app suffix changes between builds, or when the task fails in the middle. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>
* classes: Add uefi-comboapp bbclassCalifornia Sullivan2017-07-101-0/+155
This bbclass pulls in the portion of code that builds a UEFI combo application from meta-refkit to meta-intel. The combo app contains an EFI stub from systemd, which allows you to boot a kernel directly, a kernel, an initramfs, and a command line. This class is compatible as either an EFI_PROVIDER or IMAGE_CLASSES target, and does not include the entire _dsk type image creation seen in meta-refkit. Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com>