Recent Posts

11

TCB Talk / Re: Tiny Core v17.0 upgrade issues

« Last post by Stefann on April 24, 2026, 03:49:40 PM »

try upgrade tc 16 ,maybe can shrink this problem

I thought about that but that would not help me.
Just to "not have crashes" I could simply stay on TC15. But.... Than I would miss out on upgrades.
Getting upgrades is the whole point of getting to TC to begin with. I started on DSL in 2008 but DSL quickly stopped doing upgrades.
2 years ago I really had to move to a newer OS. Without upgrades I had no https and missed lots of libraries on gcc, php, python.
So... getting OS updates is important.
A stepping stone on TC16 would not give other insights.
Only when its clear which component has the error it makes sense to figure out whether that component broke from 15 to 16 or from 16 to 17.

12

TCB Talk / Re: Tiny Core v17.0 upgrade issues

« Last post by Stefann on April 24, 2026, 03:44:18 PM »

Hi,
I appreciate a lot that you are reading my reports, I can sure use any help I'm getting.

Yes,...
I'm opening the file descriptor at the start of my program and than never close it:

Code: [Select]

fd = open("/dev/ttyUSB0", O_RDWR);
My home automation program (originally) simply keeps reading from it.
Before each read it did checks whether there was data with a select command.
The fd remains the same, that never changes, so as far as I know nothing increments and reaches a limit

Code: [Select]

call this as part of forever loop:
{ static char buf[BUFSIZE+1];
   fd_set fd_check;   
   struct timeval wait = {0};
 
  FD_ZERO(&fd_check);
  FD_SET(fd, &fd_check);
  select(fd+1, &fd_check, NULL, NULL, &wait);
  if (FD_ISSET(fd, &fd_check)  )
  { j = read(fd, &buf[i], BUFSIZE-i);
    ... process results...
   }
   other commands...
}


So.. I think in principle THIS should work, and actually it does on TC15.

However...
You are very right that "if I would open other pipes without closing" I could get in trouble.
Yes.. it's not very safely programmed, it does not include the range check.

I never intentionally keep opening files without closing when I no longer need them.
What I meant is that I open "this specific file" and keep reading without ever closing.
In itself "that is not strange", I'm actively using it.
But if "it collects some garbage over time", it never gets a fresh start.

Anyway, last experiment was to "close & reopen" every 15mins. Its seems that that about doubled the time to crash but it still crashes.

Thanks for the input, I can include a logging on number of fd's when I do a next compilation.
"never intentionally" is different from "absolutely sure I did not"
For now I keep it running. Its 13 hrs down the road now... And it's almost bedtime here. Tomorrow morning I will know whether it at least passed the "15hr average crash milestone"

13

TCB Talk / Re: Upgrading TC 14.0 to 17.0?

« Last post by Rich on April 24, 2026, 01:34:11 PM »

Hi nurbles

... So I guess I can just copy the two primary OS files, reboot and update the very few extensions I use afterward.

Yes. Then just run:

Code: [Select]

update-everythingand it will update all of your extensions.

14

TCB Talk / Re: Upgrading TC 14.0 to 17.0?

« Last post by nurbles on April 24, 2026, 11:18:32 AM »

Thanks for the link!  Upgrading the extensions was always part of the plan, but I had thought I could do that after booting the upgraded OS.

After running the commands on the page you linked to look for kernel-specific extensions, I found that I have none at all.  Of course, that was after I discovered that my regular user account couldn't even see the directory being searched.  But a quick 'sudo -i' and I was able to execute the search commands.  Still, no results.  So I guess I can just copy the two primary OS files, reboot and update the very few extensions I use afterward.

15

TCB Talk / Re: Upgrading TC 14.0 to 17.0?

« Last post by Rich on April 24, 2026, 09:49:51 AM »

Hi nurbles
You should also update your extensions.
https://forum.tinycorelinux.net/index.php?topic=28008.msg181492#msg181492

16

TCB Talk / Re: Tiny Core v17.0 upgrade issues

« Last post by Rich on April 24, 2026, 09:45:18 AM »

Hi Stefann

... I got a tip from my brother that "SELECT" is a quite complicated kernel call.
I'm using SELECT to check that the pipe is ready for read but I can just as well call read from it in nonblocking mode without checking.
So... I now changed that...
- removed the SELECT
- read in non-blocking mode ...

You mentioned in a previous post you were opening files without
closing them. If you were using those file descriptors with select(),
that could be a problem:

Code: [Select]

C_Programs/AutoCursor/AutoCursor.c:     int fdmax=0;                                    // Highest file descriptor select() should monitor.
C_Programs/AutoCursor/AutoCursor.c:             select((fdmax + 1), &Dcursor, NULL, NULL, NULL);Select is limited to somewhere around 1024 file descriptors. If you keep
opening the same file over and over again, you will eventually reach
that limit and bad things things will happen. You can test for this fairly
easily. When you open a file for select() to monitor, compare the file
descriptor to FD_SETSIZE:

Code: [Select]

if(file_descriptor >= FD_SETSIZE)
{
     print error message
     exit program
}

17

TCB Talk / Re: Tiny Core v17.0 upgrade issues

« Last post by Zhe on April 24, 2026, 09:01:48 AM »

try upgrade tc 16 ,maybe can shrink this problem

18

TCB Talk / Upgrading TC 14.0 to 17.0?

« Last post by nurbles on April 24, 2026, 09:00:40 AM »

I've read that all I need to do is update the core.gz and vmlinuz files to upgrade, but I've also found a thread (https://forum.tinycorelinux.net/index.php?topic=28078.0) that indicates there were some issues going from TC 15 -> 17.  Are there any step-by-step upgrade guides available, especially for jumping multiple major version numbers?  Thanks!

Oh, FWIW, this is for embedded, headless devices in locations that update very rarely.  That's why we are jumping some many versions at once.  If necessary or significantly better (safer?) we can install clean and recreate all of our configuration, but would prefer to avoid that, if possible.  Thanks again for any hints, tips, pointers and links that may help me.  (smile)

Oh, normally these devices cannot 'see' the internet, but I can connect my development system if that is needed for the update. Then I can replicate the working image for other devices.

19

TCB Talk / Re: Tiny Core v17.0 upgrade issues

« Last post by Stefann on April 24, 2026, 02:29:44 AM »

Sad.... an other crash this night at 1:30 am; after 33.5 hours

So.....
On TC17 crash after 33.5 hours if constantly reading reading from serial-over-usb port AND close/open filedescriptor every 15mins.

But....
2 days ago I concluded that running without reading serial-over-usb was crash-free as I manually stopped after 30hr of crash-free run.
>> that conclusion may be premature

Still..
WITH constant reading of serial-over-usb crash is normally in about 15hrs, and always within 24 hours.
So... although there is variation... it still looks like "altering settings of serial-over-usb" influences the behavior.

I got a tip from my brother that "SELECT" is a quite complicated kernel call.
I'm using SELECT to check that the pipe is ready for read but I can just as well call read from it in nonblocking mode without checking.
So... I now changed that...
- removed the SELECT
- read in non-blocking mode
I also made using read, select, 15min_close/open configurable by a runtime settable variable such that I can test different configurations without recompile (to exclude impact of compilation on results)

Started at 8:22 am:

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- new compiled executable with runtime configurable serial read modes
- run application with non-blocking read without SELECT
- "every second 812byte read from /dev/ttyUSB0; baudrate 11520" from /dev/ttyUSB0


Recap of results so far:

TC15:
- including kext: usb-serial-6.6.8-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- no crash over multiple month

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- 4..6x tested, always crashes, mostly after about 15hrs; always within 24hrs

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- SAME application, NO recompile
- run application with disabled read from /dev/ttyUSB0 by configuration constant
- 1x tested, NO CRASH after 30hrs >> I thought this was good but as next config crashed after 33.5hrs I may not have been running long enough

TC17:
- including kext: usb-serial-6.18.2-tinycore.tcz
- include every 15 minute close/open file descriptor for /dev/ttyUSB0
- recompile full application
- run application with "every second 812byte read from /dev/ttyUSB0; baudrate 11520"
- 1x tested, crash after 33.5hrs

20

General TC Talk / Re: script that generates .tree files

« Last post by Rich on April 23, 2026, 02:57:10 PM »

Hi GNUser

Here's final tally of busybox ash vs. busybox awk vs. C++ implementations of treegen. All three implementations parse .dep files present on the local mirror (without using network/wget):

                                      busybox ash     busybox awk          C++
time to generate labwc-dev.tcz.tree:    11 sec          0.43 sec         0.06 sec
time to generate vlc-dev.tcz.tree:      49 sec          1.86 sec         0.31 sec

...

I decided to try my hand at a busybox ash version.

Using your busybox awk as a benchmark, I got:

Code: [Select]

tc@E310:~/TreeGen$ time ./treegen.awk vlc-dev.tcz > vlc-dev.tcz.tree2
real    0m 8.49s
user    0m 3.56s
sys     0m 4.92s
Using my busybox ash version, I got:

Code: [Select]

tc@E310:~/TreeGen$ time ./TreeGen.sh vlc-dev
6.25
real    0m 6.27s
user    0m 3.71s
sys     0m 2.52s
That surprised me, but not as much as this did:

Code: [Select]

tc@E310:~/TreeGen$ ls -l vlc*
-rw-r--r-- 1 tc staff 1879760 Apr 23 00:56 vlc-dev.tcz.tree <------ ash version
-rw-r--r-- 1 tc staff 1839796 Mar 30 13:48 vlc-dev.tcz.tree.bak <-- repo version
-rw-r--r-- 1 tc staff 1839795 Apr 22 22:53 vlc-dev.tcz.tree2 <----- awk versionThe repo versio is 1 byte longer than yours. It has an extra newline at the end of the file.
But mine is almost 40,000 bytes larger.

And about 900 lines longer:

Code: [Select]

tc@E310:~/TreeGen$ wc -l vlc-dev.tcz.tree*
  41437 vlc-dev.tcz.tree <------ ash version
  40528 vlc-dev.tcz.tree.bak <-- repo version
  40527 vlc-dev.tcz.tree2 <----- awk version
At first I figured there was a bug in my version because yours agreed with the repo version.
Then I found this:

Repo version:

Code: [Select]

   3498                   libsndfile-dev.tcz
   3499                      libsndfile.tcz
   3500                         flac.tcz
   3501                            libogg.tcz
   3502                         libvorbis.tcz
   3503                            libogg.tcz
   3504                         opus.tcz
   3505                         libmpg123.tcz
   3506                         lame.tcz
   3507                      flac-dev.tcz
   3508                      libvorbis-dev.tcz   
   3509                   libbluetooth-dev.tcz
My version:

Code: [Select]

   3498                   libsndfile-dev.tcz
   3499                      libsndfile.tcz
   3500                         flac.tcz
   3501                            libogg.tcz
   3502                         libvorbis.tcz
   3503                            libogg.tcz
   3504                         opus.tcz
   3505                         libmpg123.tcz
   3506                         lame.tcz
   3507                      flac-dev.tcz
   3508                         flac.tcz
   3509                            libogg.tcz
   3510                         libogg-dev.tcz
   3511                            libogg.tcz
   3512                      libvorbis-dev.tcz
   3513                         libvorbis.tcz
   3514                            libogg.tcz
   3515                         libogg-dev.tcz
   3516                            libogg.tcz
   3517                   libbluetooth-dev.tcz
The C++ and awk versions are not parsing flac-dev.tcz.dep and libvorbis-dev.tcz.dep

Here's the cause:

Code: [Select]

tc@E310:~/TreeGen$ grep " " DepFiles/libsndfile-dev.tcz.dep | tr " " "_"
flac-dev.tcz_
libvorbis-dev.tcz___The trailing spaces on those 2 entries are tripping up the C++ and awk programs.

Checking the rest of the .dep files related to vlc-dev turn up this:

Code: [Select]

tc@E310:~/TreeGen$ grep " " DepFiles/* | tr " " "_"
DepFiles/acl.tcz.dep:_
DepFiles/libsane.tcz.dep:libavahi.tcz_____
DepFiles/libsndfile-dev.tcz.dep:flac-dev.tcz_
DepFiles/libsndfile-dev.tcz.dep:libvorbis-dev.tcz___
DepFiles/libsndfile.tcz.dep:libmpg123.tcz_
DepFiles/sane-dev.tcz.dep:avahi-dev.tcz__
DepFiles/taglib-dev.tcz.dep:taglib.tcz___________________________________There are a handful of entries with trailing spaces.

So running treegen.awk against libsndfile-dev.tcz:

Code: [Select]

tc@E310:~/TreeGen$ ./treegen.awk libsndfile-dev.tcz
libsndfile-dev.tcz
   libsndfile.tcz
      flac.tcz
         libogg.tcz
      libvorbis.tcz
         libogg.tcz
      opus.tcz
      libmpg123.tcz
      lame.tcz
   flac-dev.tcz
   libvorbis-dev.tczIt reports flac-dev.tcz and libvorbis-dev.tcz have no dependencies.

Running these commands suggestes they do:

Code: [Select]

tc@E310:~/TreeGen$ ./treegen.awk flac-dev.tcz
flac-dev.tcz
   flac.tcz
      libogg.tcz
   libogg-dev.tcz
      libogg.tcz
tc@E310:~/TreeGen$ ./treegen.awk libvorbis-dev.tcz
libvorbis-dev.tcz
   libvorbis.tcz
      libogg.tcz
   libogg-dev.tcz
      libogg.tcz
I've attached my version of TreeGen.sh.

The only variables you need to adjust are kernel version and
path to your local repo.

Code: [Select]

Kernel="6.18.2-tinycore64"
Repo="DepFiles/"
Run the program like this:

Code: [Select]

./TreeGen.sh FilenameThe script adds .tcz automatically if you omit it.
The script automatically saves results to Filename.tcz.tree in
the current directory.