You are browsing documentation for a version other than the latest stable release. Switch to the latest stable release, 1.7.
In order to ensure that the necessary components for Mender have been integrated correctly, use this checklist to verify each of them in turn. Use this when all components have been built successfully, and the device has booted correctly.
This checklist applies only if you are using U-Boot. If you are using another bootloader, such as GRUB, this section can be skipped.
This checklist will verify some key functionality aspects of the Mender integration. It will verify that:
Steps 1-4 can be skipped when verifying raw flash integration.
As part of the test, we will need two different Linux kernels, in order to verify that both are booted correctly when they should. Therefore, before building the images you will test with, run the commands:
bitbake -c clean linux-yocto
bitbake -c cleansstate linux-yocto
Note that linux-yocto
may need to be switched with the particular kernel being used with your device.
Then build the image normally.
Copy the resulting .sdimg
file to a safe location, for example base-image.sdimg
and then repeat step 1.
Run the following commands:
sudo losetup /dev/loop0 base-image.sdimg
sudo kpartx -a /dev/loop0
sudo dd if=tmp/deploy/images/<machine>/<image>.ext4 of=/dev/mapper/loop0p3
sync
sudo kpartx -d /dev/loop0
sudo losetup -d /dev/loop0
The last number in loop0p3
should correspond to the partition number of the second rootfs partition, and may need to be adjusted if MENDER_ROOTFS_PART_B
has been changed.
The kpartx
tool may require installation before it can be used.
Some Linux distributions may try to auto-mount the devices that kpartx
maps. If so you need to unmount them again manually before calling kpartx -d
.
The reason for doing this manual image patching is to have two kernels in the image with differing build dates, which will be useful for verification later.
Flash the base-image.sdimg
image to the device and boot it.
Verify that the two commands fw_printenv
and fw_setenv
are in the path and are executable. Calling them with no arguments will should give a variable listing and an error about missing variable name, respectively. This verifies that u-boot-fw-utils tools are present on the device.
Now we will test that storing and reading values in the U-Boot environment works. Run:
fw_setenv mender_linux_test 1
Reboot, and interrupt U-Boot so you get the U-Boot prompt.
Run:
printenv mender_linux_test
The output should be:
mender_linux_test=1
in other words the same value that was set earlier.
While still at the U-Boot prompt, run:
setenv mender_uboot_test 1
saveenv
run bootcmd
You should be back inside Linux now, so run:
fw_printenv mender_uboot_test
The output should be:
mender_uboot_test=1
in other words the same value that was set earlier. This verifies that U-Boot the bootloader, and u-boot-fw-utils agree on format for the U-Boot environment.
Now we will verify that Mender is running. Run the following:
pidof mender
If Mender has been enabled as a daemon, either through inheriting mender-full
or enabling the mender-systemd
feature in MENDER_FEATURES_ENABLE
, it should return a PID. If not, it should return nothing. This verifies that Mender is started as a service if applicable.
Now we verify that the booted kernel is from the rootfs. The easiest way to check this is to check the build date, which can be seen by running:
cat /proc/version
Make sure it matches the build date and time of the first kernel you just built, and not an older one. Make a note of this time, as you will need it later. This verifies that the correct kernel is loaded from partition A.
Now we will look at which rootfs is mounted. Run mount
with no arguments. The file system mounted as root (signified by the <device> on /
entry) should be:
/dev/mmcblk0p2
when using SD card or eMMC storage.ubi0_0
when using raw flash storage.If the device listed is an ambiguous device, such as /dev/root
, you can use an alternative method for verifying it. If you call the following series of commands:
stat -c %D /
stat -c %t%02T /dev/mmcblk0p2
The output of the two commands should be identical. This verifies that the correct rootfs is mounted when partition A is active.
If you have selected a different device using either MENDER_ROOTFS_PART_A
or MENDER_STORAGE_DEVICE_BASE
in the Yocto configuration, the /dev/mmcblk0p2
(or ubi0_0
) entry may be different, but it should always correspond to the value in MENDER_ROOTFS_PART_A
.
Everything we have tested so far has been for partition A; we will now verify both kernel and rootfs for partition B. Run the following:
When using SD card or eMMC storage:
fw_setenv mender_boot_part 3
fw_setenv mender_boot_part_hex 3
fw_setenv mender_boot_part 1
fw_setenv mender_boot_part_hex 1
The number is the number of the second rootfs partition, and corresponds to the last component of the MENDER_ROOTFS_PART_B
variable. If you've changed this variable in the Yocto configuration, you may need to use a different number.
Reboot.
Repeat step 12, but this time verify that the build date is later than the first time you did this step. This is because we replaced the kernel of the second rootfs partition with a newer one. This verifies that the correct kernel is loaded from partition B.
In the case of raw flash storage, the second rootfs was not updated, hence the build time listed in /proc/version
will be the same as for the first partition.
Repeat step 13, but this time using /dev/mmcblk0p3
(or ubi0_1
). This verifies that the correct rootfs is mounted when partition B is active.
As in the previous step, /dev/mmcblk0p3
(or ubi0_1
) may be different if MENDER_ROOTFS_PART_B
or MENDER_STORAGE_DEVICE_BASE
has been changed.
Run the following commands:
When using SD card or eMMC storage:
fw_setenv mender_boot_part 2
fw_setenv mender_boot_part_hex 2
fw_setenv mender_boot_part 0
fw_setenv mender_boot_part_hex 0
Once the commands above have been run, we need to tell Mender that there is an upgrade available:
fw_setenv upgrade_available 1
fw_setenv bootcount 0
The mender_boot_part
number is the number of the first rootfs partition, and corresponds to the last component of the MENDER_ROOTFS_PART_A
variable. If you've changed this variable in the Yocto configuration, you may need to use a different number.
Reboot, but pull the power plug before the system has had time to finish booting. Mender will auto-commit the update if it is enabled as a service, which will defeat the purpose of this test, so it's important that the power is cut after the kernel has started booting, but before Mender has started.
/dev/mmcblk0p3
(or ub0_1
). The detected device should not be /dev/mmcblk0p2
(ubi0_0
), this indicates that the rollback has not worked. Otherwise this verifies that rollback, indeed, has worked.That's it! You have now verified compatibility with Mender!