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>
Note that we will still use EFI, since Mender doesn't support anything
else, but we will avoid grub.d integration since it won't be prepared
for it in this configuration. Instead the legacy method with a custom
Mender boot script will be used.
Inspired by this thread on Mender Hub:
https://hub.mender.io/t/problems-converting-a-packer-debian11-img-with-mender-convert/5054
Changelog: Title
Ticket: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
When introducing grub.d integration, we switched to using the already-
installed grub binary if it existed. But this is not a good idea,
because it may come with hardcoded paths which may fail to load the
script that we put in `/EFI/BOOT`. So revert to the old behavior,
install our own pre-compiled grub binary if grub.d integration is off.
No changelog, since we never released this regression.
Changelog: None
Ticket: None
Signed-off-by: Kristian Amlie <kristian.amlie@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>
Changelog: Download and install Debian packages taking into account the
target OS. Now downloads.mender.io serves four distributions: the two
latests releases for Debian and Ubuntu. Probe /etc/os-release to figure
out the correct package to install, and fallback to Debian Buster
packages which was the previous default.
Signed-off-by: Lluis Campos <lluis.campos@northern.tech>
Originally the intention was to fix the U-Boot integration for
Beaglebone, but this seems to have been broken for a long time, almost
a year, and no one has complained about it. The problem appears to be
connected to this commit [1], but it's not entirely clear to me what
the fix should be, and there are a lot of patches for our U-Boot fork.
However, since the U-Boot integration is supposed to be the backup
solution, rather than dig into U-Boot I decided to just fix the UEFI
path instead. This method doesn't require any patching, but there is
a problem with the specific image which is available for download at
the time of writing. So just grab the boot loader and kernel pieces
from a later, yet unbuilt, image, and it all works again.
Changelog: Title
Changelog: beaglebone: Remove U-Boot integration, which has not worked
for a long time. U-Boot will still be used for booting, but GRUB will
be used for integration with Mender, by chainloading via UEFI.
[1] e88d5dbf01
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Previously there was a mix between two, and four spaces.
This commits unifies all scripts to use two-spaces for indentation.
Changelog: None
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Minor spelling errors in user facing messages
Changelog: None
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Spell fixes
The userfacing logging had a couple of spelling errors
Changelog: None
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
The goals of the re-write was to achieve the following:
1. It should be easy to extend the tool to support other boards or distributions
2. We should not compile code in the tool (rely on binaries built elsewhere)
compiling code increases complexity, due to requirement of toolchains etc.
3. The tool shall not be designed around specific hardware/platform types
- This is the case today with the usage of --device-type flag
4 The tool should be to convert images without knowing anything about the hardware/platform
relates to above 3.
5. Configuration interface should be simplified
- command line flags -> configuration files
6. Platform specific code shall be provided trough “hooks”, and are not part of the “core” mender-convert code
7. It shall be easy to extend functionality
- support for rootfs overlay to inject user applications/configurations
- ability to override how the Mender Artifact is generated (to be able to sign and include state-scripts)
8. Code structure should be modular
- Eases Maintenance and possibility of making isolated changes
Changelog: Title
Signed-off-by: Mirza Krak <mirza.krak@northern.tech>
Lluis Campos
Kristian Amlie
Ole Petter
Dell Green
Drew Moseley
Sylvain
Mirza Krak