# New iteration of the mender-convert tool **URL:** \ **Category:** General Discussions\ **Created:** [July 12, 2019, 6:39pm UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824 "2019-07-12T18:39:03Z")\ **Posts on this page:** 10\ **Page:** 1
**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:** [July 12, 2019, 6:39pm UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/1 "2019-07-12T18:39:03Z")
Hi, As you might be aware of we have a tool we call `mender-convert` to enable support for Mender on binary distributions. > **[mendersoftware/mender-convert](https://github.com/mendersoftware/mender-convert)** > > An easy way to integrate the Mender client into an existing image - mendersoftware/mender-convert We are happy that this has worked out, enabling people to securely update their devices on non-Yocto devices. Even though we are happy with the functionality of the current tool, there are a couple drawbacks in the current design of the tool, which we want to improve. We looked hard at the current code and decided, to achieve the desired design we would need to do a re-write. We obviously learned a lot while developing the first iteration and we are trying to apply that knowledge to the current development effort. The goals of the re-write was to achieve the following (lacking today): 1. It should be easy to extend the tool to support other boards or distributions 2. We should not compile code in the tool (rely on binaries built elsewhere) - compiling code increases complexity, due to requirement of toolchains etc. 3. The tool shall not be designed around specific hardware/platform types - This is the case today with the usage of `--device-type` flag 4. The tool should be to convert images without knowing anything about the hardware/platform - relates to above 3. 5. Configuration interface should be simplified - command line flags -\> configuration files 6. Platform specific code shall be provided trough “hooks”, and are not part of the “core” mender-convert code 7. It shall be easy to extend functionality - support for rootfs overlay to inject user applications/configurations - ability to override how the Mender Artifact is generated (to be able to sign and include state-scripts) 8. Code structure should be modular - Eases Maintenance and possibility of making isolated changes With that being said, the source code of the new iteration that tries to implement above mentioned goals currently lives here, [https://github.com/mendersoftware/mender-convert/tree/next](https://github.com/mendersoftware/mender-convert/tree/next) Considered this a early beta release, and would love to get feedback on the design and if you are able to test things out and report any issues. There is still a lot of documentation to be written, and you will probably need to inspect the source code to get a full understanding of how certain things work but that is how it is 😃. The following platforms have been run-time tested: - Raspbian (Raspberry Pi 3) which is covered in the [README](https://github.com/mirzak/mender-convert/tree/v2#docker-environment-for-mender-convert) - Ubuntu Bionic (x86-64) - Instructions on how to test this can be found [here](https://github.com/mirzak/mender-convert/blob/v2/configs/qemux86-64_config) - Armbian (Pine64 ROCKPro64, SD & eMMC) - Debian on BeagleBone Black (SD & eMMC) There is no defined timeline when we would make the switch to make this tool the official one, and we will maintain both until we decide on this. Though new development will be focused on the updated version, especially adding support for new boards or distributions. Thanks! Edit: @mirzak: Updated link to the `next` branch of mender-convert repository, which is the current development branch for this new version of the tool ---
**Author:** ![incomplete](https://avatars.discourse-cdn.com/v4/letter/i/8491ac/32.png) [@incomplete](https://hub.mender.io/u/incomplete)\ **Post date:** [October 29, 2019, 10:23am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/2 "2019-10-29T10:23:35Z")
Hi, Thanks for the new iteration, I use it to alter a ubuntu image on x86 64. Which branch do you suggest to use? the `v2` branch or the `master-replaced-v1-with-v2`? I tested the `v2` branch, it can `mender -install ` and can boot into it, but on boot, it says: ```auto error: no such device: (hd0, msdos1)/EFI/BOOT/EFI/BOOT/grub.cfg. lock: OK lock: OK ``` Also, the esp partition is a bit messy (`EFI` nested in `/boot/efi`), is this intended? ```auto # hand-typed $ ls /boot System.map-4.15.0 xxxx config-4.15.0-20-generic loader a5f4ae(a long string, seems like a checksum) abi-4.15.0-20-generic efi initrd.img-xxx retpoline-4.15xxx vmlinuz-4.15xxx /boot/efi/EFI/BOOT ``` ---
**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:** [October 29, 2019, 11:32am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/3 "2019-10-29T11:32:42Z")
Actually I would recommend to try this branch, [https://github.com/mendersoftware/mender-convert/tree/next](https://github.com/mendersoftware/mender-convert/tree/next) Forgot to update this thread with the progress ---
**Author:** ![shainert.israel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/shainert.israel/32/438_2.png) [@shainert.israel](https://hub.mender.io/u/shainert.israel)\ **Post date:** [November 28, 2019, 11:55am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/4 "2019-11-28T11:55:33Z")
What is the changes needed to support BIOS GRUB? ---
**Author:** ![drewmoseley](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/drewmoseley/32/47_2.png) [@drewmoseley](https://hub.mender.io/u/drewmoseley)\ **Post date:** [November 28, 2019, 5:32pm UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/5 "2019-11-28T17:32:03Z")
@mirzak @lluiscampos @kacf any comments here? I know we’ve tested it with Yocto but in mender-convert I don’t now. ---
**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:** [November 29, 2019, 9:18am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/6 "2019-11-29T09:18:13Z")
The best source of inspiration on how this can achieved is probably this commit in meta-mender, > Where we added BIOS support, and the primary tasks would be: 1. GRUB needs to built “differently” to produce a `boot.img` 2. The `boot.img` must be embedded in the `sdimg` after the MBR Also this tutorial provides some insights how it all works, > **[Compiling and installing Grub2 for standalone USB boot](https://pete.akeo.ie/2014/05/compiling-and-installing-grub2-for.html)** > > The goal here, is to produce the necessary set of files, to be written to an USB Flash Drive using dd (rather than using the Grub installer... We can probably produce the correct GRUB binaries using Yocto, this is what we already are doing for the EFI binaries which are uploaded to an S3 bucket and mender-convert fetches them. ---
**Author:** ![shainert.israel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/shainert.israel/32/438_2.png) [@shainert.israel](https://hub.mender.io/u/shainert.israel)\ **Post date:** [December 2, 2019, 7:29am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/7 "2019-12-02T07:29:47Z")
Hi mirzak, I would like some clarification so I will not go to dead end direction. I’m not sure what should I do so the output image file will boot. Do you suggest a way to convert BIOS GRUB image into new Uboot image, UEFI GRUB or BIOS GRUB? I prefer getting BIOS GRUB at the end. What is the relation of meta-mender and mender-convert “next” branch? I guess I should change mender-convert “next” branch in the same way meta-mender was changed? Thank You, Israel ---
**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:** [December 2, 2019, 7:41am UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/8 "2019-12-02T07:41:27Z")
> [@shainert.israel](#): > > I prefer getting BIOS GRUB at the end. I think this would be would be possible. > What is the relation of meta-mender and mender-convert “next” branch? meta-mender is meta data for the Yocto Project and there is no strict relation between meta-mender and mender-convert. But meta-mender does contain logic that could be ported to mender-convert, e.g the x86 BIOS support I linked. > I guess I should change mender-convert “next” branch in the same way meta-mender was changed? Yes, to some extent. Everything is not applicable and some code is for Yocto project only. ---
**Author:** ![shainert.israel](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/shainert.israel/32/438_2.png) [@shainert.israel](https://hub.mender.io/u/shainert.israel)\ **Post date:** [December 12, 2019, 1:28pm UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/9 "2019-12-12T13:28:01Z")
Hi, I understand that the ability of the Mender Client service to come up is the indication that a full OS update is OK. Does Mender full OS update enable supplying user-exit script that will check that the upgrade is OK? Thank You, Israel ---
**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:** [December 12, 2019, 1:30pm UTC](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824/10 "2019-12-12T13:30:40Z")
There are ways of extending the sanity check. Please have a look at, [https://docs.mender.io/2.2/artifacts/state-scripts](https://docs.mender.io/2.2/artifacts/state-scripts) and specifically, [https://docs.mender.io/2.2/artifacts/state-scripts#custom-sanity-checks-after-the-update-is-installed](https://docs.mender.io/2.2/artifacts/state-scripts#custom-sanity-checks-after-the-update-is-installed)