piCore-13.0.3 released (32-bit)

[MrPorcine]

Recall that I have been having intermittent problems with missing files after extensions are loaded. I think I have a test for this that is simple enough that anyone can reproduce the error.  Recall that I am using a Raspberry Pi 3 model B+. I'm using an generic 8G SD card, nothing special. During testing I have used several different SD cards.
1)Flash the card with piCore-13.0.3.img. Use gparted to expand the second partition to fill the card.
2)Boot the Pi, change the password, run filetool.sh -b. Reboot
3)Use tce to install Xorg.tcz. Comment out the last few lines of .profile so startx is not called. Run filetool.sh -b again.
4)Copy the attached script as /home/tc/findMissingFile. Use chmod to allow execution. Insert "/home/tc/findMissingFile" as the last line in /opt/bootlocal.sh. Run filetool.sh -b once again.

findMissingFile looks that the file tree at /mnt/tcloop and checks to see if the simlinks in the root file system were created.
On my system, findMissingFile always reports 3 missing .png files. They are missing, but it doesn't matter for our purposes.

About every 2 or 3 reboots findMissingFile finds that the turbo driver "fbturbo_drv.so" is missing. This important as Xorg will not run without this driver. Sometimes findMissingFile finds other files missing as well.

I am very curious if anyone else can reproduce this problem.

[MrPorcine]

Maybe I found something. In tce-bootload, line 206, the simlink from the root file system is created with "'sudo busybox cp -r -f -s ' + root + '/tmp/tcloop/' + p[:-4] + '/* ' + root + '/'". When I look to see the effect of the "-f" here is what I find:

-f, --force
              if an existing destination file cannot be opened, remove
              it and try again (this option is ignored when the -n
              option is also used)

What happens if another thread is creating the same directory tree? Could you get a write block until the other thread is finished?

[MrPorcine]

I was probably a little to short in my explanation of what possibly is going wrong here. Recall that in Unix, if a process has a handle open to a file, and that file is deleted by another process, the file is not deallocated until the first process closes the handle to the file.  I've never seen an explanation of what happens with directories, but it it's similar to files perhaps the following scenario applies:

Process #1 creates a directory. "mydir" The kernel is in process of creation but has not finished.
Process #2 tries to create the same directory, "mydir". It can't as the kernel is still busy with process #1
Process #2, being root, deletes the directory "mydir" and creates a new one with the same name.
Process #1 can't tell that its original directory "mydir" has been deleted, so continues to create the whole path to the file it needs to create.
Process #1 completes. Its copy of the original "mydir" directory is deallocated along with all the files that depend on that directory.

Seems plausible to me.

[MrPorcine]

Here's a patch to tce-bootload. I'm no python expert, but it does seem to work.

[jefferee]

Thanks, everyone.

One request--can you please add libmodbus and libmodbus-dev?

[bmarkus]

Thanks, everyone.

One request--can you please add libmodbus and libmodbus-dev?

Do you mean https://github.com/stephane/libmodbus ?

[jefferee]

Thanks, everyone.

One request--can you please add libmodbus and libmodbus-dev?

Do you mean https://github.com/stephane/libmodbus ?

That's the one. (at least I *think* that was the tcz available in piCore 9.03).
I've actually managed to compile it from source in the meantime, so no rush.

Thanks!

[Juanito]

libmodbus doesn't have any deps, so the extension from piCore 9.x will probably work in 13.x

[dacarman]

Is the newest PiCore 13 distro able to run accelerated graphics???

Last time I tested it (previous beta version), it was not able to load the required graphics modules properly, probably because of certain "CEC" dependencies.

Graphics modules (graphics-KERNEL) fails showing ELF errors and "vc4: Unknown symbols for cec_xxxxx...".
/dev/dri was not created, so SDL dependant programs can't be run.

[Juanito]

Have you tried again with the latest graphics-KERNEL extension?

What is the exact error message you get?

[dacarman]

Last time I tried previous beta version with the last graphics kernel extension with no luck...   

I didn't tried this distro and newer modules, so I was asking because I didn't see an update from Markus related to that fix needed, and it requires some time for me to compose all the needed steps to create the SD card, download modules and copy my test programs...    I did it several times with previous 13 versions until I understood that some modifications or additional modules are required to be included for 13 and its latest kernel, but those requirements were ever fullfilled in previous PiCore versions like 12, 11, etc. even in beta versions without significant problems.

The errors shown, as I said are the ones related to ELF and "vc4: Unknown symbols for cec_xxxxx"...   when the system is booting.

When I try to run a program which requires accelerated graphics it does not work showing that /dev/dri does not exists or SDL related fails because the libraries can't be loaded properly.

[dacarman]

I think the key is the missing CEC modules which Paul refers here:

http://forum.tinycorelinux.net/index.php/topic,24762.msg157850.html#msg157850

[Juanito]

I don't believe the appropriate 5.10.x-piCore-v7_modules.tar.xz file is available for the missing modules for piCore-13.0.3 (I might be wrong) so you'll need to either:

*wait until @bmarkus posts them
*use piCore-12.x where 3d acceleration works for armv6/armv7/aarch64

[dacarman]

Thanks you.

Yes, I'm using PiCore 12 for the moment, as it looks like those modules are a new requirement difficult to have ready.

Regards.

[jefferee]

tcpdump is missing one of its required dependencies,
ipv6-netfilter-5.10.16-piCore-v7.tcz (this is on a 3B+ board).