Tiny Core Linux
Tiny Core Base => TCB News => Release Candidate Testing => Topic started by: Juanito on March 06, 2023, 06:09:49 AM
-
Team Tiny Core is pleased to announce that Tiny Core 14.0 Beta1 is available for public testing:
http://repo.tinycorelinux.net/14.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/14.x/x86_64/release_candidates/distribution_files
This is an beta level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.
We appreciate testing and feedback.
Changelog for 14.0 Beta1:
* kernel updated to 6.1.2
* glibc updated to 2.36
* gcc updated to 12.2.0
* binutils updated to 2.39
* e2fsprogs base libs/apps updated to 1.46.5
* util-linux base libs/apps updated to 2.38.1
* busybox updated to 1.36.0
* tce: allow script to exit normally without stdout from bdantas
* autologin: Remove unneeded lines from nick65go
* filetool.sh: having colors from alphons
* rebuildfstab: remove relatime, it has been the default since 2.6.30
* rebuildfstab: small speed optimization
* rebuildfstab: reorder for findutils find warning
* tce-load: add to install if extension is downloaded from aswjh
* provides.sh: backup path patch from CNK
* depends-on.sh: various from rarost, bdantas
Note:
* la files have been removed from *-dev extensions (thanks to @Rich)
* intel hd4400 graphics fails with the modesetting driver in x86
-
Thanks, maybe also the /usr/bin/select patch (attached) could be approved. It is just a tiny change for tce-ab to list 20 rows/screen instead of 15.
-
Could you submit it to tc git please?
-
Added that patch, thanks.
-
Added that patch, thanks.
Thank you too; because I just made today an account on github, but I do not know to use git to submit patches, or if they are named pull-request.
-
in /etc/init.d/tc-config, line 657: /sbin/loadcpufreq 2>/dev/null &
in https://github.com/tinycorelinux/tc-misc/blob/master/loadcpufreq.c (https://github.com/tinycorelinux/tc-misc/blob/master/loadcpufreq.c)
it tries to load specific CPU drivers, like: speedstep-ich, powernow-k6, powernow-k7, powernow-k8, longhaul, longrun
in /lib/modules/6.1.2-tinycore64/kernel/drivers/cpufreq is only powernow-k8.ko.gz
So in year 2023, for TC14 final, unfortunately the kernel 6.1.2 does not have anymore the old CPU drivers; only powernow-k8.ko.gz
also, maybe is missing the case for amd_freq_sensitivity.ko.gz (!?).
Maybe we could just force all like:
/sbin/modprobe acpi-cpufreq powernow-k8 amd_freq_sensitivityand the kernel is smart enough to load only what is needs.
-
Thanks, maybe also the /usr/bin/select patch (attached) could be approved. It is just a tiny change for tce-ab to list 20 rows/screen instead of 15.
This is too long for the default aterm terminal window size of 80x24 characters. Testing in TC 13, although all the entries are visible, it scrolls down below the blank line at the top, and this causes the starting position of the text to change when there are fewer entries on the list (eg. when you get to the last page of results). More annoyingly, on slow computers (or slow Telnet/SSH/serial connections) it causes extra flickering as the window scrolls down one line each time the list is redrawn.
-
Hi
Apps GUI claimed I needed updates for eiwd and some more but got "failed" error so then I did
tc@box:/mnt/sda3/tce/optional$ rm -rf eiwd* iwd* wifi-manager*
tc@box:/mnt/sda3/tce/optional$ tce-load -w wifi-manager
wifi-manager.tcz.dep OK
eiwd.tcz.dep OK
Downloading: eiwd.tcz
Connecting to repo.tinycorelinux.net (128.127.66.77:80)
saving to 'eiwd.tcz'
eiwd.tcz 100% |******************************************************************************| 600k 0:00:00 ETA
'eiwd.tcz' saved
eiwd.tcz: FAILED
md5sum: WARNING: 1 of 1 computed checksums did NOT match
Error on eiwd.tcz
I am not using a mirror in case its a server midnight run issue, sorry if I am too impatient
-
Hi aus9
md5.txt file corrected. Try again.
-
Rich
all good now thanks
-
[This is too long for the default aterm terminal window size of 80x24 characters. Testing in TC 13, although all the entries are visible, it scrolls down below the blank line at the top, and this causes the starting position of the text to change when there are fewer entries on the list (eg. when you get to the last page of results). More annoyingly, on slow computers (or slow Telnet/SSH/serial connections) it causes extra flickering as the window scrolls down one line each time the list is redrawn.
The idea is to see "as many as possible" tcz/screen. I did not know that exist (and are used today) terminals of 24 rows.
Anyway, there are still two empty lines in the list, one at top, one at bottom, generated by "echo" commands in the script, which could be also removed.
I obey the majority /democracy. If I am minority, then so be it. Maybe you want to "enhance" the script to check for tty rows.
EDIT: I aterm (so under X server) I can change the resolution and have a lot more of rows. In console / terminal I have 25 rows normally. If radeon console driver is loaded I have also a lot of rows. IMMV.
-
Maybe we could just force all like:
/sbin/modprobe acpi-cpufreq powernow-k8 amd_freq_sensitivityand the kernel is smart enough to load only what is needs.
Most of those modules are for 32-bit cpus, so they aren't present on 64-bit. Loading everything would work, but it may take some extra time and print a message in dmesg that there is no such hardware.
nick65go, do you want to post a new patch that uses the maximum that fits into default aterm, or do I revert?
-
nick65go, do you want to post a new patch that uses the maximum that fits into default aterm, or do I revert?
please revert it.
-
I eliminated the 3 empty rows (two in top, one in bottom), and n=next and p=previous are OK; tested on rows=60 in Xorg.
--- ./select.orig
+++ /usr/bin/select
@@ -13 +13 @@
-awk -v title="$1" -v offset="$OFFSET" -v answer="/tmp/select.ans" '
+awk -v title="$1" -v offset="$OFFSET" -v answer="/tmp/select.ans" -v r="$(expr `stty size | cut -d" " -f1` - 2)" '
@@ -33,2 +33,2 @@
- printf "\n%s\n\n", title
- for (l=1; l<=15; l++) {
+ printf "%s\n", title
+ for (l=1; l<=r ; l++) {
@@ -38,2 +38,2 @@
- printf "\nEnter selection ( 1 - %s ) or (q)uit", NR
- if ( NR > 15 ) printf ", (n)ext, (p)revious: "
+ printf "Enter selection ( 1 - %s ) or (q)uit", NR
+ if ( NR > r ) printf ", (n)ext, (p)revious: "
@@ -44,2 +44,2 @@
- if ( j > 15 )
- j = j - 30
+ if ( j > r )
+ j = j - r * 2
@@ -52 +52 @@
- j = j - 15
+ j = j - r
@@ -56 +56 @@
- if (selection+0 < 1 || selection+0 > NR ) j = j - 15
+ if (selection+0 < 1 || selection+0 > NR ) j = j - r
-
Applied. Please use -U (not -U0) in the future, it helps if it's not an exact match (someone else also worked on it, etc).
-
Hi Rich another md5 mismatch
rm -rf submitqc*
tc@box:~/1builds/optional$ tce-load -w submitqc
submitqc.tcz.dep OK
Downloading: submitqc.tcz
Connecting to repo.tinycorelinux.net (128.127.66.77:80)
saving to 'submitqc.tcz'
submitqc.tcz 100% |********************************| 24576 0:00:00 ETA
'submitqc.tcz' saved
submitqc.tcz: FAILED
md5sum: WARNING: 1 of 1 computed checksums did NOT match
Error on submitqc.tcz
-
Hi aus9
MD5 fixed.
-
Hi Rich
all good now
-
Hi Rich
tce-load -i wbar
chown: warning: '.' should be ':': 'root.staff'
wbar.tcz: OK
ls -al /usr/local/tce.installed/wbar
-rwxr-xr-x 1 tc staff 74 Nov 6 2012 /usr/local/tce.installed/wbar
exit to prompt to load a basic desktop and see multiple lines of that chown warning
edit.....I had interference from my ~./X.d script that does stuff
flwm and hackedbox wbar appears correctly
but my updated feh appears but needs a new exec line
edit nope....a simple bork unless there is an image in your home dir
-
Hi aus9
... all good now
Please update your copy for a bug fix.
-
hi Rich
submitqc updated thanks
-
It's not the base, but anyway...
gtk-icon-theme-cache has been factored out of gtk2/gtk3 into a separate extension, so that adwaita-icon-theme does not depend on gtk3, which resulted in gtk2 apps loading gtk3 via adwaita-icon-theme.
-
so that adwaita-icon-theme does not depend on gtk3, which resulted in gtk2 apps loading gtk3 via adwaita-icon-theme.
Oh YES! Thanks. For too long time gtk2 apps loaded gtk3 libs.
Maybe something similar can be done about a few of icu*.tcz versions loaded simultaneously for the same one apps.
-
The icu issue is a matter of recompiling an app against the latest version of icu in the repo - I try not to create new icu extensions unless forced to do so.
-
Hi Rich
Juanito above mentions new TCE for gtk-icon-theme-cache
one of my GUI builds has a dep of hicolor-icon-theme and has tce.install scripts that attempts
gtk-update-icon-cache -q -f -t /usr/local/share/icons/hicolor
Should this have been shorter ....target /usr/local/share/icons?
Should I delete that install script entirely and just mention it in the info file?
I did a quick check of pending/past 14x submissions only gives me feh as affected in request
####
I am aware not everyone loads TCE in their boot list....so I was attempting to automate icon cache update.
Those members not relying on a cascading menu or GUI file managers may not appreciate my bloat?
-
Although it's not strictly necessary, when icons are added by an extension, running gtk-update-icon-cache will make the search for icons quicker.
The command gtk-update-icon-cache should be run on the directory where the icons are added, for example, /usr/local/share/icons/hicolor.
Following the removal of gtk-update-icon-cache from gtk2/gtk3, some apps will needed the extension gtk-update-icon-cache to be added as a dependency in order to be able to update the icon cache.
-
gtk-update-icon-cache.tcz
Description: con theme caching
it is missing an "i" for icon <-- con ;)
-
Hi Rich
when you get a chance I think I found a missing dep due to gtk icon cache....not sure if you or others have had a chance to start checking all or if I should report.....anyhow glade
http://tinycorelinux.net/14.x/x86_64/tcz/glade.tcz.dep
has a tce.install script for icon cache updating
and I have deliberately not loaded feh to try and catch them without peeking into each non-zero install script that I might load varying TCEs from time to time
-
I forgot to mention that I have submitted an update for feh....brain still foggy.
hicolor-icon-theme appears to be missing the new dep.
2) and I have only just twigged something. A number of packages that landed prior to submitqc bug fix....have install script as tc:staff
I am not alone here. ;)
but if my packages or other members packages are in their boot list....then the install script for Xlibs....takes care of that old bug
and changes to root:staff 775
-
Hi aus9
... when you get a chance I think I found a missing dep due to gtk icon cache....not sure if you or others have had a chance to start checking all or if I should report.....anyhow glade
http://tinycorelinux.net/14.x/x86_64/tcz/glade.tcz.dep
has a tce.install script for icon cache updating ...
There are some extensions that call gtk-update-icon-cache for their own icons.
Those extensions have been tracked down and will be fixed.
... hicolor-icon-theme appears to be missing the new dep. ...
No, it is not. hicolor-icon-theme.tcz is currently a dependency of gtk-update-icon-cache.tcz.
However, that may change.
-
Hi Rich
if adwaita-icon-theme pulls in gtk-update-icon-cache then it would also pull in hicolor-icon-theme?
-
I just tested TC 14.0beta1 on an old PC with a Cx486DX4 CPU and booting fails when starting init with an "invalid opcode" error in ld-linux.so.2.
My previous installation of TC 13.0beta1, done the same way, still boots
successfully. In fact I'm posting with it in elinks now.
Unfortunately I won't have time to test on other systems such as my Pentium 1 for a few days, and I probably won't have time/energy to reply on the forum for about a day after now either.
-
Hmm - I compiled both with a uname_hack forcing to i486 and -march=i486 - let me double-check
-
Unfortunately TC14 release_candidates/distribution_files fail to load on my old Pentium MMX box reporting "Attempted to kill init! exit code 0x00000004". TC12 works fine on this box.
-
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
-
There are some extensions that call gtk-update-icon-cache for their own icons.
Those extensions have been tracked down and will be fixed.
Hopefully done
-
I rebuilt glibc and created rootfs_i486.gz - maybe you could test
Thanks, Juanito! Core14 loads fine.
total used free shared buff/cache available
Mem: 54076 6372 21452 19484 26252 24616
Swap: 262076 0 262076
I may have missed something in the discussion on rebuildfstab, but on my ancient box I have the feeling that rebuildfstab is much faster. Is it new version by @Rich?
Thank You very much!
Maybe dmesg will be of interest.
Best regards!
-
It’s a newer version of rebuildfstab than 13.x, but not the very latest version - I’ll update it with the next version of 14.x
-
Hi aus9
if adwaita-icon-theme pulls in gtk-update-icon-cache then it would also pull in hicolor-icon-theme?
Yes.
-
Hi Rich
thanks
Hi Juanito
Thanks heaps for taking pity on me....again....and taking time out to update meson when I know you have other things to do.
Some of my sway related packages complains about old meson and others about python3.6
I was planning to try out a ~/local/ install showing up at mesonbuild.com but my coding skills are still poor.
No need to reply to my bodge attempt sent by pm thanks. That did actually work for seatd and borked for wlroots
once again thanks and sorry for drifting off TCB topic
-
Hi GNUser
I am confused again after Apps update for submitqc...I have
submitqc: icewm.tcz file and directory ownership/permissions follow wiki recommendations?
squashfs root dir ownership not tc:staff. Will rebuild squashfs to fix
I thought we were going with root:staff?
when I look at the last output I see
/tmp/submitqc/basicfileperms
and I think this was once something like tce.install changed...while basicfileperms is a bit vague for me
sorry if I have not read something...again
-
It would be nice to adjust http://tinycorelinux.net/14.x/x86/tcz/tcc.tcz.dep to match an actual kernel version:
sed -i 's/5.15/6.1/' tcc.tcz.dep
Regards!
-
Hi aus9. root:staff is for startup script and tce.installed directory, tc:staff on squashfs's root dir, root:root for everything else.
I got root:staff and root:root from wiki recommendations. tc:staff on squashfs's root dir is not specifically mentioned but is seen on vast majority of repo's extensions, including all of Juanito's extensions.
-
Hi aus9. Just two more thoughts for completeness's sake:
1. Inspecting extensions
To inspect ownerships and permissions inside an extension, don't extract it. When contents are extracted and written to your drive (or to your RAM), ownerships and permissions can change. To inspect an extension, look inside it without extracting it, like this:
unsquashfs -lls foo.tczTo see ownership and permissions of root directory of all your loaded extensions, do:
ls -l /tmp/tcloop
2. Flexibility of the extension system
TCL is very flexible and forgiving when it comes to ownerships and permissions in extensions. For example, wiki recommends root:staff 775 for startup scripts, but submitqc was forcing tc:staff 755 for a long time without any problems. Also, wiki recommends root:root for most directories and files, but I've seen extensions where everything is owned by tc:staff (or 1000:staff in the case of some of my old extensions) and they work just fine. Furthermore, most extensions have tc:staff ownership of squashfs-root directory, but you'll also see root:root (or 1000:staff in the case of some of my old extensions) and it makes little difference.
IMHO the job of submitqc should be twofold: 1. correct obvious errors (most important) and 2. ensure conventions and wiki recommendations are followed (less important, but still a nice service and cosmetically desirable).
[Edit]: Fixed typo, changed 1001:staff to 1000:staff. Rich
-
Hi jazzbiker
It would be nice to adjust http://tinycorelinux.net/14.x/x86/tcz/tcc.tcz.dep to match an actual kernel version: ...
Fixed. :)
-
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:
real 3m 31s
user 0m 3.79s
sys 0m 52.37s
Latest (2023-03-18) Git repo rebuildfstab:
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.
-
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?
-
... 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 (http://distro.ibiblio.org/baslinux/), 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.
-
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. ;D
cheers
-
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".
-
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.
-
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!
-
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.
-
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:
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.
-
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).
-
Pentium, I'm guessing, if it has USB
Yes, genuine Intel, "F00F Bug Inside"!
-
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
-
OK, but that’s a separate issue to updating the base.