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>
Because the shim has hardcoded paths for each distribution, it is
better to use the `grub-install --removable` argument to install into
`/EFI/BOOT` than to do it ourselves. This makes sure that all files
are present and loaded from correct locations.
The symptom before this change was that the shim could not find the
grubx64.efi file, which is because we were not installing it
correctly. So in fact the image would not boot, even though it would
boot after a Mender conversion.
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
This fixes a boot problem which was introduced in the standalone grub
boot scripts, during the grub.d integration work.
Changelog: None
Ticket: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
This is to make sure we do not accidentally re-publish already
existing tags. They can still be published manually by using the
manual publish job, if necessary.
Changelog: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
This is using pre-signed binaries by Microsoft, Canonical and Debian,
no customized signing.
Changelog: 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>
* Standardize on "qemux86-64", not "qemux86_64", since the former is
what is used everywhere else.
* Rename qemux86_64 to ubuntu-qemux86-64, since we now have more than
one qemu configuration.
Changelog: None
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Changelog: The mender-convert docker image does now contain the mender-convert application and does no longer need companion checkouts.
Changelog: All input files passed to docker-mender-convert must be located within the input directory as opposed to anywhere in the mender-convert checkout directory
Signed-off-by: Simon Ensslen <simon.ensslen@griesser.ch>
Changelog: title
The configuration files are only meant to work on
specific combinations of board+OS. These are added
verbatim in order to avoid confusion.
Signed-off-by: Josef Holzmayr <josef.holzmayr@northern.tech>
Kristian Amlie
Kristian Amlie
oleorhagen
Mikael Torp-Holte
Lluis Campos
dependabot[bot]
mender-test-bot
Simon Ensslen
Josef Holzmayr