Tiny Core 14.0 Alpha 1 Testing

[Juanito]

Team Tiny Core is pleased to announce that Tiny Core 14.0 Alpha1 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 alpha level cut. If you decide to help test, then please test carefully. We don't want anyone to lose data.

Since this is an alpha cut, we ask that only experienced users test. This cut is not for general use. The features in any alpha are not fixed and may change before a public release candidate is available.

We appreciate testing and feedback.

Changelog for 14.0 alpha1:
* 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

Note:

* la files have been removed from *-dev extensions (thanks to @Rich)
* intel hd4400 graphics fails with the modesetting driver in x86

[patrikg]

Maybe this is silly question ??
Is it possible to make tc boot faster ??
I thinking of like bmarcus does with picore use the python capabilities to extract the extensions in one core each.
Have seen some problems with that because of not having control of the extractions order of the deps. 
But i think's it's work very well.

I don't know how that can be accomplished with the ordinary tc.
Maybe make some type of depending tree of how and what order the extensions extract.
I don't know how to run shell scripts and commands from each core.
What commands have the capabilities to do that.

Just having only one command in mind that spans the commands in separate cores.
Yes you are right, the make command with it's -j argument.
 
Thats all.
PS. And thx for this os

[curaga]

If you have several cores, TC probably already boots very fast? Move some rarely used extensions to ondemand, etc.

[GNUser]

Congratulations to the team on this upcoming release!

I'm using it now on my laptop. It is a pleasure to help with testing. It already seems to be in an advanced state of readiness. I've only found two issues so far:

1. The gcc.tcz extension loads but is unusable:

Code: [Select]

$ tce-status -i | grep gcc
gcc
gcc_libs
$ gcc
sh: gcc: not found
2. A handful of extensions (eight, see below) that are dependencies of some of my applications load and can be used (the applications that need them run just fine), but the extensions fail to create a file in /usr/local/tce.installed/

Here's a photo of my laptop's screen when booting with the showapps code, which shows some information that may be helpful:

[GNUser]

I deleted gcc.tcz and reinstalled it. That solved problem #1 in my previous post.
Problem #2 from previous post remains. I'll keep investigating.

[GNUser]

The 8 extensions impacted by problem #2 seemed too simple to be causing problems, so on a whim I removed the extension being loaded before them, namely gnumeric.tcz, from my onboot.lst file. Lo and behold, problem #2 went away.

I'm not sure what it is about gnumeric.tcz that's causing the "Permission denied" error for the handful of extensions that are loaded after it. I inspected the contents of gnumeric.tcz (including its tce.installed script) and nothing seems amiss. Very strange. I will just do without gnumeric for now.

[curaga]

gnumeric.tcz's permissions for the tce.installed dir may be wrong, missing the group write permission?

[Rich]

Hi curaga
That happened when I removed the  .la  files from the extensions.

It turns out that the  unsquasfs (V4.2)  command on our server removed the
group write permission. The Tinycore  unsquasfs (V4.3)  command does not
do that.

There are 424 x86 and 458 x86_64 extensions affected. I will fix them tonight.
Attached are the lists of affected extensions.

[GNUser]

Thanks, Rich. Mystery solved!

[GNUser]

On this alpha (64-bit) I can no longer create a 5 GHz 802.11ac hotspot on my router using hostapd.

I have confirmed that regulatory domain is set correctly. Whether I use the hostapd from the repo or one compiled for this version, result is the same: wireless clients can authenticate but have no internet connectivity, router becomes completely unresponsive after about 1 minute.

I will try creating a 5 GHz 802.11n hotspot: If that works, points to a problem with 802.11ac support; if that doesn't work, points to a problem with 5 GHz support.

curaga: Between TCL13.1 and TCL14-alpha1 is there any relevant change in kernel configuration options? All the hardware is the same on my end.

[curaga]

No, I don't think any wifi-related config changed. Wifi drivers (among with graphics) do often have bugs though.

[GNUser]

I am able to create a working 5 GHz 802.11n AP. The problem is with 802.11ac.

Thanks for that, curaga. Any troubleshooting ideas? I'd like to upgrade the router if possible, but not at the expense of my nice 802.11ac AP.

[GNUser]

Crash seems to happen as soon as a device authenticates, suggesting a regression in wireless authentication/encryption.

So I tinkered some more and discovered that, indeed, there's no problem if using 802.11ac with WPA1. When using 802.11ac with WPA2, certain encryption algorithms (including what I've been using for years) now cause router to immediately become unresponsive when first client authenticates.

For 802.11ac and WPA2, these settings seem to work just fine (just relevant lines from hostapd.conf are shown):

Code: [Select]

driver=nl80211
country_code=US
channel=36
hw_mode=a
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=SecRetPasswOrd
wpa_key_mgmt=WPA-PSKI realize that this is a very specific and very small regression, probably not affecting too many users. Sorry for the noise.

I'm very happy to be able to move past this and upgrade the router to TCL14-alpha1

[GNUser]

No joy. Changing the encryption options lowers speed considerably.

- TCL13.1 with old hostapd.conf: link speed = 433 Mbps, speedtest.net download speed = 120 Mbps

- TCL14 with modified hostapd.conf: link speed = 54 Mbps, speedtest.net download speed = 20 Mbps (or use old hostapd.conf with the new kernel and be subject to immediate system crash when a wireless client authenticates).

The wireless device that creates my AP is the ALFA AWUS036ACHM, which uses mt7610u chipset. The kernel panic when using linux kernel 6.1.x and this chipset is a known issue, for which a kernel patch exists:
https://github.com/morrownr/USB-WiFi/issues/168

@curaga - Would it be possible to include this kernel patch in TCL14 release? This chipset is supposedly one of the superstar chipsets with best linux support (see https://github.com/morrownr/USB-WiFi/blob/main/home/The_Short_List.md), so others who power their wireless router with TCL would also benefit from this patch.

[Rich]

Hi GNUser
Gnumeric and any other extensions that had incorrect tce.installed permissions
have been corrected and new md5.txt files were generated.

Update your extensions and see if things act normally now.