Running from eMMC will / "always" be mounted on /dev/mmcblk1p1, From SD Always/ on /dev/mmcblk0p1 ?


When Linux and our application is running from eMMC, we wish to be able to create log files on a uSD card plugged into the uSD slot on our board.

I’ve ported some scripts which a former colleague wrote for the BeagleBone Black that create a mount point on a factory default SD card if the SD card exists, and re-formats the FAT to an ext4 partition. Basically they used a udev script to trigger on the presence of /dev/mmcblk0p1 or /dev/mmcblk1p1 and then call a shell script (from a systemd service launched by udev) for formatting and mounting the SD card.

One key thing that that shell script did was to detect where Linux was running (e.g. /dev/mmcblk0p1 vs mmcblk1p1) based on examining the label of the storage device, and then mounting the other device if it exists. This capability to handle the ‘/’ mount point “pingponging” between /dev/mmcblk0 and mmcblk1 was needed due to the mount point changing for the eMMC depending on whether an uSD card was plugged into the slot on the BeagleBone Black with kernel 3.8.?.

However, on the baseline images I’ve been using for the BB-X15, I haven’t yet observed any pingponging in that ‘/’ always SEEMS to be mounted on /dev/mmcblk1 when running from eMMC and /dev/mmcblk0p1 when running from uSD card. I’ve been working with a BB-X15 console image consisting of (Debian 8.10, kernel 4.4.110, and some variant of u-boot 2017.01),

?? Will this always be the case for the BB-X15 (and other devices) or at least with the Debian version, kernel version, and u-boot version we’re using??

If so I’d like to take advantage of this fact in the shell script to only create a mount point on the SD card when it doesn’t contain a Linux image and when ‘/’ is mounted on /dev/mmcblk1p1. But I’m afraid that this assumption may not hold and come back to bite us at some point.

Thanks in advance!


According to my notes, this "randomness-race-label" condition was
first "fixed" in the v4.5.x merge and "really" fixed in v4.5.3

We back-ported these two fixes to our v4.4.x-ti tree for the bbb and bbx15.


Thanks Robert!!

…One of these days, I need to be following what’s going on with the commits and the upstream…