I’ve had this problem a few times now: after a reboot, /media/BEAGLEBONE/ is empty. It doesn’t seem to be linked to any particular action; one time it happened immediately after reflashing the eMMC (to the Angstrom 2013.06.20 image). Sometimes it doesn’t happen until I’ve rebooted half a dozen times.
This has been causing me problems. To free up GPIO pins, I’ve been disabling the HDMI framer via /media/BEAGLEBONE/uEnv.txt:
optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
Eventually I perform the dreaded reboot that wipes /media/BEAGLEBONE/. I don’t realise this until I try to edit /media/BEAGLEBONE/uEnv.txt, and find that it is no longer there. I’ve tried backing up the contents of /media/BEAGLEBONE/, copying them back onto the BBB via WinSCP, editing uEnv.txt to remove the commands to disable HDMI -
optargs=quiet drm.debug=7
- but when I reboot, HDMI is still disabled:
cat /sys/devices/bone_capemgr.*/slots
0: 54:PF—
1: 55:PF—
2: 56:PF—
3: 57:PF—
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
dmesg shows me the following:
Kernel command line: console=ttyO0,115200n8 quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait
This doesn’t resemble my uEnv.txt; it doesn’t seem to get processed. I don’t know where the kernel is picking up this information at boot-time; my newbieness fails me at this point. But the upshot is that my BBB is stuck in one configuration, without any HDMI. Even if I reflash, /media/BEAGLEBONE/ eventually gets wiped again, and I end up in the same state.
If anyone can help me out I would be really grateful 