# How to configure the mender to use dm-crypt partitions for rootfs? **URL:** \ **Category:** General Discussions\ **Tags:** yocto, sumo, nxp, standalone\ **Created:** [February 6, 2020, 11:22am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508 "2020-02-06T11:22:29Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 6, 2020, 11:22am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/1 "2020-02-06T11:22:30Z")
Hello everyone, We are using the mender 2.0 in standalone mode. Currently, the system is working fine and can able to update the artifacts (A/B block update). However, as part of security enablement, we need to make the rootfs as encrypted with [dm-encypt](https://en.wikipedia.org/wiki/Dm-crypt). This means that the mender can not access the physical partitions directly as “`/dev/mmcblk0p1`” and need to use the virtual layer partition for the update. Has anyone used or know how to configure the mender to use these virtual partitions for the A/B rootfs update? Whether changing the “`MENDER_STORAGE_DEVICE`” to the virtual name is enough for the mender to take the virtual partitions or do I need to configure anything else? ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 8, 2020, 5:19am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/2 "2020-02-08T05:19:52Z")
@mirzak @eystein @drewmoseley @kacf @lluiscampos Any thoughts on this? Whether mender supports any device name or only known devices? I have tried to modify the `MENDER_STORAGE_DEVICE` from “/dev/mmcblk0” to “/dev/dm-” and also tried to change `MENDER_STORAGE_DEVICE_BASE` from “/dev/mmcblk0p” to “/dev/dm-”. ``` Both give Yocto build error as follows: ERROR: u-boot-imx-2018.03-r0 do_provide_mender_defines: Function failed: do_provide_mender_defines (log file is located at /2018.03-r0/temp/log.do_provide_mender_defines.6108) ERROR: Logfile of failure stored in: /2018.03-r0/temp/log.do_provide_mender_defines.6108 Log data follows: | DEBUG: Executing shell function do_provide_mender_defines | + echo u-boot-imx | + fgrep mender-auto-provided | + true | + expr 16777216 % ( 8388608 * 2 ) | + [0 -ne 0] | + [16777216 -gt 16777216] | + [-n /dev/dm-1] | + get_part_number_from_device /dev/dm-1 | + dev_base=unknown | + printf %d unknown | + part=0 | + MENDER_BOOT_PART_NUMBER= | + bb_exit_handler | + ret=1 | + echo WARNING: exit code 1 from a shell command. | WARNING: exit code 1 from a shell command. | + exit 1 | ERROR: Function failed: do_provide_mender_defines (log file is located at /2018.03-r0/temp/log.do_provide_mender_defines.6108) ERROR: Task (/u-boot-imx_2018.03.bb:do_provide_mender_defines) failed with exit code '1' ``` Please note that the dm-crypt will change the partitions as /dev/dm-1 , /dev/dm-3 etc. ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 8, 2020, 6:54am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/3 "2020-02-08T06:54:18Z")
I have seen the following thread and mine is similar set-up (not exactly the same). > [@Mender for updating encrypted filesystem](https://hub.mender.io/t/mender-for-updating-encrypted-filesystem/475): > > Hello, I am currently working on an embedded IOT product and using mender for over the air software update. I am using the mender for the past 2 years for another product and it’s working perfectly fine. The roll outs to devices are smooth after every software update. As part of security concept for the new product, my security engineer advises to have encrypted filesystem(most likely with LUKS and dm-crypt). May I know whether mender supports such encrypted file systems. The root filesystem i… I understood that the kernel images need to be outside for this and can not update the kernel images as part of the rootfs update. My worry is how the mender OTA update on rootfs works without specifying the physical block. If mender accesses the physical block (/dev/mmcblk0p1) and delete the partition, then the system will not mount it because encryption voids in this case. The physical partition is hidden always with dm-cyrpt and we can use the virtual physical partitions (/dev/dm-1 instead of /dev/mmcblk0p1) for the update. However, specifying this /dev/dm-1 not passing the build. It looks like the mender 2.0 's “`meta-mender-core/classes/mender-helpers.bbclass`” only define “`/dev/mmcblk*p*`” or “`/dev/mmcblk*`” for the U-boot. ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [February 8, 2020, 7:29am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/4 "2020-02-08T07:29:54Z")
as you have pointed out **get\_part\_number\_from\_device()** in [https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/classes/mender-helpers.bbclass](https://github.com/mendersoftware/meta-mender/blob/master/meta-mender-core/classes/mender-helpers.bbclass) does not have a case for encrypted partitions names. The guys would probably welcome a pull request which contains an additionally case for dmcrypt named devices, could be very simple to add. Its not clear to me why manipulating the names of MENDER\_STORAGE\_DEVICE\_BASE and MENDER\_ROOTFS\_PART\_A and MENDER\_ROOTFS\_PART\_B would not be enough and carries the following caveat. “Note that the Mender image builder will not produce such images, so only set these variables if you’re building partitioned images yourself, with a different layout than the default Mender layout (the example above reflects the default).” Although thinking about it aren’t you going to need to create your own sdimg image recipe anyway to create a factory image with encrypted partitions? Albeit as you have pointed out there are probably more hurdles to overcome after you have the storage device correctly added. ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 8, 2020, 8:08am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/5 "2020-02-08T08:08:02Z")
Thank you for the reply @dellgreen. I’m using eMMC storage and the partition layout is different than the default mender layout (even for without encrypting case of mine). Could you please let me know if I put the MENDER\_STORAGE\_DEVICE\_BASE and MENDER\_ROOTFS\_PART\_A and MENDER\_ROOTFS\_PART\_B as actual physical partitions (/dev/mmcblk0p1), will it completely erase the physical partition while streaming the update? In this case, I have to put the upper virtual layer partition created by dm-crypt (/dev/dm-1) for mender rootfs partitions. Removing only the “/dev/dm-1” level and update the rootfs will not break the dm-crypt functionalities. ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [February 8, 2020, 8:40am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/6 "2020-02-08T08:40:05Z")
To be honest, I’m not sure, I was under the impression that mender did streaming of block writes of the artifact to the non-active block device, so as long as the references to the mender block devices in uboot and the mender client config point to the /dev/dm-\* block devices i would expect it to work as this block devices should of been decrypted by the kernel when you pass the necessary crypt parameters to the kernel from the bootloader. This is not something I have done, so expect a level of trial and error and probably bbappend files for some recipes. ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 8, 2020, 9:18am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/7 "2020-02-08T09:18:34Z")
@dellgreen, a quick question. My understanding is that changing `MENDER_STORAGE_DEVICE`, `MENDER_STORAGE_DEVICE_BASE`, `MENDER_ROOTFS_PART_A`, and `MENDER_ROOTFS_PART_B` will finally change the U-boot arguments. These configurations do not have any mender client source dependencies or implications. Please correct me if I’m wrong. In this case, whether changing the U-boot arguments directly (instead of Yocto) using a patch will help? Yocto changes look like not going smooth and getting multiple errors, hence asked 🙂 ---
**Author:** ![dellgreen](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/dellgreen/32/85_2.png) [@dellgreen](https://hub.mender.io/u/dellgreen)\ **Post date:** [February 8, 2020, 11:41am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/8 "2020-02-08T11:41:25Z")
another thing to watch out for is /etc/mender/mender.conf on the root file system also contains references to both device partitions. Not sure why or whether relevant if using mender client in standalone mode. So is setting MENDER\_ROOTFS\_PART\_A, MENDER\_ROOTFS\_PART\_B and MENDER\_STORAGE\_DEVICE\_BASE to your virtual device and device partitions still failing the build? ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 8, 2020, 11:52am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/9 "2020-02-08T11:52:52Z")
> another thing to watch out for is /etc/mender/mender.conf on the root file system also contains references to both device partitions. Not sure why or whether relevant if using mender client in standalone mode. Thank you for pointing out this part. I will take care of the mender.conf. > So is setting MENDER\_ROOTFS\_PART\_A, MENDER\_ROOTFS\_PART\_B, and MENDER\_STORAGE\_DEVICE\_BASE to your virtual device and device partitions still failing the build? This will eventually fail since the changes will call “`get_part_number_from_device()`” and “`get_uboot_device_from_device()`” inside “`meta-mender-core/classes/mender-helpers.bbclass`”. This call is coming from the `meta-mender-core/recipes-bsp/u-boot/u-boot-mender-common.inc`’s “do\_provide\_mender\_defines()”. Both “`get_part_number_from_device()`” and “`get_uboot_device_from_device()`” currently hardcoded the partitions format. I have added the “`dm-`” in these calls but still getting the error. I’m debugging the issues 😇 ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [February 10, 2020, 8:43am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/10 "2020-02-10T08:43:51Z")
I have not personally worked with dm-crypt so do not have much more to add then what has been covered in this thread. ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [February 19, 2020, 12:48pm UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/11 "2020-02-19T12:48:11Z")
I did a similar thing and maybe I am able to give a few hints: I am using an unmodified Mender (2.1) with LUKS/dm-crypt encrypted partitions (Data, A and B are encrypted, the boot partition is not encrypted). The partition setup in /etc/mender/mender.conf contains the following values: ``` "RootfsPartA": "/dev/mapper/mydevice-root", "RootfsPartB": "/dev/mapper/mydevice-root-mmcblk2p3", ``` The RootfsPartA is constant while the RootfsPartB setting gets adjusted within a Download\_Enter… script. In an ArtifactInstall\_Leave… script I copy the signed FIT image from the encrypted rootfs partition to the unencrypted boot partition. U-Boot will then check the signature of the FIT image. Unfortunately I cannot give any hints about the Yocto integration as I have done the full secure boot setup based on Debian using my tool called [edi](https://www.get-edi.io). ---
**Author:** ![ajithpv](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/ajithpv/32/728_2.png) [@ajithpv](https://hub.mender.io/u/ajithpv)\ **Post date:** [February 20, 2020, 12:50pm UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/12 "2020-02-20T12:50:53Z")
> [@lueschem](#): > > The RootfsPartA is constant while the RootfsPartB setting gets adjusted within a Download\_Enter… script. I would like to know whether the RootfsPartA is always constant or will change during next update? Also how the A/B rootfs update working with the above case (including the fallback)? 🤔 ---
**Author:** ![lueschem](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/lueschem/32/214_2.png) [@lueschem](https://hub.mender.io/u/lueschem)\ **Post date:** [February 21, 2020, 11:34am UTC](https://hub.mender.io/t/how-to-configure-the-mender-to-use-dm-crypt-partitions-for-rootfs/1508/13 "2020-02-21T11:34:09Z")
I keep RootfsPartA always constant and just adjust RootfsPartB. Like this Mender will always believe it is running from RootfsPartA. The beauty of device mapper is, that I can mount RootfsPartB within a Download\_Enter… script in a way that it matches /etc/mender/mender.conf. During the update Mender will then happily stream the update to RootfsPartB. The switching between partition A and B on bootloader level is done in a similar way to [this example](https://www.get-edi.io/Booting-Debian-with-U-Boot/). The “primary boot script” looks like [this one](https://github.com/lueschem/edi-pi/blob/master/plugins/playbooks/rpi3_base/roles/bootloader/files/boot.scr.txt). However, a small modification at the end of the script is needed to boot the secondary boot.scr from the unencrypted boot partition instead of the encrypted A or B partition. The secondary boot script then loads and starts the signed fit image that will then mount the encrypted partitions.