Core v14.0beta1

[CNK]

I rebuilt glibc and created rootfs_i486.gz - maybe you could test

http://tinycorelinux.net/14.x/x86/release_candidates/distribution_files/rootfs_i486.gz

Yep that's fixed it, I got a chance to boot the revised rootfs on my Cx486DX4 today and it worked.

RE rebuildfstab: I also tested that out earlier in TC 13.0beta1 on the 486. Comparing between the standard TC 13 rebuildfstab and the current version from the Git repo. The main limitation here isn't actually the 486 CPU, but the 16MB RAM (5-6MB left after the Linux kernel is loaded) which only works at all with a HDD install, a swap partition, and modifications to the tc-config script.

The system only has three partitions on one drive.

TC 13 rebuildfstab:

Code: [Select]

real 3m 31s
user 0m 3.79s
sys  0m 52.37s

Latest (2023-03-18) Git repo rebuildfstab:

Code: [Select]

real 0m 59.68s
user 0m 1.57s
sys  0m 16.02s

So yes, well done Rich, the speed improvements work on the slowest systems as well.

[Rich]

Hi CNK

... So yes, well done Rich, the speed improvements work on the slowest systems as well.

Thanks, though I would have hoped for somewhat lower execution times.
I wonder where the bottleneck is?
What's the clock speed of the CPU?
Are there any USB storage devices connected?
Could you attach copies of  /proc/partitions  and  /etc/fstab  please?

[CNK]

... So yes, well done Rich, the speed improvements work on the slowest systems as well.

Thanks, though I would have hoped for somewhat lower execution times.
I wonder where the bottleneck is?

Oh it's sure to be the RAM, it has to dive into swap space to do anything and the mid-90s laptop HDD that the swap partition lives on isn't quick. Plus because adding Tiny Core was a late change and I didn't want to mess with my existing MSDOS installation, the swap partition is at the end of the disk space, which is the worst place for it.

Note that even with almost everything disabled (including fstab generation at boot) TC 13 took over 3minutes to boot up itself. TC 14 actually took over 9minutes, but I may have messed up the file system when I accidentally booted without my modified version of tc-config and had to do a hard power off when it ran out of RAM, so some of that time might have been repairing/working-around that.

What's the clock speed of the CPU?

100MHz - very quick by 486 standards. BasicLinux, based on kernel v. 2.2, boots up in 16 seconds and runs as fast as you'd want. In part that might be because it has almost 15MB of RAM left after that much older/smaller kernel has loaded. A comparison with current OpenWrt would be interesting to do one day, because they turn off a lot more kernel features.

Are there any USB storage devices connected?
Could you attach copies of  /proc/partitions  and  /etc/fstab  please?

No USB anything, and although it'll be a while until I have time get files off it, from memory I can assure you that /etc/fstab recorded three partitons on only one drive, /dev/sda: one vfat (FAT16), one ext2, and one Linux swap partition.

[aus9]

hi GNUser

I re-read my post 40. basicfileperms ......was finding I was building as root. gutmensch advised me that my earlier builds, even I agree they are/were terrible, resolve owner issues easily if I build as root.

your change was new to me....and now that I have read your comments I accept I am going see that msg more often as I will still build as root. 
cheers

[Rich]

Hi CNK

... I wonder where the bottleneck is? ...
 ... Could you attach copies of  /proc/partitions  and  /etc/fstab  please?

Don't bother. Between a 100Mhz CPU and a system that needs to access swap to
do anything, I think that mystery is solved.

... the swap partition is at the end of the disk space, which is the worst place for it. ...

Swap is slow wherever it's placed. I'm not sure there would even be a noticeable
difference if the swap partition were move to "the best place for it".

[curaga]

A custom kernel could help a lot, if you're actually doing things on that system that is If it's just for fun, probably not worth the bother.

[jazzbiker]

Between a 100Mhz CPU and a system that needs to access swap to
do anything, I think that mystery is solved.

As my elder runs at almost the same frequency (something around 100 MHz) but have memory sufficient for executing rebuildfstab without swapping I've made some measurements.
I was testing HDD (IDE, 4GB, 4 partitions) and USB flash drive (8GB, 3 partitions, connected to USB1.1 port). I was comparing native rebuildfstab of TC12, rebuildfstab from rootfs_i486.gz by @Juanito and rebuildstab from core-scripts git repo (under TC14). Execution times vary depending on the number of partitions mounted, so there are too many cases and I will tell in brief about the worth one:
1. both HDD and USB flash drive connected.
2. Only one HDD partition mounted.

Competitors' results are:
1. TC12 native - 17.5 s
2. TC14 rootfs_i486.gz native - 11.5 s
3. TC14 rootfs_i486_gz rebuildstab from git repo - 9 s

@Rich, if I can make some tests which can help You to improve the performance I will gladly do.

Have a nice Core!

[GNUser]

Hi aus9.

gutmensch advised me that my earlier builds, even I agree they are/were terrible, resolve owner issues easily if I build as root.

That used to be true, as I discovered the hard way here (I maintain eiwd):
http://forum.tinycorelinux.net/index.php/topic,26077.msg167960.html#msg167960

With recent tweaks to submitqc it shouldn't matter much anymore how extension is built, because everything inside the final foo.tcz will be owned by root (root:root in general, root:staff in special case of startup scripts).

P.S. I use several of your extensions. They are all excellent and some of them are critical to my infrastructure (e.g., firmware-mediatek.tcz in my TCL-powered wireless router). Thank you.

[Rich]

Hi jazzbiker

... @Rich, if I can make some tests which can help You to improve the performance I will gladly do. ...

No need. Those numbers sound reasonable to me for hardware of that caliber.

By the way, I did my timing comparisons with only internal storage devices connected.
I felt connecting USB devices introduces too many timing variables depending on which
USB device you plug in and differences in USB hardware from one machine to another.

Even my old Sony Vaio (PCV-RS320) with IDE drive has respectable numbers:

Code: [Select]

tc@box:~$ time sudo ./rebuildfstab.devlist3
real    0m 0.94s
user    0m 0.04s
sys     0m 0.10s
tc@box:~$ time sudo ./rebuildfstab.devlist3
real    0m 0.23s
user    0m 0.06s
sys     0m 0.05s
tc@box:~$ time sudo ./rebuildfstab.devlist3
real    0m 0.41s
user    0m 0.04s
sys     0m 0.09sUSER  and  SYS  is basically the CPU doing real work running user and kernel code.
The  REAL  time includes wait times such as waiting for hardware to respond.

[CNK]

A custom kernel could help a lot, if you're actually doing things on that system that is If it's just for fun, probably not worth the bother.

Actually the only 486 that I really do things with has only 8MB RAM (but it's less damaged than the other one), and I discovered with TC 12 that 8MB wasn't enough to boot TC. But running modern Linux is indeed just for fun, BasicLinux does pretty much all I'd want. I can telnet into a modern computer from it to do things requiring encryption like HTTPS, which is the main reason you'd want to run modern software (other advantages are pretty much all drowned out by how much slower most modern software is).

In fact the internet is usually the only reason I ever upgrade software on anything (either accessing it, or avoiding getting hacked from it).

Thanks Jazzbiker for getting some timings from another 100MHz system (Pentium, I'm guessing, if it has USB).

[jazzbiker]

Pentium, I'm guessing, if it has USB

Yes, genuine Intel, "F00F Bug Inside"!

[adb014]

Its probably too late to do anything about it, but openssl version 1.1.1 will reach end of life on the 11 Sept 2023 (see https://www.openssl.org/news/secadv/20230322.txt) and no patches will be issues for free after that date.. Given that openssl has at least 5 or 6 major CVE per year, this is a real problem (I tend to update openssl to follow the CVE).. The packages in Tinycore should at least start move toward being linked against openssl 3.1.x

[Juanito]

OK, but that’s a separate issue to updating the base.