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

Does the script 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? 



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

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", 


On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
> BB-X15  ***
> Film at 11..
> On Friday, April 6, 2018 at 9:24:59 AM UTC-5, Jeff Andich wrote:
>> 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 
>> 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..

For more options, visit http://beagleboard.org/discuss
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to