Hi,
I am trying to use mender in standalone mode. Till now , i am able to manually patch the uboot fork which i am using. Able to make the uboot-fw-utils. Finally i am just looking for genrating the .mender artifact, but in that process when i do bitbake , i get below error.
The rootfs size 2097152(K) overrides IMAGE_ROOTFS_MAXSIZE: 425984(K)
Did i miss something to set, however i am not setting any mender partitions or sizes.
Hi,
It seems that the generated rootfs image is a lot bigger then the default rootfs partition.
You can adjust this with the MENDER_STORAGE_TOTAL_SIZE_MB variable.
And you can read more about it here,
https://docs.mender.io/2.0/devices/yocto-project/partition-configuration
Thanks, the image got built and i got the .mender artifact as well. I have my own partitioned image where partitions are like:
/dev/mmcblk1boot0 for uboot.imx
/dev/mmcblk1p1 for Primary rootfs
/dev/mmcblk1p2 for Secondary rootfs
/dev/mmcblk1p3 for App Data.
I am not able to give the same partition layout as part of Mender variables or do i even need to? I did change as below in my machine.conf
MENDER_STORAGE_TOTAL_SIZE_MB = “2048”
MENDER_STORAGE_DEVICE = “/dev/mmcblk1”
MENDER_STORAGE_DEVICE_BASE = “{MENDER_STORAGE_DEVICE}"
MENDER_BOOT_PART = "{MENDER_STORAGE_DEVICE_BASE}boot0”
MENDER_ROOTFS_PART_A = “{MENDER_STORAGE_DEVICE_BASE}p1"
MENDER_ROOTFS_PART_B = "{MENDER_STORAGE_DEVICE_BASE}p2”
MENDER_DATA_PART = “${MENDER_STORAGE_DEVICE_BASE}p3”
When i build the image now, i get below error
ERROR: u-boot-imx-2017.03-r0 do_provide_mender_defines: Function failed: do_provide_mender_defines
My config_mender_defines.h file looks like below:
#define MENDER_BOOT_PART_NUMBER 1
#define MENDER_BOOT_PART_NUMBER_HEX 1
#define MENDER_ROOTFS_PART_A_NUMBER 2
#define MENDER_ROOTFS_PART_A_NUMBER_HEX 2
#define MENDER_ROOTFS_PART_B_NUMBER 3
#define MENDER_ROOTFS_PART_B_NUMBER_HEX 3
#define MENDER_UBOOT_STORAGE_INTERFACE “mmc”
#define MENDER_UBOOT_STORAGE_DEVICE 0
/* BB variables. */
#define MENDER_STORAGE_DEVICE_BASE “/dev/mmcblk0p”
#define MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 0x800000
#define MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 0x1000000
#define MENDER_ROOTFS_PART_A_NAME “/dev/mmcblk0p2”
#define MENDER_ROOTFS_PART_B_NAME “/dev/mmcblk0p3”
#define MENDER_MTD_UBI_DEVICE_NAME “”
Any pointer will be helpful.
This case is not supported by sdimg and you would need flash this as a separate step. So I would just emit this part from the build process.
I have my own partitioned image where partitions are like
If you have your own custom image type that is already partition in the why it would be required for Mender, you can disable the sdimg and use your own image.
In this case all you would need to configure is the following to get the correct values in U-boot and /etc/mender/mender.conf.
MENDER_STORAGE_DEVICE = “/dev/mmcblk1”
ERROR: u-boot-imx-2017.03-r0 do_provide_mender_defines: Function failed: do_provide_mender_defines
Can you share the full error log for above error?
Yes true i am not going to use .sdimg as i have my custom image and the way to flash it. I am just trying to create .mender artifact which knows the exact primary, secondary and app/data partition. Seems i can only set the
MENDER_STORAGE_DEVICE = “/dev/mmcblk1”
MENDER_STORAGE_DEVICE_BASE = “{MENDER_STORAGE_DEVICE}p" MENDER_ROOTFS_PART_A = “{MENDER_STORAGE_DEVICE_BASE}1" MENDER_ROOTFS_PART_B = "{MENDER_STORAGE_DEVICE_BASE}2”
MENDER_DATA_PART = “${MENDER_STORAGE_DEVICE_BASE}3”
and just do away with the mender related boot partition configuration. Is this understanding correct? I am building another image without the MENDER_BOOT_PART conf and checking if it works fine.
<-------------------------After some time ---------------->
This is how after a successful build the mender.conf looks like:
{
“InventoryPollIntervalSeconds”: 1800,
“RetryPollIntervalSeconds”: 300,
“RootfsPartA”: “/dev/mmcblk1p1”,
“RootfsPartB”: “/dev/mmcblk1p2”,
“ServerURL”: “https://docker.mender.io”,
“TenantToken”: “dummy”,
“UpdatePollIntervalSeconds”: 1800
}
I am having the same partitions as in my custom image, so it looks ok. I am hoping it is going to allocate size as per the max storage size i have given to whole device = 2048 (2GB). Also since i am going to use mender in standalone mode, the above parameters:
“ServerURL”: “https://docker.mender.io”,
“TenantToken”: “dummy”,
“UpdatePollIntervalSeconds”: 1800
Are they going to play or disturb anything. I think they all came as i did a
INHERIT += “mender-full”
I am going to use this artifact and check if it installs well on my board.
I have never tried this so I cannot comment on whether the above is completely correct or not, but at first glance it looks ok. Please let us know if it works.
I am able to setup everything on my imx6ull custom board and things are working fine with my custom partitions. I am able to do an update locally from file system. I just have one query, if somehow the mender artifact is corrupt, how does the rollback happens. Is it automatically taken care of or we have to do something manually like i am scripting to commit the update on the reboot. Any pointers?
It depends on the nature of the corruption. And also whether you are doing full partition updates or something with an update module. I’ll assume based on the previous discussion that it is full partition.
If the corruption is such that the artifact install fails, then it will never be used by the system.
If the artifact install succeeds, then the reboot is conditional. Any subsequent reboot before the commit will cause the logic in the bootloader to automatically switch back to the old system. If the failed install allows your scripting to run and detect the situation then you can simply issue a reboot command in your script. If the system cannot run your scripts (say due to a kernel oops) then other mechanisms such as watchdog timers will be needed to force a reboot but the logic in the bootloader will still detect this since the commit has not happened.
Hope that clears it up.
Drew
Thanks for such a nice explanation. Yes i am doing a full image update. My script is working as you explained. I did test with corrupt, incomplete mender artifact and even tested the rollback. Only thing which i haven’t covered is let say the kernel has panicked, i need to have the hardware watchdog timer. That part i have to check and add for imx6ull board.
@mirzak: Just confirming as suggested by @drewmoseley, if we have intentionally rebooted our board after mender update is complete and on this reboot we loose power just before mender commit, which i do from a userspace script. There is no update to commit and the bootloader switches to old image (old partition). Can this be avoided. This can always happen, if we loose power at the time of intentional reboot after mender update. I am using mender in standalone mode with delivery of mender artifact from my cloud server. Please help!
Hi @CoderOnWinks, I’m not sure how this can be avoided as this is exactly the way Mender was designed. The “commit” is the very last stage of the update intended to run after all your custom post-install steps. Any reboot prior to that is considered a rollback since Mender does not necessarily know the specifics of why the system rebooted.
@drewmoseley: I did a reboot after the mender install command, and then on coming from that reboot, I do mender commit. I don’t know if the reboot after mender install was really needed, or can I simply do a mender commit and then reboot the system. If i do a mender commit just after mender install, will the system come with new image/partition then? I designed my approach thinking that after mender install, we should first reboot to see, that everything is coming up properly and then commit that update from a user space script. What if there is a bad kernel image and we have installed and already committed, in this case there will not be any rollback and it will lead to bricking the device. Thoughts?
As to your last point, so as not to depend solely on software, the way we have tackled it in our products is to add a small physical button on the back of our devices connected to gpio. Then in uboot we have added code to toggle between A/B partitions If button is held down during startup
@dellgreen: This you have put to unbrick a box/device in field. Right. So when service engineer will go and debug they can use this feature. I do not expect customers to know this.
yes, our customers do it, its no different to some consumer devices like home routers etc, which have a hard button (or insert paperclip here) on the back of them to reset to defaults.
Your approach is the way it is supposed to work. When a new update is installed, the system reboots and runs in the new image conditionally one time. The very last step of the update process is the commit which will lock that new image in. If the system is rebooted for any reason before that commit happens, then the logic in the bootloader will detect it and rollback.
If the system is sane enough for Mender to run and detect the issue (either Mender cannot connect to the server or a postinstall check that you added fails), then Mender will reboot and skip the commit.
If the system is not sane enough for Mender to run (ie a kernel oops or some such) then the commit still will not have happened so any subsequent reboot will trigger a rollback. This is a common use case for a watchdog timer for instance.
Regarding a switch to manually change partitions, you have to be a bit careful with that in case the inactive partition is invalid. ie You may have had a deployment started but aborted for some reason, in which case the contents of that partition are undefined.
Drew
Regarding a switch to manually change partitions, you have to be a bit careful with that in case the inactive partition is invalid. ie You may have had a deployment started but aborted for some reason, in which case the contents of that partition are undefined.
Do you have more detail on this, as we spent a lot of time proving in our setup this couldn’t happen as you should be able to toggle to at least one working partition with networking. If you were able to install a broken image in the first place you have networking working in that partition which means you can switch back to it and do another follow-up update with the fix. And equally if you don’t have networking in the broken partition you cannot then brick the previous working partition.
There is no guarantee that the inactive partition will be valid. If you try to boot into and have issues the previously active partition is likely still valid so you can just switch back unless a very odd set of circumstances allows the inactive partition to boot and start a deployment but still not be valid.
Drew
Ah I see what you are saying, and yes your correct, a hardware button gives the customer the immediate ability to choose to switch to a previous state if for any reason they deem the previous update unsatisfactory without having to wait for a follow-up update to fix whatever problem they found and reported. If the previous state is damaged for any reason then they can also choose to toggle back and wait for a follow up update.
I think the key takeaway is that the customer has a choice. 
@drewmoseley: Is it possible for me to run a script in kernel to do a mender commit, considering I want it at the very first level or can I do it at u-boot level? Right now I have to live with a subsequent reboot which is not letting me do the mender commit. I want to do that in kernel or u-boot, is it feasible?