Tiny Core Base > piCore Final Releases
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:
--- Quote ----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)
--- End quote ---
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version