Sorry I couldn't help more Sam . . . This problem seems kind of obscure to me. I do not remember reading about, or hearing of a similar issue. If you did happen to buy, or borrow a serial debug cable. You could run both configurations, logging the boot log output to file. Then run a diff on them to see if anything stands out.
You can also try this with dmesg . . . and . . . just poking around myself . . . debian@beaglebone:~$* dmesg > ~/file* debian@beaglebone:~$ *nano ./file* *[ 3.590829] bone-pinmux-helper P8_27_pinmux.18: Set initial pinmux mode > to hdmi* > *[ 3.598760] bone-pinmux-helper P8_28_pinmux.19: Set initial pinmux > mode to hdmi* > *[ 3.606640] bone-pinmux-helper P8_29_pinmux.20: Set initial pinmux > mode to hdmi* > *[ 3.614507] bone-pinmux-helper P8_30_pinmux.21: Set initial pinmux > mode to hdmi* > *[ 3.622286] bone-pinmux-helper P8_31_pinmux.22: Set initial pinmux > mode to hdmi* > *[ 3.630087] bone-pinmux-helper P8_32_pinmux.23: Set initial pinmux > mode to hdmi* > *[ 3.637903] bone-pinmux-helper P8_33_pinmux.24: Set initial pinmux > mode to hdmi* > *[ 3.645782] bone-pinmux-helper P8_34_pinmux.25: Set initial pinmux > mode to hdmi* > *[ 3.653558] bone-pinmux-helper P8_35_pinmux.26: Set initial pinmux > mode to hdmi* > *[ 3.661459] bone-pinmux-helper P8_36_pinmux.27: Set initial pinmux > mode to hdmi* > *[ 3.669453] bone-pinmux-helper P8_37_pinmux.28: Set initial pinmux > mode to hdmi* > *[ 3.677472] bone-pinmux-helper P8_38_pinmux.29: Set initial pinmux > mode to hdmi* > *[ 3.685519] bone-pinmux-helper P8_39_pinmux.30: Set initial pinmux > mode to hdmi* > *[ 3.693538] bone-pinmux-helper P8_40_pinmux.31: Set initial pinmux > mode to hdmi* > *[ 3.701634] bone-pinmux-helper P8_41_pinmux.32: Set initial pinmux > mode to hdmi* > *[ 3.709755] bone-pinmux-helper P8_42_pinmux.33: Set initial pinmux > mode to hdmi* > *[ 3.717978] bone-pinmux-helper P8_43_pinmux.34: Set initial pinmux > mode to hdmi* > *[ 3.726225] bone-pinmux-helper P8_44_pinmux.35: Set initial pinmux > mode to hdmi* > *[ 3.734519] bone-pinmux-helper P8_45_pinmux.36: Set initial pinmux > mode to hdmi* > *[ 3.742802] bone-pinmux-helper P8_46_pinmux.37: Set initial pinmux > mode to hdmi* > *[ 3.756370] bone-pinmux-helper P9_19_pinmux.46: Set initial pinmux > mode to i2c* > *[ 3.764617] bone-pinmux-helper P9_20_pinmux.47: Set initial pinmux > mode to i2c* > *[ 3.777412] bone-pinmux-helper P9_25_pinmux.52: Set initial pinmux > mode to audio* > *[ 3.789016] bone-pinmux-helper P9_28_pinmux.55: Set initial pinmux > mode to audio* > *[ 3.798144] bone-pinmux-helper P9_29_pinmux.56: Set initial pinmux > mode to audio* > I wonder if somehow pinmux-helper could somehow be causing issues here ? On Thu, May 7, 2015 at 2:01 PM, Sam Thomas <[email protected]> wrote: > I am pretty sure it isn't a pin conflict since I can remote desktop in as > root and access the mounted drives no problem. > > Something strange is happening to my permissions as soon as I run uEnv.txt > > I have checked my sudoers file and nothing in there has changed. > > Unfortunately I don't have a usb to serial cable. > > Thanks for your help William > > On Thu, 7 May 2015 at 08:49 William Hermans <[email protected]> wrote: > >> So, the comment by me above "sounds like a pin conflict", doesn't mean I >> think for a second that it *is* a pin conflict. I just meant that it is a >> "reaction" one might expect from having a pin conflict . . . the sdcard, >> and hdmi should be able to work properly at the same time. >> >> I seem to recall reading something about a udev rule fix a long time back >> - For situations like these but . . . What I am "remembering" is rather >> vague in my mind at the moment. >> >> On Wed, May 6, 2015 at 3:40 PM, William Hermans <[email protected]> >> wrote: >> >>> Sounds like a possible pin conflict but . . . >>> >>> I was reading an ARCHLinux post concerning a similar problem( but on PC >>> ), and the person fixed it by making some additions to the PAM >>> configuration file. >>> >>> https://bbs.archlinux.org/viewtopic.php?id=167947 >>> >>> ( post #5 ). >>> >>> Not sure that would fix the problem, but might be worth a try. However, >>> if you remove the "quiet" from the optarg variable, and you have a serial >>> debug cable. The output I believe should be more verbose. You can also look >>> through dmesg, and /var/log/messages to see if you can spot anything >>> obvious. >>> >>> On Wed, May 6, 2015 at 3:11 PM, Sam <[email protected]> wrote: >>> >>>> Hey again William! >>>> >>>> I am just using the default debian user for now so I have not messed >>>> with the sudoers file. >>>> >>>> If I comment out "optargs=quiet >>>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" in my uEnv.txt then >>>> my usb and uSD is automounted correctly. So something strange is happening >>>> when HDMI is disabled. >>>> >>>> I am accessing the BBB with xrdp which may also have something to do >>>> with it. >>>> >>>> I wonder if there somewhere else that I can run the command to disable >>>> the hdmi that is not on external memory. See if that helps? >>>> >>>> Failing that I could try running debian from the uSD. At least that >>>> would give me all the memory I need. >>>> >>>> >>>> >>>> On Wednesday, 6 May 2015 19:44:30 UTC+10, Sam wrote: >>>>> >>>>> >>>>> Hey Everyone! >>>>> >>>>> I want to use my HDMI pins for other purposes. >>>>> >>>>> I have added a uEnv.txt to my bone that contains >>>>> "optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN" >>>>> >>>>> when i cat the slots >>>>> debian@beaglebone:~$ 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 >>>>> >>>>> Unfortunately when I click a mounted drive in LXDE I get an error "Not >>>>> Authorised" >>>>> >>>>> I can access the drives as root though. >>>>> >>>>> Is something happening to the permissions of the mounted drives when >>>>> uEnv.txt is run? >>>>> >>>>> Cheers! >>>>> >>>>> Sam >>>>> >>>>> >>>>> >>>>> -- >>>> 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]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/893ifb_sEwI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
