Tiny Core Linux
Tiny Core Base => TCB News => Final Releases => Topic started by: Juanito on February 09, 2020, 04:22:53 AM
-
Team Tiny Core is proud to announce the release of Core v11.0
http://www.tinycorelinux.net/11.x/x86/release
http://www.tinycorelinux.net/11.x/x86_64/release
Changelog for 11.0:
* kernel updated to 5.4.3
* glibc updated to 2.30
* gcc updated to 9.2.0
* e2fsprogs base libs/apps updated to 1.45.4
* util-linux base libs/apps updated to 2.34
* busybox updated to 1.31.1
* .ashrc removed #alias d='dmenu_run &'
Note:
* we discovered a bug on the 32-bit version, in Intel IOMMU, preventing boot. If you have a high-end Intel system with IOMMU and VT-D, you may need intel_iommu=off to boot the 32-bit version
* the nouveau kernel module is now enabled, but it is in a separate extension and not in graphics-KERNEL. The nvidia binary driver is still recommended.
* Intel compute sticks, etc should now detect their embedded mmc flash
* for 64 bit version only: task_xacct and ipmi are enabled
* we will move extensions from linking to openssl-1.0.2 -> 1.1.1 as 1.0.2 is at end of life
* Xorg-7.7 will move from using the depreciated xf86-input-evdev to xf86-input-libinput, it is still possible to use xf86-input-evdev if required
Note also:
* There has been an attempt to remove old and/or depreciated versions of giflib, gstreamer, icu, ncurses, openssl, qt-4.x, readline, webkit, etc from the repos and hence extensions that depend on them may not be present. If you are missing an extension, please highlight this here: http://forum.tinycorelinux.net/index.php/topic,23440.0.html
-
When I boot the CorePlus 11.0 iso, it says Booting Core 10.1
-
Hi thane
The version is listed in 2 files (that I'm aware of):
/etc/os-release
/usr/share/doc/tc/release.txtI'm guessing 1 or both of those files wasn't updated. Probably /etc/os-release since that was a recent addition.
-
CorePlus-current.iso shows the version as 10.1 in both files. However CorePlus-11.0.iso does show 11.0 when it boots, although the timestamp and file size are the same for both iso's. Hmmm
-
Hi thane
I think you are mistaken. I downloaded both versions and a diff shows them to be the same. I also checked the release files in
both directories and they showed 11.0. Since all versions contain a CorePlus-current.iso I suspect you mixed them up and
inadvertently used a 10.1 ISO.
-
The link on http://www.tinycorelinux.net/downloads.html still directs to 10.x, this is probably the reason for the confusion.
-
Hi FreeFull
Welcome to the forum.
The link on http://www.tinycorelinux.net/downloads.html still directs to 10.x, this is probably the reason for the confusion.
Yes it does, nice catch. In fact, all 3 links (Core, TinyCore, and CorePlus) still point to the 10.1 release directory.
thane must have downloaded his initial ISO from there.
-
Yes, think I did, then went to the Release Files page for 11.0.iso, and saw the .current.iso version there was the same size and timestamp. Didn't investigate any further :/ Anyway, so far so good with 11.0.
-
links updated
-
I didn't notice some changes. Are they documented somewhere? Please let me know, where to look.
Flwm_topside is no longer the default windows managers. Is this an intentional change?
With going to openssl-1.1.1.tcz there is no more wpa_supplicant extension, only the one with the suffix -dbus. Isn't that the x86_64 variant (=download&s[]=tcz]http://wiki.tinycorelinux.net/wiki:setting_up_wifi?s[]=download&s[]=tcz (http://wiki.tinycorelinux.net/wiki:setting_up_wifi?s[))? They seem to have at least different dependencies.
-
Flwm_topside is no longer the default windows managers. Is this an intentional change?
as far as I know, flwm_topside is a modified version of the default flwm
With going to openssl-1.1.1.tcz there is no more wpa_supplicant extension, only the one with the suffix -dbus. Isn't that the x86_64 variant (=download&s[]=tcz]http://wiki.tinycorelinux.net/wiki:setting_up_wifi?s[]=download&s[]=tcz (http://wiki.tinycorelinux.net/wiki:setting_up_wifi?s[))? They seem to have at least different dependencies.
this was done to avoid having to compile wpa_supplicant twice - the dbus daemon does not need to be running for it to work.
-
In general TC 11.0 is working fine for me.
In Apps/Maintenance/Check for Updates I do see the message "Warning: You are running version 11.0. The latest release is 10.1"
Also, a couple apps I use (audacious, flpicsee) apparently have not been migrated to the 11.0 repo. I retained the 10.1 versions when I updated and they appear to work fine in 11.0.
-
Latest file updated on server, thanks for reporting.
-
as far as I know, flwm_topside is a modified version of the default flwm
A compile-time variant. The 10.1 ISO and previous ones contain only flwm_topside. The 11.0 ISO only contains flwm. A matter of packaging. I'm just curious why this was changed and if this was/is intended.
this was done to avoid having to compile wpa_supplicant twice - the dbus daemon does not need to be running for it to work.
It only confused me, when reading the wiki entry. No big deal.
-
Latest file updated on server, thanks for reporting.
Curaga - see http://forum.tinycorelinux.net/index.php/topic,23523.0.html
I think you updated it to 11 - when 11.0 was more appropriate...
Lexi
-
Libgit2 on 64-bit depends on SSL 1.0 and needs a refresh.
-
Also, a couple apps I use (audacious, flpicsee) apparently have not been migrated to the 11.0 repo. I retained the 10.1 versions when I updated and they appear to work fine in 11.0.
tc-10.x audacious depends on libavdevice3 and gnome-icon-theme, which are not in the 11.x repo - updated for the 11.x repo.
flpicsee depends on fltk-1.10 - an extension recompiled against fltk-1.3 would be gratefully received :)
-
Libgit2 on 64-bit depends on SSL 1.0 and needs a refresh.
libgit2 and libgit2-glib updated
-
md5sum: libgit2.tcz.md5.txt: no checksum lines found :o
-
It should be OK now
-
Hi,
When this will be available for other architectures?
Thanks
-
Which other architectures are you speaking of?
-
I think those:
http://tinycorelinux.net/11.x/armv6/test_releases/RPi/
http://tinycorelinux.net/11.x/armv7/test_releases/RPi/
http://tinycorelinux.net/11.x/armv7l/test_releases/RPi/
-
Thank you for the update. Loving it so far.
-
Thank you for this new release.
Here my observation using 11.0 for the first time.
- With 10.1 and before I can start a TCL VM with just 64MB memory assigned.
(depending on the extension I do need to increase memory, but often 128MB is sufficient for my needs)
- With 11.0 I observe the following:
- with 96MB: Kernel panic - not syncing: System is deadlocked on memory.
- with 128MB: a back screen (no GUI)
- with 160MB: no issues
I understand new features require more resources. Just checking if this is expected.
I'm also missing ipv6-5.4.3-tinycore.tcz for IPv6 support.
-
Hi rhermsen
... I'm also missing ipv6-5.4.3-tinycore.tcz for IPv6 support.
It was merged with netfilter and is now called:
ipv6-netfilter-5.4.3-tinycore.tcz
If you're running 64 bit it's
ipv6-netfilter-5.4.3-tinycore64.tcz
-
Such a RAM need increase is unexpected, but the upstream kernel doesn't care that much about such low RAM amounts, so it's possible. There is no external increase - the initrd only grew about the usual amount - so it's very likely a kernel behavior change.
-
Thank you both for the replies.
@Rich see indeed both extensions (running the 32bit version of TCL).
-
If you'd like to do a bisect and report the RAM regression to the kernel bugzilla, please do. I think it's quite possible nobody has noticed it yet.
edit: And the 64-bit kernel is available on the 32-bit edition, for running with large RAM machines, etc.
-
putty doesn't work in version 11
-
Hi bjorn
putty doesn't work in version 11
Maybe you could share what error messages you get when you enter the putty command?
-
putty ran on every version up to 10.1 on 64-bit tinycore. There are no error messages, just a blank screen.
-
Hi bjorn
If you open a terminal, and enter the command putty , you don't see any error messages in the terminal?
-
If you'd like to do a bisect and report the RAM regression to the kernel bugzilla, please do. I think it's quite possible nobody has noticed it yet.
Never looked at bisect before. And a bit rusty on compiling a 'custom' kernel, so not sure if I manage to get into this. I did put this on my todo list.
edit: And the 64-bit kernel is available on the 32-bit edition, for running with large RAM machines, etc.
Thanks for explaining! Wondered already before why sometimes 64bit extensions where present in the 32bit repo.
-
putty ran on every version up to 10.1 on 64-bit tinycore. There are no error messages, just a blank screen.
putty works for me in tc-11.x x86 and x86_64
-
Tried a few times more to start a 11.0 VM with just 64MB. First time it failed again, second time the VM booted normally with 64MB.
tc@box:~$ version
11.0
tc@box:~$ cat /proc/meminfo
MemTotal: 56056 kB
MemFree: 6864 kB
MemAvailable: 6308 kB
Buffers: 192 kB
Cached: 22016 kB
SwapCached: 20 kB
Active: 17756 kB
Inactive: 17100 kB
Active(anon): 17528 kB
Inactive(anon): 16756 kB
Active(file): 228 kB
Inactive(file): 344 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 56056 kB
LowFree: 6864 kB
SwapTotal: 4480 kB
SwapFree: 4 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 12644 kB
Mapped: 7748 kB
Shmem: 21636 kB
KReclaimable: 1160 kB
Slab: 5796 kB
SReclaimable: 1160 kB
SUnreclaim: 4636 kB
KernelStack: 464 kB
PageTables: 284 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 32508 kB
Committed_AS: 44516 kB
VmallocTotal: 958464 kB
VmallocUsed: 652 kB
VmallocChunk: 0 kB
Percpu: 164 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
DirectMap4k: 20472 kB
DirectMap4M: 45056 kB
tc@box:~$
tc@box:~$ version
10.1
tc@box:~$ cat /proc/meminfo
MemTotal: 56620 kB
MemFree: 7236 kB
MemAvailable: 9476 kB
Buffers: 324 kB
Cached: 28576 kB
SwapCached: 0 kB
Active: 19096 kB
Inactive: 20200 kB
Active(anon): 17932 kB
Inactive(anon): 17056 kB
Active(file): 1164 kB
Inactive(file): 3144 kB
Unevictable: 0 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 56620 kB
LowFree: 7236 kB
SwapTotal: 1612 kB
SwapFree: 1612 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 10388 kB
Mapped: 6972 kB
Shmem: 24604 kB
Slab: 5472 kB
SReclaimable: 1136 kB
SUnreclaim: 4336 kB
KernelStack: 448 kB
PageTables: 252 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 29920 kB
Committed_AS: 40264 kB
VmallocTotal: 958464 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 152 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
DirectMap4k: 20472 kB
DirectMap4M: 45056 kB
tc@box:~$
-
On 64-bit hplip needs to be recompiled against openssl-1.1.1, as it's looking for 1.0 now. This may also be true for 32-bit, but I haven't checked.
-
Having recompiled hplip, it looks like the problem is with ghostscript :(
-
hplip and ghostscript posted to tc-11.x x86_64 repo
My hp network printer is found automatically and the test page prints , but most of the hp-* commands cannot find the printer..
-
Hi Juanito and Rich,
I use findutils and after upgrading to TC11 I noticed there is an error building the locate database with 'sudo updatedb' because the sort utility is not found. I see in the updatedb script on lines 111 and 115 a command to /bin/sort The error is fixed with changing these two lines to /usr/bin/sort
thx
Billy
-
Hi Rudock1
Looks like a regression from the last update. The info file shows this in the change-log:
2019/02/20 corrected sort path in updatedb
Current: 2019/11/29 updated 4.6.0 -> 4.7.0:
I don't understand why /bin/sort is not linked to busybox like all the other commands.
You didn't specify which architecture, but I suspect x86 and x86_64 are affected since their change-logs both indicate a recent update.
-
<sigh> at least this time I remembered the script needed fixing, I just fixed it to the wrong place - I'll fix the extensions tomorrow.
-
Thanks for the quick replies. Sorry I forgot to say I use Corepure64 , x86_64
Also, I use coreutils.tcz which gives me the GNU sort
thx and good health to all,
Billy
-
Hi Juanito
Since the script comes from an outside source, and will likely continue to point to /bin/sort in the future, would it make sense to
add a link command in the tce.installed file instead of always modifying the script?
-
It actually points to /usr/local/bin/sort because coreutils is present at compile time.
-
findutils reposted
-
hplip and ghostscript posted to tc-11.x x86 repo - things had also been broken by a net-snmp update
-
GNU wget gives: Disabling SSL due to encountered errors.
Looks due to openssl 1.1.1 (see e.g. https://github.com/ContinuumIO/anaconda-issues/issues/10709)
wget
BusyBox v1.31.1 (2019-12-17 16:10:37 UTC) multi-call binary.
cd /tmp
wget https://github.com/FRRouting/frr/archive/frr-6.0.2.tar.gz
Connecting to github.com (140.82.118.4:443)
sudo rm frr-6.0.2.tar.gzConnecting to codeload.github.com (140.82.114.9:443)
saving to 'frr-6.0.2.tar.gz'
frr-6.0.2.tar.gz 100% |*****************************************************************| 4371k 0:00:00 ETA
'frr-6.0.2.tar.gz' saved
tce-load -wi wget.tcz
#reboot
wget --version
NU Wget 1.20.3 built on linux-gnu.
cd /tmp
wget https://github.com/FRRouting/frr/archive/frr-6.0.2.tar.gz
--2020-04-04 13:54:17-- https://github.com/FRRouting/frr/archive/frr-6.0.2.tar.gz
Disabling SSL due to encountered errors.
-
https://bugs.debian.org/926315
Some more info.
-
I've compiled openssl-1.1.1f, which seems to fix the problem - I'll post after some more testing.
-
updated openssl-1.1.1 posted
-
GNU wget is working fine with openssl-1.1.1f.
Thanks!
-
SNIP
/etc/os-release
/usr/share/doc/tc/release.txtSNIP
I wonder, is it possible for someone to accidently download the 32 variants....boot up on a 64 bit CPU and be none the wiser?
on my 64 bit I have
cat /etc/os-release
NAME=TinyCore
VERSION="11.1"
ID=tinycore
VERSION_ID=11.1
PRETTY_NAME="TinyCoreLinux 11.1"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:tinycore:tinycore_linux:11.1"
HOME_URL="http://tinycorelinux.net/"
SUPPORT_URL="http://forum.tinycorelinux.net/"
BUG_REPORT_URL="http://forum.tinycorelinux.net/"
tc@box:~$ cat /usr/share/doc/tc/release.txt
11.1
If its just a string.....maybe add x64_64 to it?
I am aware I am on the correct variant as "uname -r" tells me so.
I do not want to waste internet bandwith in these troubling times by downloading 32 bit variants to peek into their text files
thanks for reading
-
Hi aus9
... I wonder, is it possible for someone to accidently download the 32 variants....
Certainly, if they manually download extensions instead of using the intended tools (apps or tce-load).
... boot up on a 64 bit CPU and be none the wiser? ...
Since Tinycore does not support mixed 32/64 bit libraries (and extensions), no.
If you are running Corepure64 (64 bit kernel, 64 bit apps) a 32 bit program will fail to run.
If you are running Core64 (64 bit kernel, 32 bit apps), you can only run 32 bit programs.
If you are running Core (32 bit kernel, 32 bit apps), you can only run 32 bit programs.
I am aware I am on the correct variant as "uname -r" tells me so.
That only tells you if you are running a 32 or 64 bit kernel.
The getBuild() function defined in /etc/init.d/tc-functions is used to determine whether you need 32 or 64 bit extensions:
tc@E310:~$ . /etc/init.d/tc-functions && getBuild
x86
tc@E310:~$