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...

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? 

Thanks!

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"





On Friday, April 6, 2018 at 1:28:34 PM UTC-5, Jeff Andich wrote:
>
> *** 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..
>
>
>
>
>
> 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 
>> 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..
>>
>

-- 
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 
https://groups.google.com/d/msgid/beagleboard/1e0e16e0-1267-4023-9f94-3894e24091b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to