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 [email protected].
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.
