Re: Tiny Core v17.0 upgrade issues

[Stefann]

Small update…
Application was still running without crash after 3 days.
I got a bit worried….. I am sure the system is not stable, but appearantly I changed some detail such that the time to crash got extended.

Yesterday I restarted the application without serial read. In parallel I used a dedicated “crash program”. It reads the serial-over-usb with a buffer of only 2 bytes. That gave me 23500 reads/minute versus about 120 per minute with my applictqion. On top of that I fire an interrupt every 100us.

Bingo.. crash after 14 hours. It’s still not stable

@rich..
I had hard wired terminal  with gui up. However ist completely frozen. Control-alt-F1 or control-alt-F2 does nothing. So… no messages…

Today i spent time to hardware-built-in the terminal. So far it was blocking the hallway. I mounted it at the inside of the hallway cupboard. Made the keyboard “foldable”. This allows the terminal to be a permanent service setup. So…. No Kernel testing today. That will be tomorrow.

I was able to compile and built a kernel from source on my second system. It took about 3 hours.
I also compiled all modules. That took about 36 hours. Completely unnecessary as I only need the usb-serial module which I probably better compile als part of the kernel anyways.
But… I’m learning……

[Stefann]

Anyone has tips??

Monday I succeeded to make a "custom kernel" for TC17, linux-6.18.28
However... when I tested it today:
- It boots and gets to a terminal prompt which is responsive to linux commands
- but extensions are not loaded at boot.

Trying to load afterwards also fails, example:

Code: [Select]

tce-load -i /mnt/hda1/tce/optional/nano.tcz
gets me:
mount: can't setup loop device: No such device or address
Any reason why?

Note, how I created kernel:

Code: [Select]

1/ get files you need
On laptop:
- find download location on http://tinycorelinux.net/downloads.html
- download [version]/x86/release/src/kernel/linux-x.y.z-patched.tar.xz
- download [version]/x86/release/src/kernel/linux-x.y.z/config-x.y.z-tinycore
On tinycore:
- create toplevel directory that you want to use for kernel customization. Can have 1 top-level for all versions. Assume path to be [TC]
- cp above 2 files to [TC]

2/ goto your [TC] toplevel directory and prepare kernel make
- cd [TC]
- tar xvf linux-x.y.z-patched.tar.xz (this creates a linux-x.y.z directory)
- cp config-x.y.z-tinycore linux-x.y.z/.config
- cd linux-x.y.z

3/ make kernel image
- make clean
- make bzImage (this makes kernel image, takes 3 hrs on my 1GHz 2core machine)

4/ Install image, on main system:
- cp [TC]/linux-x.y.z/arch/x86/boot/bzImage /mnt/sda1/tce/boot/vmlinuzCUSTOM
- modify /mnt/sda1/tce/boot/extlinux/extlinux.conf to boot from vmlinuzCUSTOM
Should I have run "make mrproper" ?
or "make oldconfig"?
And what about core.gz. I used the core.gz that was made with linux-6.18.2?

[Juanito]

Before making your changes, use "make mrproper", copy the tinycore config to .config in the top level of the linux source and then "make oldconfig"

Before packing up the modules.gz initrd (or core.gz), you need to issue a depmod command so that the kernel know where to find the modules when it boots.

..something like:

Code: [Select]

sudo depmod -a -b /tmp/extract $KERNEL...assuming you have the initrd under /tmp/extract

[Stefann]

Hi Juanito,
1/ Thanks a lot!

2/ its a bit to fast.. could you (please please) explain a little bit more step-by-step?

What I understand from you:..... after I downloaded and unpacked the sources and have the .config:

Code: [Select]

cd ./linux-x.y.z
make mrproper
cp ../[downloaded config] ./.config
make oldconfig
Than I would expect...

Code: [Select]

make bzImage
cp bzImage  [bootdrive]/tce/boot/vmlinuz
At this moment, I just copied it as alternative vmlinuzCUSTOM to the existing vmlinuz in the same boot directory.
in that boot directory "core.gz" is already available.
--> so far so good...

but....
Do I really need to regenerate core.gz?
Existing core.gz is 6.18.2 while new bzImage is 6.18.28. does that hurt?
And IF I need to generate the core.gz: "how do I do that" It is NOT created with a make bzImage.

help is greatly appreciated.

[Juanito]

Ah - if you’re only changing something that’s compiled into the kernel then you shouldn’t need to regenerate core.gz/modules.gz.

In that case the steps you list should be fine.

If you’re using 6.12.28 you’ll need the core.gz/modules.gz that goes with it.

[Stefann]

update...

This morning an other crash after 12hrs
Application running without serial read
serial read in a "crash program" with accelerated calls: 23500loops per minute versus about 120/minute with my application

FINALLY managed to have "non blank terminal" at crash. But.... no messages....
Following guidance of @Rich:
- I had jumped out of flwm by CNTRL/ALT/F1 when system was still running.
- So system crashed with command line visible
- However: ZERO messages..
- So: linux just freezes with zero messages
Thanks @Rich

Following guidance of @Juanito:
- succeeded to create a vmlimuz from source that booted with full functionality
- adapted vmlinuz to include usb-serial in vmlinuz so no longer need usb-serial-6.18.2-tinycore.tcz
- also successful boot with full funciutonality and usb-serial support
Thanks @Juanito

I restarted the application without serial read AND dedicated crash program in parallel
-> this to confirm that my customer kernel also crashes

If this crashes I will modify usb-serial.c and check whether that brings improvement

[Stefann]

OK... What is happening???

vmlinuz from http://tinycorelinux.net/17.x/x86/release/ + usb-serial-6.18.2-tinycore.tcz
may-21: crash after 14hr
may-23: crash after 12hr

vmlinuz recompiled as custom kernel with usb-serial included in kernel
may-25: running for 48hr and still running......

WHY does the vmlinuz from download location crash 2 times in a row and does the regenerated kernel survive 4x longer?

===================================
Some comparison of file size & date:
vmlinuz from http://tinycorelinux.net/17.x/x86/release/
-rwxrw-r--    1 tc       staff      6087168 Feb 10 13:10 vmlinuz

vmlinuz recompiled as custom kernel with usb-serial included in kernel
-rw-rw-r--    1 tc       staff      6304256 May 23 08:15 vmlinuz17C2

Both are linux 6.18.2
For some reason the recompiled kernel is 217k bigger

I just recompiled the kernel without usb-serial to see whether that explains the file size difference;
-rw-r--r--    1 tc       staff      6287872 May 25 08:43 bzImage
==> so "no";  freshly compiled kernel without usb-serial included is 200k bigger than published kernel at download location

I checked timestamps to check on evidence that the kernel source on download location has a different version than the compiled vmlinuz on download location. I see no evidence for that. So... for all I can see I'm compiling my custom kernel from exactly the same source.

I'm working on a Via Eden processor. I compiled the kernel on a HP510 thin client with 1GHz dual core Via Eden processor. I'm running on a 500MHz single core 32bit Via Eden processor. So.. although it's the x86 instructions it's not an intel chip.
- Could the fact that I compile on a Via Eden processor explain the difference?
- The executable is 5% bigger. Is that a tell?

Anyway...
- I leave this running for 1 or 2 extra days "just to be sure"
- After that I will probably test the custom kernel without integrated usb-serial and test that with usb-serial-6.18.2-tinycore.tcz

All in all...... if this works
- than I basically have a solution.
- and I also basically do no longer have a bug-suspicion towards linux.
- I would have a suspicion towards "validity of published tinycore kernel for Via Eden Processor" but that's something I can live with. I can easily circumvent by generating my own kernel from published sources. My main objective "to stay current with linux versions" is perfectly served.

So... if things keep functional I will close this and move on with application work
..... but for now... keep testing.....

[Rich]

Hi Stefann

... I just recompiled the kernel without usb-serial to see whether that explains the file size difference;
-rw-r--r--    1 tc       staff      6287872 May 25 08:43 bzImage
==> so "no";  freshly compiled kernel without usb-serial included is 200k bigger than published kernel at download location

Did you use the original  config-6.18.2-tinycore  or did you run  make menuconfig
on your modified  .config  to switch USB from built in back to module?

[Stefann]

I did,..

Code: [Select]

Make mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make menuconfig
…. Change usb-serial from “module” to “yes”
… Save
… exit
Make bzImage
This morning, 2days later, I thought it to be good to see kernel size without integrated usb-serial so I did:

Code: [Select]

Make menuconfig
… change usb-serial back from “yes” to “module”
… save
… exit
Make bzImage
I will do a fresh run to be absolutely sure:

Code: [Select]

Make mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make bzImage

[Rich]

Hi Stefann

... I will do a fresh run to be absolutely sure:

Code: [Select]

Make mrproper
Cp “www.tinycorelinux.net/17.x/x86/release/src/kernel/linux-6.18.2/config-6.18.2-tinycore” .config
Make bzImage

That's exactly what I was getting at.

When selecting options in  make menuconfig , whether it's support for certain
hardware, compiling a driver as a module, or building it into the kernel, the
menuconfig  script is selecting other options required to support your choices
in the background.

However, reversing one of your choices does not necessarily cause the script
to unselect its additional choices, since they may be valid to select on their own.

[Stefann]

Hi @Rich,
Let me first say that I am very very happy with all your help and suggestions.
You have a very keen and detailed eye
I do my best, but its very easy to overlook some detail.
The whole issue is utterly "strange". I'm pretty sure the rootcause is an extreme minute detail.
So.. yeah... very helpful you get me hints and directions.

That's exactly what I was getting at.

Yeahh... That's How I did interpret your message.

When selecting options in  make menuconfig , whether it's support for certain
hardware, compiling a driver as a module, or building it into the kernel, the
menuconfig  script is selecting other options required to support your choices
in the background.

However, reversing one of your choices does not necessarily cause the script
to unselect its additional choices, since they may be valid to select on their own.

Thanks for that explanation. Makes a lot of sense.

Note, On the one hand it's quite annoying to have this issue. On the other hand it's quite fun to "learn things". To be honest it's quite cool to say "I'm compiling my own linux kernel". Learning the internals of TinyCore is much more boring if there is no issue to crack.

Anyway........... progress.............
I did a recompile of the kernel with "make mr proper" and "copy config from download location to .config". Compilation was a 4hr job on my HP510 1GHz 2core machine.
No new insights. Kernel has exactly the same size:
-rw-r--r--    1 tc       staff      6287872 May 25 20:06 bzImage

My current intention on going forward:
1/ keep this running for an other 36hrs to a total of 4 full days.
In principle the configuration with a self-compiled kernel is a fully acceptable solution.
- It assures I have a recent linux
- Unlike "not use blocking read in my application" it is a solutions without hidden deficiencies.
So... I want to give this an overkill of runtime to be very very sure this works as a solution.
(Note,... and IF it works I may still abandon the blocking reads, but as a simplification, not as a necessity)

2/ Than test the just generated kernel Excluding the usb-serial driver together with usb-serial-6.18.2-tinycore.tcz from TC server
IF that crashes than the issue is nailed again tot usb-serial driver. In that case I will compile the driver myself and test again.
If it keeps running I will probably stop investigating and use the self compiled kernel as a solution.
Probably do some additional tests when TC17.1 gets released

[Juanito]

Don’t forget that after copying the tinycore config to .config you need to make oldconfig

[Stefann]

Don’t forget that after copying the tinycore config to .config you need to make oldconfig

Ah.... I did not do that...

Anyway... I have 36hrs available on my 2nd system as I keep my 1st system testing for an other 36hrs.
So I started a kernel make again:

Code: [Select]

tc@hp510:/krubo/work/TC/linux-6.18.2$ make mrproper
tc@hp510:/krubo/work/TC/linux-6.18.2$ cp ../config-6.18.2-tinycore ./.config
tc@hp510:/krubo/work/TC/linux-6.18.2$ make oldconfig
tc@hp510:/krubo/work/TC/linux-6.18.2$ make bzImageI did not get any questions from "make oldconfig"
This will again take 4hrs by which time I will be sleeping.... so... results to be expected tomorrow.

But...... "not doing the make oldconfig"...
Could that potentially explain why the kernel I made without "make oldconfig" is running already 60hrs without crash??
While the kernel I downloaded from the tinycore download area did crash 2x in a row, after 14hrs and after 12hrs?

[Rich]

Hi Stefann
I'm not certain of this and may be misremembering.
I think the new kernel is built on the previous version of Tinycore.
If that's the case, it might be built with the previous version of GCC.
Newer versions of GCC typically build larger executables.

Maybe Juanito and/or Paul_123 can comment.

[Stefann]

Don’t forget that after copying the tinycore config to .config you need to make oldconfig

OK.. I again made a new kernel.
No change however, same file size as without "make oldconfig":
-rw-r--r--    1 tc       staff      6287872 May 26 01:41 bzImage

Hi Stefann
I'm not certain of this and may be misremembering.
I think the new kernel is built on the previous version of Tinycore.
If that's the case, it might be built with the previous version of GCC.
Newer versions of GCC typically build larger executables.

OK.....
Indeed at this moment I'm compiling on my 2nd system. This 2nd system runs TC17 with vmlinuz & core.gz from download location without a problem. So.. yes... at this moment I'm compiling with TC17. Not with TC16.

In principle I could bring my 2nd system to TC15 or TC16 to test compiling under older gcc. That is however quite some effort as I would also need to get back to older tce/optional directory to make sure I have older tcz files. Not sure I want to put in the time for that.

I DID however make a bzImage for TC17.1 release candidate (linux 6.18.28) some time ago:
-rw-r--r--    1 tc       staff      6316544 May 22 09:37 bzImage

I can compare this to TC17.1 download location http://tinycorelinux.net/17.x/x86/release_candidates/tc17.1/
bzImage                                            08-May-2026 18:33             6111744

So...
- published TC17.1 bzImage is generated on may-8 so I would expect generated with TC17.0 (linux 6.18.2)
- published TC17.1 bzImage is 14kB bigger than the vmlinuz on TC17.0 download location
- published TC17.1 bzImage is 20k smaller than the bzImage I generated under TC17.0 configuration.

Could we be looking at something of a "cross compile issue"?
To keep in mind: I'm compiling on a hp510 thin client with Via Eden 2core 1GHz 64bit cpu running 32bit TC17.0.
Via Eden has x86 commandset but is different brand than intel.

Going forward..
- I will just see whether the self compiled kernel will indeed be crash free. I give it 24hr additional testing towards 4 full days
- and I will check whether self compiled kernel "without integrated usb-serial" using usb-serial-6.18.2-tinycore.tcz from TC-website will crash
>> if that crashes I can see whether I can compile usb-serial-6.18.2-tinycore.tcz myself and test with vmlinuz from website.

But anyways... assuming current configuration holds I will soon close this thread and start fully using my self generated kernel.

Than... when TC17.1 gets released for beta do some good additional testing
- test published kernel
- test self generated kernel
That will probably be a better moment in time to hunt down reason for different behavior/filesize of published versus self generated kernel.