Does break UDEV's Ability to See MMCBLK0P1?


We’ve got a mechanism for creating a mount point on an SD card, specifically used for storage/logging while our main application is running from eMMC (mmcblk1p1) on a BB-X15 - like platform. The mechanism uses UDEV rules to fire on the presence of a properly formatted SD card in the slot which doesn’t have label rootfs. The UDEV rule (listed below) is looking for the presence of mmcblk0p1, and if found, initiates a systemd service which calls a shell script which then detects mmcblk0p1 (while the main image (rootfs) is running on mmcblk1p1), and then if mmcblk0p1 is found, the script checks the formatting on the SD card, re-formats to ext4, if necessary, and then creates a mount point for storage on the card.

Everything was working ok when I copied/created the scripts on the running eMMC image (and on a master SD card flasher image to install the image + scripts on the eMMC).

However, when I called the script for cloning the eMMC to an SD card, yesterday for the first time, the script apparently broke UDEV’s ability to fire on MMCBLK0P1 on the eMMC image after the script finished uploading to SD card. As after I powered the image running from eMMC down and inserted a “properly formatted SD card” in the slot (but without the label rootfs), our UDEV rules never fied.

But from this state UDEV was still able to fire on the presence of MMCBLK1P1, and if I “relax” the UDEV rule to fire on either mmcblk[0-1] our shell script runs and IS able to look for /dev/mmcblk0p1 and format the SD card if found. But I really don’t want to change this as we’ve shown that that the UDEV rule fires so long as I don’t run the cloner script. Additionally the UDEV rule should just fire on the presence of MMCBLK0P1, and not on MMCBLK1P1, as I don’t know about the order that the drivers load when the kernel is booting… What if the shell script runs before /dev/MMCBLK0P1 is “available” after first detecting /dev/MMCBLK1P1?? I guess I could create a systemd service (?or cron job??) which periodically looks for the presence of /dev/mmcblk0p1 and then mounts the SD card, if found??

More details on what’s happening:



Film at 11…

Ok, I finally did the following:

->ran a stock console image, 2018-02-01 on my BB-X15,
->copied the above referenced auto-mount scripts to that image on SD card.
->Converted that SD card image containing the mount point scripts to a flasher image to flash the eMMC,
->inserted a blank SD card with a single FAT partition, rebooted, and the automount scripts created a mountpoint on /dev/mmcblk0p1.

->then ran /opt/scripts/tools/eMMC/ to clone the eMMC to SD card,
->removed that clone SD card,
->inserted a blank SD card with a FAT partition back in the SD card slot.
->Re-booted, and confirmed that our BB-X15 is still running from the eMMC image (which may have been changed by

After which it APPEARS like the UDEV rules in my udev script don’t appear to be firing any more on /dev/mmcblk0p1, only /dev/mmcblk1p1…

I’m not sure why appears to modify the eMMC image which it copies from.

Does the script, for instance, switch something off with /dev/mmcblk0 to protect the cloning process so that the kernel temporarily doesn’t report /dev/mmcbl0 to udev?

I need to dig into the script (both eMMC to SD card and SD card to eMMC) to get a better idea of what’s going on, but I was wondering whether the above scenario rings any bells?

Thanks in advance!!


More details are provided below on this mechanism for auto-mounting an SD card:

KERNEL!=“mmcblk0p1”, GOTO="mmc_job_storage_mount_end
ENV{ID_FS_LABEL}==“rootfs”, GOTO=“mmc_job_storage_mount_end”

(The folllowing systemd service, setup-mount-point calls a shell script to detect both blk devices and format and setup a mount point
on /dev/mmcblk0p1 in the event that mmcblk1p1’s label == rootfs and mmcblk0p1’s label !=rootfs).

ACTION==“add”, TAG+=“systemd”, ENV{SYSTEMD_WANTS}=“setup-mount-point.service”