Raspberry Pi 3 Model B/B+ Raspbian

Tested newest Raspbian (2019-04-08) with Hosted Mender just now. No issues.

Also upgrading from 2018-11-13 to 2019-04-08 using a Mender Artifact works as expected! :slight_smile:

I built my mender image using 1.1x in Feb, then Mender Server 2.0 was released. Will my image work if I upgrade my server to Mender 2.0?

There was one change in your readme where you removed this line:

./docker-mender-convert from-raw-disk-image
–mender-client /mender

Currently, the image I created works great with Mender 1.7

Yes, that should be no problem!

3 posts were split to a new topic: Issues adding Mender to 2018-04 raspbian lite

11 posts were split to a new topic: Problems with Raspbian Buster

5 posts were split to a new topic: Issue with GL driver on Raspbian Stretch

6 posts were split to a new topic: Device not visible in “Pending”

3 posts were split to a new topic: Can I create a new artifact from an mender based sdimg?

Are there any standard set of test cases, that one should conduct to test the integrity of the system.
Apart from the normal ones

See this link: https://docs.mender.io/hosted/devices/yocto-project/bootloader-support/u-boot/integration-checklist

Of course that just tests Mender. You probably will need to review Raspberry Pi docs and general Yocto docs to understand other parts of the system and the needs for testing there.


Yes, Sorry I did not phrase my question properly. I did perform those steps. What I wanted to know. How do I test the retry and rollback feature from the https://hosted.mender.io

How do I create a failed scenario? How do I create a retry scenario?

I think I don’t know care about the fail scenario because the board integration checklist takes care of that. but How Do I create a retry scenario?

The steps in the integration checklist do verify that rollback is performed but if you want to test it in a full deployment then just power cycle the board while it is rebooting the first time.

Testing a retry will require implementing state scripts. You can see our examples here. If you create a ArtifactCommit_Enter script that returns “21” then it will retry. You will need to make sure to eventually return OK to avoid the server timing out the deployment.

Im still having the Problem with my Image not booting after converting it due to ‘dtoverlay=pi3-disable-bt’.

Can someone explain how exactly to aply the workaround reported in here

Im not very experienced with patching uboot.


I was able to fix the problem with disable-bt overlay:

  • I forked the mender-uboot and applied the patch mentioned here
  • I patched integration-scripts to create the binaries
  • I run mender-convert using the patched binaries
    Everything is now running nice and smoothly and i can use ttyAMA0.

I think it would make sense to offer that patched version of mender-uboot binaries for a “new” device type (raspberrypi3serial) and by assigning RASPBERRYPI_CONFIG=“raspberrypi3serial” those binaries would then be used when running mender convert. the raspberrypi_config.)


Sounds interesting!

How about a PR, and we’ll take it from there?


I just encountered an issue when upgrading from buster to bullseye. This update does also need updates to the boot partition. I’m writing this here in the hope it helps others spend less time debugging…

1 Like

Whenever I run mender-convert the output is 8.6GB, whether I supply it with a golden image from an 8GB SD card or the standard 2021-10-30-raspios-bullseye-armhf-lite.img

This 8.6GB file then doesn’t fit on my 8GB SD card?

Hmm, interesting.

The linked imabe above should be converted with the latest mender-convert, and is only 7.4GiB.

What parameters are you running the conversion with?

I follow the instructions above (Build Docker image for mender-convert) line-by-line and I end up with a .img file that’s 8.6 GB (8,589,934,592 bytes). Thanks.

There is one difference between the image produced by the tutorial above, and the image provided in the link, and that is that the image provided in the link has a few extra configurations added.

Especially the configurations from configs/images/raspberrypi_raspbian_config.

Most interestingly for you probably is the added:

# Real life SD cards typically have less than they advertise. First off, they
# often use a base of 1000 instead of 1024, and even then they are often smaller
# than advertised. The number below is based on a conservative target of 7.9GB
# (that's mathematical GB, base 1000), converted to MiB, rounding down.


1 Like