In the first step, you are modifying a file from the current running partition A. At step 5, you had to specify to boot from partition B, so the modifications to the kernel shouldn’t affect the booting process to the inactive partition so far.
I am curious on what kind of system you are testing right now. Is this an integration you are performing or are you following a tutorial in particular?
Usually the values are 2 and 3 for A and B. As the 1st one is assigned to the bootloader and the 4th one for the /data partition for persistent information. How is your system partitioned?
If your system is partitioned differently as I explained, if this is a Yocto based system,
please make sure to override these variables so it will use the right ones:
If this is a Debian-based system, override the partition numbers as described here.
# Partition number of boot partition
MENDER_BOOT_PART_NUMBER="1"
# Partition number of root filesystem A
MENDER_ROOTFS_PART_A_NUMBER="2"
# Partition number of root filesystem B
MENDER_ROOTFS_PART_B_NUMBER="3"
# Partition number of persistent data partition
MENDER_DATA_PART_NUMBER="4"
If you are using the default partitioning configuration, and you are currently in partition A, you are telling the bootloader to keep in the current partition with the command you shared.
Could you please confirm? The system can boot without the mender boot but it just can’t go to the next rootfs as per the instruction in the integration checklist.
I am happy to put back the mender boot if it is indeed necessary.
Mmmm, you can say that all of these variables are “optional” in the sense that they have a default value. See these lines for the boot partition, and just below for the rest. But AFAIK the boot partition must be always present in the system.
So what you are doing with your configuration is incorrect, as both MENDER_BOOT_PART and MENDER_ROOTFS_PART_A are pointing to the same partition.
Now, I would expect meta-mender logic to catch this and trow an error… I’ll follow it up independently.
I might be wrong: it seems that a setup with no boot partition is valid, see these lines.
Although I don’t know in which circumstances a system does not need the boot partition what is clear from the code is that you need to set MENDER_BOOT_PART to empty string, rather than not setting it (which will trigger the default logic I pointed in my previous comment), for this piece of logic to trigger.
I think the reason why booting is not working because fw_printenv does not have any mender variables. The result of printenv and fw_printenv are totally different. How can I make them the same?
This is content of my target:
root@hero-secc:/# ls
bin data etc lib media opt run sys unit_tests var
boot dev home lost+found mnt proc sbin tmp usr www
You need to make sure that /etc/fw_env.config contains these lines:
DEVICE OFFSET1 SIZE
DEVICE OFFSET2 SIZE
where the DEVICE is the same as the one expected by U-Boot. This is defined in U-Boot’s C code defines, CONFIG_SYS_MMC_ENV_DEV and CONFIG_SYS_MMC_ENV_DEV (very often mmc and 0, respectively, which corresponds to DEVICE = /dev/mmcblk0).
OFFSET1, OFFSET2 and SIZE should match U-Boot’s C code defines CONFIG_ENV_OFFSET, CONFIG_ENV_OFFSET_REDUND and CONFIG_ENV_SIZE, respectively.
The meta-mender layer code tries to check that these variables are correct, but may miss some cases.
Also, make sure that U-Boot has been flashed correctly to your board, and you’re not still using the old version from before you attempted the Mender port.