Once you update to an image, can you easily switch back to that partition and if so, will the next update just overwrite that other partition that you switched from?
I see the rollback but looks like this is only if things are broken during the update, is that correct? Looks like if I try to update and I reboot it does not boot to the new partition, so I can’t verify things are working on the new partition unless I commit but if I commit and reboot I can’t roll back. I am looking for a way to go back to the previous partition even if the image did install correctly on the partition and the user switched to it.
assuming your using uboot as your bootloader, on the device you can use fw-utils to change the uboot environment to switch between the active partitions from the operating system. Make sure you change both variables together and then reboot.
Do also keep in mind that there is no guarantees made by the Mender client that the “previous” partition actually contains something that will boot once you have run mender -commit.
E.g the Mender client could have started a deployment and aborted for someone reason, and then you would have something incomplete on the old partition and forcing a rollback in this case would result in a bricked device.
So you need to make sure that you always have something valid on the “old partition”, which can be done by hooking in the Mender state-machine and making sure to restore “old partition” in some chosen states.
yes, that’s an good point to remember. I should of stated in my reply, that our physical button and gpio pin code is is included in the boot-loader code to avoid ever having a bricked device caused by a mender os update.
So you can only change this via uboot menu on bootup or via physical button? I was just wondering if this was easy for a non-techie or not so sounds like the answer is no, which is fine. I have an internal website to update firmware and wanted to see if there was an easy way to switch partitions.
when you boot your device, if using uboot and is configured to allow you to enter a shell then you can usually hit the keyboard to drop into a uboot shell where there are commands to be able to manipulate all manner of things. However this is usually just for development/testing. To make permanent changes alterations one would add C code to uboot with the extra functionality you require or get uboot to load in scripts from memory. Either way its not non-techie.
Making the changes from the operating system as already mention is simple, but as @mirzak pointed out you need to be careful.
As @mirzak pointed out you better be sure the “old” partition can boot or you may have bricked your device. I wonder if there is an alternate solution available. If you set the mender_boot_part and mender_boot_part_hex and also set upgrade_available=1 doesn’t this prevent the bricking scenario? On a subsequent reboot (and failure to boot the “old” partition) shouldn’t U-boot fallback to the original partition to boot? It’s almost like doing an installation (to the “old” partition) that fails and the normal boot-count recovery mechanisms in U-Boot returns you to the original partition. I have tested this and it seems to work. Am I missing something that could be leaving Mender in an inconstistent state? I suspect if it boots successfully back into the “old” partition you’ll have to do a “mender commit” to make the change permanent and clear the “upgrade_available” flag.