We are using an IMX6UL with a Nand-flash directly attached to the SoC. Our vendor has done the footwork to use barebox as bootloader - hence we use it. We are using RAUC to do dual-system updates today. The partitioning of the NAND and related information/configuration (ubi + ubifs-volumes) is done with barebox scripts centralized in our own BSP-layer where.
Right now, we are studying whether Mender is suitable for our system or not.
To do this, we ideally replace RAUC with Mender on the system plus adding the barebox-bootchooser-scripts (barebox’s framework to switch systems) as described by Trent @tpiepho on other threads on the hub.
When starting to integrate meta-mender in our build, I’m stumbling directly on setting MTDIDS-variable and MTDPARTS. I imagine these are necessary to integrated with a full solution using U-Boot and creating everything from nothing via mender.
Is there are a way to simply have mender generate artifacts which are representing the rootfs (image-type ubifs) and use the client on the system to upgrade? How to have mender ignore the bootloader?
2 Likes
Hi @pboettch!
Please have a look at the features section in our docs,
https://docs.mender.io/2.3/artifacts/yocto-project/image-configuration/features
I think what you are looking for is to disable mender-uboot, because you are not using U-Boot 
.
Based on your description you probably want to disable the following:
MENDER_FEATURES_DISABLE_append = " mender-uboot mender-grub mender-bios mender-image-ubi"
As you probably are using:
INHERIT += "mender-full-ubi"
It can be simplified to:
MENDER_FEATURES_DISABLE_append = " mender-uboot mender-image-ubi"
Adding the MENDER_FEATURES_DISABLE_append line of yours still makes it moan about MENDER_MTDIDS must be defined.
Adding MENDER_MTDIDS="foo" calms it down but there are warnings:
There as still some warnings (I’m using the zeus-next-branch):
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDIDS (asd).
WARNING: Unknown MTDID type , setting UBI block overhead to 0
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDIDS (asd).
WARNING: Unknown MTDID type , setting UBI overhead to 0
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDPARTS (). Returning UBI size of zero.
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDIDS (asd).
WARNING: Unknown MTDID type , setting UBI block overhead to 0
WARNING: Could not find MENDER_IS_ON_MTDID () in MENDER_MTDIDS (asd).
WARNING: Unknown MTDID type , setting UBI overhead to 0
Well, I don’t get it, sorry.
How can I tell mender-core to just create an artifact out of the rootfs-ubifs-file the image-recipe produces? I have the feeling this is what I want. Without telling mender the partitioning of my storage-device?
I realize that there is also a config-file to be generated but is there no other way that to give mender the full picture?
The intention of the following:
MENDER_FEATURES_DISABLE_append = " mender-uboot mender-image-ubi"
should be
How can I tell mender-core to just create an artifact out of the rootfs-ubifs-file the image-recipe produces
With that said, it does not mean that it is perfect and there might be assumptions made that you are building a full image even if you are specifying above. If you come across things like this, we would love to see this being resolved and fixed upstream. I do not know if anyone has tried this path before, so hiccups are expected.
One example is that it is enforced that MENDER_MTDIDS is defined, even if you only want to build a ubifs image and not an ubi image. This is because the MENDER_MTDIDS variable is parsed to get the size of the ubifs image, MENDER_MTDIDS is parsed to get a lot of other information. But this can probably be disabled as well.
If you take a look at mender-setup-ubi.inc, you should get a better idea of what is going on.
So you have two additional options moving forward:
-
Define MENDER_MTDIDS to represent what you have on the device. Information in this variable will be used to create a correct ubifs image and it will not create an ubi image since the latter was disabled.
-
Provide all values manually, these (probably not all):
https://github.com/mendersoftware/meta-mender/blob/zeus-next/meta-mender-core/classes/mender-setup-ubi.inc#L120-L151
Actually there is a third option which would be very minimal. Remove everything you have Mender related so far and only add:
ARTIFACTIMG_FSTYPE = "ubifs"
IMAGE_CLASSES += "mender-artifactimg"
But above would not even install the Mender client, it will just build the Mender Artifact (.mender) file. Though never tested this and would be interesting to see if you get other problems.
Thanks for getting back.
My rootfs partitions are created with ubimkvol and are of type dynamic.
Couldn’t mender just use the generated .ubifs-file and incorporate it in the artifact and then use ubiupdatevol not caring about the size (and the error blocks) of the partition.
Your third option sounds interesting. I actually like minimal approaches; helps a lot to understand how things work.
For the mender-client, I assume it is as simple as adding mender-client to IMAGE_INSTALL?
Here is what I added to my image recipe to have it generate an artifact:
inherit mender-artifactimg
MENDER_ARTIFACT_NAME = "release-1"
ARTIFACTIMG_FSTYPE ='ubifs'
IMAGE_FSTYPES += 'mender'
Now I’m investigating how to elegantly create a config-file.
1 Like