BBB will not open() files when running from microSD card

OK weird problem so maybe I am missing something. I am booting from micro SD card, running my code from the SD card but when the code executes FD = open(“myFile”, O_RDONLY); it returns -1 but errno = 0 ! I tried several files, same thing. Files are there, permissions are -rw-r–r-- so I should be able to read it. This code runs properly when booting and running from the onboard eMMC. The SD card code can cat the files, create threads, run the GTK UI but will not open a file for read. What am I missing?
The SD card is running
NAME=“Debian GNU/Linux”
VERSION=“11 (bullseye)”
Linux version 5.10.145-ti-r55

while the eMMC is Debian 10 buster Linux kernal 4.19.94.ti-r42.

Have a Blessed day!

You will have to post more of the code, from the top down to where you are opening it up.


I remember an older model of the source images that the people would provide. One would have to erase the first some-eyed bytes of the eMMC to use the SD Card. This was an issue for me when getting new boards w/ an already programmed eMMC and u-boot.

To my knowledge, this issue has been resolved and a provided script handles the SD Card booting into the SD Card u-boot instead of the SD Card booting into the u-boot from the eMMC.

I just figured since you are using 5.10.x kernels from, one would have this script programmed to run after a reboot or booting the machine again, i.e. the target BBB.

If this is not the case and if the u-boot on the SD Card is giving an issue, I will research more on it.

Please provide the below command output for each, separate command:

uname -a


cat /etc/dogtag


P.S. I will go and look at my image and report back but I am almost certainly positive that u-boot gets pushed to SD Card when using SD Card even though the eMMC has it available when rebooting.

Hello again,
The SD card seems to be working as the code will run just will not open a file.
uname -a for SD card:
Linux BeagleBone 5.10.145-ti-r55 #1bullseye SMP PREEMPT Tue Dec 6 23:59:06 UTC 2022 armv7l GNU/Linux
dogtag Debian Bullseye IoT Image 2023-01-02

my test code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>

extern int find_voltage1_raw(int argc, char *argv[], char* LinePath);
static char AD_Path[512];
char * popen_error[256];

int main()
    int fh;

     fh = open("/usr/DonCode/testfile.txt", O_RDONLY);		//returns -1 if open failed because path wrong
     if (fh = -1) {
		fprintf(stderr, "error opening file, fh = %d, errno = %d \n", fh, errno);

    return 0;

output is: error opening file fh = -1, errno = 0

I have tried to open several files, simple text files in Linux to test file I created, none open in the SD card in the program. All files I try to open in this program can be opened or viewed by various means. This code and the main program it is from work from the eMMC.

Have a Blessed day!

Go into the directory containing your testfile and

$ pwd

it needs to be the exact path used to open it.

Then go above that directory and

$ ls -al

Never hurts to check permissions when things don’t work.

Thank for your reply but I checked the permissions for the file (I tried several files) and they are -rw-r–r-- which, I think, means I can read them. I can -rw-r–r-- cat the files from the code using the same path. The testfile is in the same directory as the executing code. The image I am using is

Could I have flashed it to the sd card with some weird permission set wrong? Again the code works, I can open() the same file in the same directory structure running in the eMMC. I am logged in as root. The code I gave above is executable as
-rwxr-xr-x- .

This is such a weird problem I must be doing something dumb but simple.

Have a Blessed day1

Are you logged in as root or user?

Hello @DonTrustee ,

This may sound odd. Try to put the same images and same u-boot variants on the different mediums.

So, for instance, one would have kernel 4.19.x on the eMMC w/ u-boot 2019-10 and then the same for the SD Card.

B/c of what I described earlier, timing, development, and so on, u-boot and kernels need to be similar if not the same if using the eMMC w/ kernel 4.19.x.


P.S. At least, from my perspective, this idea was the truth. So, from me, I say use Kernel 4.19.x and kernel 4.19.x w/ u-boot 2019-xx or whatever but have them the same for u-boot and kernel on eMMC and SD Card.

Maybe I am not making myself clear enough…

eMMC: kernel 4.19.x and u-boot 2019.10

and then…

SD Card: kernel 4.19.x and u-boot 2019.10

and so on…

W/ the updated images w/ different u-boot and kernels, from what I have seen now handles the automatic source code that changes u-boot variants upon reboot or booting again after shutting down.

But since you have an older model of the image on eMMC, circa kernel 4.19.x or before which may have been Buster or an earlier Debian Distro, the source code to automatically handle u-boot variants is not automatically installed and pushed through…

I do not want to advise you on this matter, e.g. as not backing up data, while listening to me, may create an unbootable eMMC w/ all your old software/hardware unworkable.

I can keep trying to make you understand. Also, if you want…

Show this set of output from these commands:
1. ./var/scripts/tools/ # This is on the eMMC
2. sudo apt install bb-beagle-version && ./bb-beagle-version # SD Card
a. number 2 is for the SD Card if you are using a newer image, 5.10.x w/ Bullseye

I will keep trying here as I have had this issue and overcame it a while back but it is persistent to specific people b/c of them using different u-boot variants on eMMC and SD Card circa kernel 4.19.x.

Thank you all for your answers. I told you I was doing something dumb. If you look at the code I provided you will see if (fh = -1); not if (fh == -1); I looked at that many times but saw what I wanted to see. It ‘works’ in the eMMC but I changed it to be more robust on error handling for the code in the SD card which caught the issue.

Have a Blessed day!

1 Like

Hello @DonTrustee ,

I thought the people fixed that issue. Sorry for trying to give past circumstances that are no longer viable.


P.S. == and not =. Oh.

At least I can play the old card on that one too… Glad you figured that out.