Changelog: Fix grub.d integration when host and target 32/64 bit
architectures don't match. Namely: pass the correct `--target` parameter
to `grub-install` command instead of relaying on host architecture.
Ticket: MEN-5979
Signed-off-by: Lluis Campos <lluis.campos@northern.tech>
This means that `grub-install` and `update-grub` no longer risk
bricking the device, but will produce boot scripts with Mender support
integrated. It also means that the standard GRUB menu will be
available.
It is supported on x86_64 platforms where `grub.d` is available, and
can be turned on and off with `MENDER_GRUB_D_INTEGRATION`. The default
is to use it if available.
Devices that did not previously use `grub.d` integration won't be
upgraded correctly with it turned on, so it is advised to set
`MENDER_GRUB_D_INTEGRATION=n` if you are upgrading existing devices.
Changelog: Commit
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
The presence of the shim depends on whether Secure Boot is enabled or
not, plus the configuration of the distro. GRUB itself however, will
always be present if the distro uses GRUB with UEFI at all. So check
for that instead.
Of course, without the shim, Secure Boot will not work out of the box,
but this is a misconfigured platform, not a problem with Mender.
Cancel-Changelog: 2b805e29dc
Changelog: If `grub*.efi` preexists on the EFI partition, keep it
instead of installing our own. In all other cases, we fall back to the
old functionality of installing mender-grub and nuking the existing
bootloader.
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
In the case a boot shim is found on the boot partition, we do keep the boot
partition pristine, and only install the generated mender `grub.cfg` file we need.
In all other cases, we fall back to the old functionality of installing
mender-grub and nuking the existing bootloader.
Changelog: commit
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Lluis Campos
Ole Petter
Kristian Amlie