Does beaglebone-black-make-microSD-flasher-from-eMMC.sh break UDEV's Ability to See MMCBLK0P1?

[Jeff Andich]

Hi,

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, beaglebone-black-make-microSD-flasher-from-eMMC.sh 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:

***************************************

The following UDEV rule triggers on our working image, running from eMMC with a properly formatted SD card in the slot, but breaks after we run, beaglebone-black-make-microSD-flasher-from-eMMC.sh .

 

KERNEL!="mmcblk0p1", GOTO="mmc_mount_end"

But after running beaglebone-black-make-microSD-flasher-from-eMMC.sh, the only rule which will fire is:

KERNEL!="mmcblk[0-1]p1", GOTO="mmc_mount_end"

Notes:

1) I have not yet tested if UDEV will fire on MMCBLK0 in place of MMCBLK0P1.

2) When I ran beaglebone-black-make-microSD-flasher script for the first time, the uSD card (utilized for the clone of eMMC) was formatted with a single ext4 partition.  (Linux said ext4 partition, but when I ran fdisk, fdisk said FAT32 W95).  

3) But when the beaglebone-black-make-microSD script ran, it spat out a comment leading me to believe that the uSD card (for cloning eMMC) should be partionless (e.g. just run sudo dd if=/dev/zero of=${DISK} bs=512 count=1, but I ran bs=1M and count=1000), so I erased it without running fdisk to create a partition, and then re-ran beaglebone-black-make-microSD....  But I ended up with the same issue with the script disabling UDEV's ability to see MMCBLK0P1. 

??I was wondering if the beaglebone cloner script needed to disable UDEV rules for MMCBLK0P1 without really understanding the nuts and bolts of what the script actually does..

4) cat  /etc/dogtag:  2018-01-01.  

5) I have not run a git pull on the /opt/scripts/tools directory, but I didn't SEE any updates to functions.sh post 2018-01-01..

6) kernel: 4.4.110

7) I "slightly hacked" and renamed functions.sh in that I copied our custom board u-boot and MLO to the backup/uboot folder and reference that in the functions.sh script instead of the default (This maybe not needed and a bad idea which I will have to fix later), but I don't THINK any of this gets called anyway for the eMMC to SD card and flasher scripts I'm running.

TO DO:

*I need to run a git pull on the /opt/scripts directory on target and re-run the beaglebone cloner script to see if the outcome is different.

*Start looking into the script to figure out why this could be happening.

*Modify UDEV rules to trigger on MMCBLK0 instead of MMCBLK0P1..

[Jeff Andich]

*** PLEASE IGNORE THIS THREAD UNTIL i TEST THIS  SAME SCENARIO ON A BB-X15  ***

THIS WAS THE RESULT ON OUR CUSTOM BOARD. 

Film at 11..

[Jeff Andich]

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/beaglebone-black-make-microSD-flasher-from-eMMC.sh 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  beaglebone-black-make-microSD-flasher-from-eMMC.sh).

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 beaglebone-black-make-microSD-flasher-from-eMMC.sh 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!!

Jeff

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"  

LABEL="mmc_job_storage_mount_end"