Added a simple check to log a warning when an image is generated with the client
installed, and the version installed will lead to the image being unusable.
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Changelog: A bootstrap Artifact is now installed in
/data/mender/bootstrap.mender, on every conversion, adding the ability to have
the Mender client bootstrap the database without running an update first, thus
enabling delta-updates to be installed without first running a full rootfs
update. Please note that this will require a minimum of the Mender client at
version 3.4.x. However, the generated Artifact is still usable in any case.
Ticket: MEN-5594
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Ticket: ME-6
Changelog: The prebuilt Mender Grub integration now comes with the XFS module
installed by default.
Signed-off-by: Ole Petter <ole.orhagen@northern.tech>
Intuitively it might make sense to keep them in mender-image-tests,
but this has problems when trying to test updates to the file, so we
resort to duplicating it instead.
Ticket: QA-464
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
Add a unit to systemd that checks whether /data is mounted before
starting mender client.
Changelog: None
Ticket: MEN-5519
Signed-off-by: Mikael Torp-Holte <mikael.torp-holte@northern.tech>
The issue is a bit complicated. The naming still uses sdimg for
historical reasons. However, we need to put `uefiimg` in
`IMAGE_FSTYPES` because it is required for feature selection. This bug
previously prevented the test_secure_boot test from running.
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
* Needs sudo to copy files to right locations.
* Need to strip last component in target path to avoid subsequent runs
ending up with copies one level deeper than they should be.
Signed-off-by: Kristian Amlie <kristian.amlie@northern.tech>
This already broke once in our pipeline, so let's add this job
configuration so that we keep testing it.
Signed-off-by: Kristian Amlie <kristian.amlie@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>
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>