Tiny Core v16.0

[Juanito]

Team Tiny Core is proud to announce the release of Core v16.0
http://www.tinycorelinux.net/16.x/x86/release
http://www.tinycorelinux.net/16.x/x86_64/release

Changelog for 16.0:
* kernel updated to 6.12.11
* glibc updated to 2.40
* gcc updated to 14.2.0
* binutils updated to 2.43.1
* e2fsprogs base libs/apps updated to 1.47.1
* util-linux base libs/apps updated to 2.40.2
* zlib base lib updated to 1.3.1

* getTime.sh: support more than one server from dhcp from miesi-ionos
* update-everything: offer to remove deprecated extensions from bdantas
* tc-function remove mount/umount from bb list from CardealRusso
* provides.sh: Rich's improved versions: update from CardealRusso
* linuxrc: remove symlink from GNUser
* update-everything: backup stale .dep files form bdantas
* tce-load: add missing sudo to rmdir command in copyInstall() from Rich
* tce-load, tce-setup: changes from idk
* tce-setup: fix syntax error from bdantas

Not in the base, but also updated:
* mirrorpicker: grab info.lst from 15.x
* mirrorpicker: explicitly use bb wget
* editor: various changes from Rich

Note also that the fltk_projects in x86_64 have been updated to use fltk-1.4 with x11 and wayland. In the interests of minimising bloat the x86 fltk_projects remain with fltk-1.3 x11 only.

[Uncle Warthog]

I'm having some issues with the Apps GUI application in both the 32 and 64 bit versions.  The problem in both is that I am unable to load apps locally from the GUI menu.  All of my downloaded apps appear but selecting one for installation does nothing and gives no error message.  Installing one manually using the tce-load -i command line loader pointing it to the physical location of the application seems to work fine.  Also, using the browse menu to find the application online then selecting it for download and load works fine; in the download window, I can see it scroll through the application and list of dependencies but they are not downloaded as they already exist in the tce location then the application is loaded and can be run.

Also, onboot maintenance, at least in the 64-bit version (I have not checked the 32-bit version yet) does not appear to work correctly, with a problem possibly related to the local loading.  I'm presented with a list of apps as usual but the onboot list in the right half of the window is blank.  I can select an application to be added to the onboot list but no change is made to the onboot list, either in the window or on disk.  Editing the onboot list file manually with vi or another text editor seems to work fine.

This appears to be a new problem in TCL 16.0, TCL 15.0 worked fine for both of these things.

Any help you can give me with this would be greatly appreciated.

[CNK]

Following on from discussion on failure to boot on 486 and VIA C7 CPUs in the TC16 Alpha/Beta testing threads:

486

Although I found some 16MB RAM sticks to try and upgrade my 486 desktop PC to 36MB RAM, it looks like the 486 reboot problem is definitely in the kernel code anyway. I finally dug up this patch in the kernel mailing list from Oct. 2024. The author says the first bug fixed by it "causes immediate reboot" on CPUs without CPUID support (486s).

Looking though the Git log for the patched file in the kernel sources it doesn't seem to have been merged, though it's not clear why. I guess then that all current unpatched kernels since v6.7-rc1 fail on 486 CPUs (the TC15 kernel was v6.6.8).

I'd ask about adding that patch to the TC16 kernel, but since it's released now I guess I'm a few hours too late...

VIA C7

I did similar searching for the VIA C7 issue and found lots of hits for random freezes like with the printk kernel, but in that case they were all pretty ancient bugs, nothing recent. However I haven't found a suggestion of a fix ever being made, newer software versions apparantly just started working again. My guess is that the bug is still rolling around in the kernel code somewhere, intermittently getting triggered by different glibc builds, or this time by the non-printk kernel build itself, when the compiler happens to optimise it in a certain way that triggers the hang condition. Or I guess it could just be a coincidence.

2008 - Gentoo bug 228263 - sys-libs/glibc-2.6.1 plus VIA C7 CPU plus load freeze box
2008 - Debian Bug 507845 - Dedibox server with VIA C7 cpu freeze with the last libc6
2008 - Kernel mailing list discussion - strange freeze with VIA C7 dedicated server and libc 2.6.1
2007 - Kernel mailing list discussion - similar sounding issue fixed with some X86_CMPXCHG64 patch - possibly related CONFIG_X86_CMPXCHG64 kconfig option removed in v5.15.153.
2007 - unanswered Kernel mailing list post - VIA spurious hang on 2.6.23.1

On my VIA C7-M system I tried "clocksource=jiffies" and related kernel commands, and failed to enable any more debugging info with "sched_debug", nothing had any affect with the standard kernel. There are more suggestions in the threads above, but they never seemed to help anyone back then...

[Rich]

Hi Uncle Warthog

... The problem in both is that I am unable to load apps locally from the GUI menu. ...

Confirmed. I'll try to take a look tomorrow to see if I can spot the problem.

[Juanito]

Although I found some 16MB RAM sticks to try and upgrade my 486 desktop PC to 36MB RAM, it looks like the 486 reboot problem is definitely in the kernel code anyway. I finally dug up this patch in the kernel mailing list from Oct. 2024. The author says the first bug fixed by it "causes immediate reboot" on CPUs without CPUID support (486s).

Looking though the Git log for the patched file in the kernel sources it doesn't seem to have been merged, though it's not clear why. I guess then that all current unpatched kernels since v6.7-rc1 fail on 486 CPUs (the TC15 kernel was v6.6..

I'd ask about adding that patch to the TC16 kernel, but since it's released now I guess I'm a few hours too late...

Before we think about recompiling the kernel, you might want to ask the kernel people why the patch wasn't included?

[Rantanplan]

Bonjour @Juanito,

Merci à l'équipe de développeurs de Tiny Core Linux et aux testeurs pour cette dernière version de TCL.

Félicitations et Bravo à toute l'équipe.

Amitiés.

[Rich]

Hi Juanito
I tracked down the issue and pushed the fix to git.

If you see this type of warning when compiling apps, ignore it:

Code: [Select]

warning: ignoring return value of 'bool std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::empty() const [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>]', declared with attribute 'nodiscard' [-Wunused-result]   66 | report_type.empty();/code]


[Uncle Warthog]

Hi Uncle Warthog

... The problem in both is that I am unable to load apps locally from the GUI menu. ...

Confirmed. I'll try to take a look tomorrow to see if I can spot the problem.

Thanks!  Let me know if there's anything you want me to test on my systems.

[Rich]

Hi Uncle Warthog
Once Xprogs.tcz gets updated with the fix you should see an announcement here.

[Juanito]

Xprogs updated

[Juanito]

Release of Core v16.0 reposted with some small changes added that were missed first time.

Release announcement modified to suit.

[Uncle Warthog]

Thanks!

I've tested and everything seems to be working now except for onboot maintenance in the 64-bit apps GUI (the 32-bit works fine). 

[Juanito]

If you start apps from a terminal window do you see any error messages?

[Uncle Warthog]

If you start apps from a terminal window do you see any error messages?

No error messages in the terminal window when I start it and no error messages when trying to use onboot maintenance.

When I try to use onboot maintenance, I get the list of apps in the left side of the window as normal but the right side of the window is completely empty instead of showing the contents of the onboot.lst file.  The system allows me to try to add an entry into the file without errors but the listing in the right side of the window remains blank and the existing onboot.lst file remains unchanged.  I've checked that the file is not marked as read-only and I'm able to edit it using vi or other editors without problems.

I know that onboot functionality itself is working correctly as I can insert and remove entries in the onboot.lst file using vi without problems.  It's just editing it in the apps GUI that isn't working.

[Rich]

Hi Juanito
I updated my Xprogs and corepure64 files.
When starting apps from the command line, I get an
error when trying to add an extension to onboot.lst:


You can see in the error message it somehow jumbled
the path to onboot.lst and part of /proc/cmdline together.

If you look just above the 2 display windows in apps you
can see more of the text from /proc/cmdline scribbled
across the length.