Call lsblk to detect MICROBIT devices

[conchyliculture]

By default on debian mount won't display labels, you need mount -l To get a more specified (and hopefully universal) string for mounted block devices, it is preferable to run lsblk (which is in util-linux package)

[virtualabs]

Well, I am using Debian and have no problem with the current version of Btlejack. Can you give more insight about the error you may have encountered ?

[conchyliculture]

The current code searches for a mounted partition with the name MICROBIT. The problem is on my debian (buster), mount doesn't display the labels by default:

$ mount --version
mount from util-linux 2.32.1 (libmount 2.32.1: selinux, smack, btrfs, assert, debug)

From the manual:

       The following command lists all mounted filesystems (of type type):

              mount [-l] [-t type]

       The option -l adds labels to this listing.  See below.

I don't have a microbit device with me right now to test. So if I make a silly file with just a VFAT partition with a name:

# truncate -s 100M img ; sgdisk -og  img ; sgdisk -n 1:2048:20480 img ; losetup --show -fP img
/dev/loop0
# mkfs.vfat -n MICROBIT /dev/loop0p1 ; mkdir /mnt/testlabel ; mount /dev/loop0p1 /mnt/testlabel

With mount:

# mount | grep testlabel
/dev/loop0p1 on /mnt/testlabel type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

with mount -l :

# mount -l | grep testlabel
/dev/loop0p1 on /mnt/testlabel type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) [MICROBIT]

For other projects, I found that lsblk has nicer options for output parsing. But maybe we should follow what the mount manual says:

   Listing the mounts
       The listing mode is maintained for backward compatibility only.

       For more robust and customizable output use findmnt(8), especially in your scripts.   Note  that  control
       characters in the mountpoint name are replaced with '?'.

[nviennot]

lsblk is not present by default on MacOS. So I vote for no.