Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: Juanito on January 04, 2021, 05:12:03 AM
-
Team Tiny Core is pleased to announce that Tiny Core 12.0 Alpha1 is available for public testing:
http://repo.tinycorelinux.net/12.x/x86/release_candidates/distribution_files
http://repo.tinycorelinux.net/12.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 12.0 alpha1:
* kernel updated to 5.10.3
* glibc updated to 2.32
* gcc updated to 10.2.0
* binutils updated to 2.35.1
* e2fsprogs base libs/apps updated to 1.45.6
* util-linux base libs/apps updated to 2.36.1
* tc-functions: version changes from andyj
* version: changes from andyj
* shutdown.sh: clarifying comment
* busybox-aliases: additions from bdantas
* filetool.sh: comments from bdantas
* tce-setup: remove neeedless timestamp from bdantas
* tce-config: more precise /opt copying from bdantas
* tce-config: rename autoscan from polikuo
* tc-config: similar awk rounding
* init: avoid awk rounding
* filetool.sh: dc syntax change fix from watt
* tce-audit: search fix from lhaley42
Note:
* we discovered a bug whereby busybox modprobing any module for the 5.10 kernel prints the message "Module has invalid ELF header", but the module is loaded anyway
* the libffi and readline extensions have been updated - this will break a lot of extensions, so fallback libffi6 and readline7 extensions have been created.
-
I realize that starting out there will not be many extensions, but Xorg-7.7 has a dependency on libxkbfile which is missing in the 32-bit and 64-bit repos so Xorg is a non-starter.
-
No squashfs-tools either which makes building extensions a little more challenging.
-
Thanks to Core Team and congratulations to all of us!
I see hwclock not system time on my 32-bit system:
sudo hwclock -s -u
hwclock: settimeofday: Invalid argument
echo $?
1
while kernel is serving rtc and tz correctly
tc@box:~$ hwclock
Mon Jan 4 15:44:51 2021 0.000000 seconds
tc@box:~$ hwclock -u
Mon Jan 4 17:45:00 2021 0.000000 seconds
tc@box:~$ date
Mon Jan 4 17:45:09 EET 2021
tc@box:~$ echo $TZ
EET-2EEDT-3,M3.5.0/3,M10.5.0/4
-
libc.pdf says:
The struct timezone type is obsolete and should never be used.
-
This is from /util-linux-2.36/sys-utils/hwclock.c:
* POSIX 2008 marked TZ in settimeofday() as deprecated. Unfortunately,
* different C libraries react to this deprecation in a different way. Since
* glibc v2.31 settimeofday() will fail if both args are not NULL
Seems that busybox's hwclock.c needs to be patched a little bit in order to work properly with fresh libc.
-
I realize that starting out there will not be many extensions, but Xorg-7.7 has a dependency on libxkbfile which is missing in the 32-bit and 64-bit repos so Xorg is a non-starter.
libxkbfile and squashfs-tools copied over
-
This is from /util-linux-2.36/sys-utils/hwclock.c:
* POSIX 2008 marked TZ in settimeofday() as deprecated. Unfortunately,
* different C libraries react to this deprecation in a different way. Since
* glibc v2.31 settimeofday() will fail if both args are not NULL
Seems that busybox's hwclock.c needs to be patched a little bit in order to work properly with fresh libc.
The util-linux "hwclock -s -u" doesn't give an error - please report the bug to busybox.
-
I'm pretty sure that was covered in bb months ago, and current version (or git) works fine.
-
Xorg works now, and I can compile and build a few extensions but not many. I would think that for any extension its associated -dev extension would be available too, since they're mostly header files. Mirrors.tcz might be helpful too.
-
I’m steadily working through the extensions and adding them as I check their status vis a vis libffi and readline - *dev extensions often pull in additional deps, so they take longer.
-
I'm pretty sure that was covered in bb months ago, and current version (or git) works fine.
Quite right, busybox 1.33.0 is already cleaned out of this inconsistency.
@Juanito, Xfbdev.tcz.dep includes libXfont.tcz reference, while present in repo is libXfont2.tcz. Both x86 and x86_64.
-
And, correspondingly, Xfbdev wants libXfont.so to start ...
And Xvesa the same.
-
There is a patch on the bb mailinglist for the modprobe issue. Let's wait a bit to see if it's accepted; if not, we'll carry that locally. bb needs an update anyways.
-
I've copied libXfont.tcz* from my local tce11/optional along with the other missing stuff and now I am writing this post from TC12a1 under Xfbdev+dwm with the help of netsurf-gtk.:)
-
Xorg works now, and I can compile and build a few extensions but not many. I would think that for any extension its associated -dev extension would be available too, since they're mostly header files. Mirrors.tcz might be helpful too.
copied over
-
And, correspondingly, Xfbdev wants libXfont.so to start ...
And Xvesa the same.
copied over
-
I saw this in the Slackware changelog:
k/kernel-source-5.10.5-noarch-1.txz: Upgraded.
We'll turn off the silent stream feature as there's a known deadlock bug that
remains in 5.10.5. Perhaps we'll restore it once that's patched... but we
made it this far without the feature so I'll probably wait for a case to be
made for it. Thanks to Petri Kaukasoina.
Also build the intelfb module. This doesn't have anything to do with the
lockups occurring on Intel systems, but we might as well provide the module.
It remains blacklisted by default.
FB_INTEL n -> m
SND_HDA_INTEL_HDMI_SILENT_STREAM y -> n
+FB_INTEL_DEBUG n
+FB_INTEL_I2C y
Is this going to be a problem for TC 12?
-
# CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set
-
Good. For some reason I can't seem to find the kernel source or config files. Where would these be?
-
I think they aren't yet posted as we weren't sure if the modprobe error was to be fixed in kernel or not.
-
I read it as a busybox issue. Did I misread that?
-
Denys blames kernel, kernel programmer blames busybox.
-
This "Module has invalid ELF header" messages are seen only in the initial console. The action, which will cause this messages in concole, in the terminal emulator under X don't show this messages. For example
tce-load -i wifi
performed before startx shows a lot of such messages, while started ubder Xfbdev in st executes smoothly.
What does this means? Messages are output device dependent? My guess is that they are emitted by kernel.
-
Yes, the message comes from the kernel. The point of contention is the mechanism.
-
Testing/playing with TC12_x64, all good until now (except already reported harmless "invalid ELF header" messages).
But I need to copy kmaps.tcz (for UK keyboard) and firmware-rtlwifi.tcz (for wifi rtl8723be) from TC11. And I write this from win10, because no minimal web-browser (yet) in TC12.
-
Hi nick65go
... because no minimal web-browser (yet) in TC12.
You should be able to get firefox using the following:
http://repo.tinycorelinux.net/11.x/x86/tcz/firefox_getLatest.tcz.info
-
I could try, but I am afraid that I will add/poluate a lot of tcz manualy imported from TC11.My undestranding is that firefox_getlatest.tcz only build firefox.* (tcz, dep) but will not download all dependency necesary for firefox.exe to run.
Maybe a simple (low dependency web-browser) solution will come in my mind.I already have in TC11_x64 the firefox 84.02 + its deps.
PS: If I remember correctly firefox from Alpinelinux has less dependencies (they adjust a text file from firefox folder...which list its dependencies; or I saw this in win10 when I manualy un-ziped firefox into an random folder and run it from there directly).
-
Anyway. I manually add few tcz which are not yet in TC12 (gdk-pixbuf2.tcz, gamin.tcz) and firefox is running.
With this kernel version 5.10.3, for my CPU = AMD A6-6310 APU with AMD Radeon R4 Graphics, (core GCN 1.x or 2x?)
Is anything else that I can do to have amdpgu instead of radeon as video card driver?
because unfortunately radeon is detected/loaded first and not amdgpu.
tc@box:~$ lsmod | grep radeon
radeon 991232 0
drm_kms_helper 114688 1 radeon
ttm 53248 1 radeon
drm 286720 3 radeon,drm_kms_helper,ttm
backlight 12288 3 radeon,drm,video
Filesystem Size Used Available Use% Mounted on
/dev/loop4 8.5M 8.5M 0 100% /tmp/tcloop/firmware-amdgpu
/dev/loop32 3.1M 3.1M 0 100% /tmp/tcloop/graphics-5.10.3-tinycore64
/dev/loop33 64.0K 64.0K 0 100% /tmp/tcloop/xf86-video-amdgpu
but from dmesgLinux version 5.10.3-tinycore64 (root@box) (gcc (GCC) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #2021 SMP Mon Dec 28 16:17:51 UTC 2020
Command line: BOOT_IMAGE=/boot/tc12/vmlinuz64 tce=sda8/tce laptop pcie_aspm=force radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1
..
[drm] radeon kernel modesetting enabled.
radeon 0000:00:01.0: CIK support disabled by module param
no MTRR for c0000000,1000000 found <-- is my UEFI buggy?
EDIT: even after I did oot@box:/home/tc# modprobe amdgpu
root@box:/home/tc# modprobe -r radeon
root@box:/home/tc# lsmod | grep radeon
root@box:/home/tc# lsmod | grep amdgpu
amdgpu 3342336 0
gpu_sched 16384 1 amdgpu
drm_kms_helper 114688 1 amdgpu
ttm 53248 1 amdgpu
drm 286720 4 amdgpu,gpu_sched,drm_kms_helper,ttm
backlight 12288 3 amdgpu,drm,video
then Exit to console, and again startx, I have VESA not amdgpu driver (because Xorg is compiled with radeon in mind, not with amdgpu)
[ 2940.013] ABI class: X.Org Server Extension, version 10.0
[ 2940.013] (==) Matched ati as autoconfigured driver 0
[ 2940.013] (==) Matched modesetting as autoconfigured driver 1
[ 2940.013] (==) Matched fbdev as autoconfigured driver 2
[ 2940.013] (==) Matched vesa as autoconfigured driver 3
[ 2940.013] (==) Assigned the driver to the xf86ConfigLayout
[ 2940.013] (II) LoadModule: "ati"
[ 2940.013] (WW) Warning, couldn't open module ati
[ 2940.014] (EE) Failed to load module "ati" (module does not exist, 0)
-
http://forum.tinycorelinux.net/index.php/topic,24551.msg155804.html#msg155804
kernel 5.1x. AMDGPU Radeon
- AMDGPU DC display support for GCN 1.0 "Southern Islands" graphics processors. AMDGPU DC for GCN 1.0 was one of the lingering missing items that remained for potentially enabling AMDGPU support by default for GCN 1.0/1.1 era hardware in place of the Radeon DRM driver. The last apparent blocker though is the lack of analog output support with AMDGPU DC and so for that no default change has been made. Those with these aging Radeon HD 7000 series graphics cards and other select GCN 1.0/1.1 products can boot their kernel with "amdgpu.cik_support=1 amdgpu.si_support=1 radeon.cik_support=0 radeon.si_support=0" to enjoy the AMDGPU kernel driver by default that also means working Vulkan support, possible performance improvements, and just enjoying the more modern code-base. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-Feature-Recap
-
The SI and CIK AMDGPU options are not enabled. The radeon module is what was intended for those cards, and gives them full functionality and less bugs. If you want amdgpu for some reason, you'll need a custom kernel.
-
@curaga: Thanks for the clarification. It is not what I expected from a modern kernel 5.10.x, but at least now I know it is about kernel compile options that TC developers choose for their distribution.The radeon driver works OK (except insane default brightness). So I wanted to try/test amdgpu driver for my UEFI laptop, to see if it could have longer batery life, if not then better performance, etc.
Without radeon driver /dev/dri/card is not created by the kernel, so Xorg is not loading amdgpu.
Could you please copy/paste the few options from .config (for kernel) to be activated, so that amdgpu becoming default video driver?
-
Anyway. I manually add few tcz which are not yet in TC12 (gdk-pixbuf2.tcz, gamin.tcz) and firefox is running.
gdk-pixbuf2 was already in the tc-12.x repos, but gamin and firefox_getLatest (and kmaps) copied over
-
gdk-pixbuf2 was already in the tc-12.x repos, but gamin and firefox_getLatest (and kmaps) copied over
maybe you are right, but now (13/01/2021 at 12:45 my time in Austria), they are not in http://tinycorelinux.net/12.x/x86_64/tcz/ (http://tinycorelinux.net/12.x/x86_64/tcz/). looking from MS Windows10, so maybe just the list is not updated, but the tcz are in folder as invisible files.
-
@xor: regarding "potentially enabling AMDGPU support by default for GCN 1.0/1.1 era hardware in place of the Radeon DRM driver."
from https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.10-Feature-Recap
it seams to me that my AMD A6-6310 APU [with AMD Radeon R4 Graphics] is type GCN 2.x (code CIK, or Sea Islands) acording to
https://www.x.org/wiki/RadeonFeature/#decoderringforengineeringvsmarketingnames
https://wiki.gentoo.org/wiki/AMDGPU#Kernel
https://wiki.archlinux.org/index.php/AMDGPU#Enable_Southern_Islands_(SI)_and_Sea_Islands_(CIK)_support
-
The SI and CIK AMDGPU options are not enabled. The radeon module is what was intended for those cards, and gives them full functionality and less bugs. If you want amdgpu for some reason, you'll need a custom kernel.
find keywords AMDGPU (5 times) and RADEON (6 times) for kernel config in
https://git.alpinelinux.org/aports/tree/main/linux-lts/config-lts.x86_64 (https://git.alpinelinux.org/aports/tree/main/linux-lts/config-lts.x86_64)
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
CONFIG_DRM_RADEON=m
CONFIG_DRM_RADEON_USERPTR=y
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
# CONFIG_DRM_AMDGPU_USERPTR is not set
# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set
# ACP (Audio CoProcessor) Configuration
CONFIG_DRM_AMD_ACP=y
# Display Engine Configuration
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_DCN=y
CONFIG_HSA_AMD=y
Is anything else that I need to have options SI and CIK enabled for AMDGPU? Thanks in advance.
-
Hi nick65go
In case you are not aware, kernel config files are not intended to be edited directly. Options interact. Use the command:
make menuconfig
to make changes.
Select:
Device Drivers->Graphics support
And you will see the entries you need:
(http://forum.tinycorelinux.net/index.php?action=dlattach;topic=24677.0;attach=5610)
-
I copied these extensions from my TCL11.1/tce/optional to TCL12.0/tce/optional and they work well:
gtk2.tcz
fuse.tcz
iproute2
iptables
openresolv
db
libdb
wireguard-tools
As I was expecting, I see that the linux kernel team now provides the wireguard kernel module:
TCL12$ tce-load -wi ipv6-netfilter-KERNEL
TCL12$ sudo modprobe ipv6
TCL12$ sudo modprobe wireguard # this works because the wireguard module is included in modules64.gz. Awesome!
I expect that by the time TCL12 is released, the TCL team will have separated out the wireguard kernel module into its own extension (wireguard-5.10.3-tinycore64.tcz). If that's the case, no changes will be needed to wireguard-tools.tcz.dep. If, on the other hand, the wireguard kernel module is part of TCL12 base system, then wireguard-KERNEL.tcz should be removed from wireguard-tools.tcz.dep.
P.S. This post was made from TCL12 using firefox, a wifi connection, and a wireguard VPN connection.
-
It's small enough that probably it won't make sense to make an extension for it.
-
* the libffi and readline extensions have been updated - this will break a lot of extensions, so fallback libffi6 and readline7 extensions have been created.
I found three affected extensions so far among those I've copied over from TCL11.1 x86_64:
- libffi6.tcz should be appended to geany.tcz.dep and caja.tcz.dep
- readline7.tcz should be appended to gnupg.tcz.dep
-
I copied these extensions from my TCL11.1/tce/optional to TCL12.0/tce/optional and they work well:
gtk2.tcz
fuse.tcz
iproute2
iptables
openresolv
db
libdb
wireguard-tools
gtk2, fuse, iproute2, iptables and openresolve copied over - db was already there.
@curaga - do you mean add the wireguard module to the base or to wireguard-tools?
-
Although Vim is good, there are still a few people (mostly in countries that use hieroglyphics) who like vi, so I recommend adding Unicode support to BusyBox's vi. Note: BusyBox's vi editor does not support Unicode encoding.
-
..but that will add bloat...
-
Ex-vi (also known as native vi) supports Unicode, but has a lot of problems, such as screen flickering, replacement mode...
-
..but that will add bloat...
You can do it as an extension, as a patch, but I won't or I'll do it, so more people can benefit from it.
-
I found three affected extensions so far among those I've copied over from TCL11.1 x86_64:
- libffi6.tcz should be appended to geany.tcz.dep and caja.tcz.dep
- readline7.tcz should be appended to gnupg.tcz.dep
geany and gnupg updated, caja dep file adjusted
-
Vim/gvim is compiled with multibyte support and seems to work with the few files I have to test it with. If it isn't working for you I'll need some example files and fonts that should work before I can see what the issue might be. So far I have been able to compile vim and rxvt for TC 12, but not much else. I can submit those if you are willing to help me test them.
-
I realize that starting out there will not be many extensions, but Xorg-7.7 has a dependency on libxkbfile which is missing in the 32-bit and 64-bit repos so Xorg is a non-starter.
libxkbfile and squashfs-tools copied over
libxkbfile-dev is still missing from the 32 and 64-bit repos.
-
Oops, sorry - they should be there now.
-
@curaga - do you mean add the wireguard module to the base or to wireguard-tools?
It's already in the base, I mean it can stay there.