| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
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>
|