Skip to content

.gitlab-ci.yml: create bmap file to enable flashing with 'bmaptool copy'

Johannes Schauer Marin Rodrigues requested to merge bmaptool into main

Offer bmap files for each image which allow users to use bmaptool copy to flash the images. The bmap utility uses the information from the bmap xml files to only copy those blocks which do contain data (thus the transfer is faster), it verifies checksums and it performs checks to prevent accidentally flashing to the wrong drive.

This is how it looks like in action:

$ sudo bmaptool copy https://source.mnt.re/reform/reform-system-image/-/jobs/4000/artifacts/raw/reform-system-ls1028a.img.gz /dev/mmcblk0
bmaptool: info: discovered bmap file 'https://source.mnt.re/reform/reform-system-image/-/jobs/4000/artifacts/raw/reform-system-ls1028a.bmap'
bmaptool: info: block map format version 2.0
bmaptool: info: 1174529 blocks of size 4096 (4.5 GiB), mapped 828242 blocks (3.2 GiB or 70.5%)
bmaptool: info: copying image 'reform-system-ls1028a.img.gz' to block device '/dev/mmcblk0' using bmap file 'reform-system-ls1028a.bmap'
bmaptool: info: 100% copied
bmaptool: info: synchronizing '/dev/mmcblk0'
bmaptool: info: copying time: 4m 32.8s, copying speed 11.9 MiB/sec

I verified that it aborts when trying to write to a block device that has mounted partitions on it. It seems to do so by trying to open the device with O_EXCL.

Advantiages over dd:

  • faster, because not the whole image has to be written to the sd-card (currently, only 70% are actual data that needs writing)
  • verifies checksums automatically
  • automatically discovers the bmap file, so nothing needs to be downloaded additionally first
  • can directly download from a https:// source without having to download the image first
  • automatically decompresses the image without having to manually unpack it
Edited by Johannes Schauer Marin Rodrigues

Merge request reports