Tiny Core Linux
Tiny Core Base => TCB News => Final Releases => Topic started by: Juanito on February 22, 2024, 11:34:02 AM
-
Team Tiny Core is proud to announce the release of Core v15.0
http://www.tinycorelinux.net/15.x/x86/release
http://www.tinycorelinux.net/15.x/x86_64/release
Changelog for 15.0:
* kernel updated to 6.6.8
* glibc updated to 2.38
* gcc updated to 13.2.0
* binutils updated to 2.41
* e2fsprogs base libs/apps updated to 1.47.0
* util-linux base libs/apps updated to 2.39.2
* zlib base lib updated to 1.3
* busybox updated to 1.36.1
* tce-functions/setdrive/setup: use : in chown
* tce-audit: add md5check action from bdantas
* tce-audit: md5check update from bdantas
* tce-load: sudo touch from polikuo
* update-everything: handle missing or extraneous dep files from bdantas
* tce-update: allow tcedir/optional to be a symlink from bdantas
* update-everything: add safety checks from bdantas
* busybox CONFIG_FEATURE_EDITING_HISTORY changed 150 -> 1000
-
Congratulations to the team on another solid release!
Just one cosmetic thing: /etc/os-release in corepure64.gz (I tested CorePure64-15.0.iso only) needs to be updated:
$ cat /etc/os-release
NAME=TinyCore
VERSION="15.0beta1"
ID=tinycore
VERSION_ID=15.0beta1
PRETTY_NAME="TinyCoreLinux 15.0beta1"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:tinycore:tinycore_linux:15.0beta1"
HOME_URL="http://tinycorelinux.net/"
SUPPORT_URL="http://forum.tinycorelinux.net/"
BUG_REPORT_URL="http://forum.tinycorelinux.net/"With current /etc/os-release, boot message says 15.0beta1 is booting when I am in fact booting version 15 final release.
-
I'm not sure what happened there, hopefully OK now..
-
Hi Juanito. Yes, looks good now :) Thanks!
-
Hi,
first, thanks for TinyCoreLinux. And of course the 15th release!!!
I signed up to the forum as fast as I could (I *hate signing up* but I've been a daily driver for some 4 years by now).
Why, did i hurry? It would be horrible if TinyCore 15 release ISO would be forever bugged with the broken busybox 1.36.1 !!
WHAT is broken? it is what I call the 'double prompting' (or dual prompting) bug.
It is not always consistent but happens for every linux that I or others have tried (that includes folk in the busybox irc channel). There is however a sure way to replicate the bug consistently:
tce-load -wil links
this will install links2 browser. Start it (command-line), and just use CTRL+Z to send the job to the background. Et voila: 2 prompts with about 1 second in between (it is of course fun to execute partial commands...).
On other machines i currently use 1.36.0 (the ready static compiled release) for this reason.
please, something, anything. don't let 15 ISO go into history with the dual prompting bug!
-
When I read this, I think of the shell's "readline", and that are using in app links.
-
Gtk3-dev for 32-bit doesn't look for colord now, but it is looking for tiff-dev, which isn't in the repository. In 32-bit land I think it wants libtiff-dev.
-
I believe that was due to an error in the gdk-pixbuf2-dev dep file, which was corrected a few days back - the gtk3-dev tree file does show any instances of tiff-dev.
-
This is what I'm seeing:
tc@box:~$ cd /etc/sysconfig/tcedir/optional/
tc@box:/etc/sysconfig/tcedir/optional$ rm gtk3-dev.tcz.dep
rm: remove 'gtk3-dev.tcz.dep'? y
tc@box:/etc/sysconfig/tcedir/optional$ tce-load -iwl gtk3-dev
gtk3-dev.tcz.dep OK
Downloading: tiff-dev.tcz
Connecting to distro.ibiblio.org (152.19.134.43:80)
wget: server returned error: HTTP/1.1 404 Not Found
md5sum: tiff-dev.tcz.md5.txt: No such file or directory
Error on tiff-dev.tcz
tc@box:/etc/sysconfig/tcedir/optional$
-
downloaded http://www.tinycorelinux.net/15.x/x86_64/release/TinyCorePure64-15.0.iso yesterday. (yes, good checksum)
today i had time to write it to a thumbdrive and it fails to bring up the gui and reports "failed in waitforX"
tried it in both a lenovo y580 and a thinkstation a20 with the same results
rewrote the stick just to double-check and had no change/improvement
rewrote the stick back to tcl14 just to prove my stick and methods
mostly i wanted to get this posted in case someone else has the same problem(so they know they aren't alone).
will investigate more as additional time becomes available.
as always, huge kudos and thanks to the whole tcl team!
-
Did you check your local copy of gdk-pixbuf2-dev.tcz.dep?
-
Instead of startx, enter the first line of .xsession to troubleshoot.
-
Hi gadget42
... i had time to write it to a thumbdrive and it fails to bring up the gui and reports "failed in waitforX" ...
At that time you are at the command prompt. If you now enter:
startxDoes the GUI come up? If it does, it's a timing problem, and
here are two ways of addressing it.
You can insert a time delay as described here:
https://forum.tinycorelinux.net/index.php/topic,26391.msg170331.html#msg170331
Or you can set up a loop that waits for your graphics card as described here:
https://forum.tinycorelinux.net/index.php/topic,26391.msg170335.html#msg170335
-
Did you check your local copy of gdk-pixbuf2-dev.tcz.dep?
That was it. Thanks.
-
When I read this, I think of the shell's "readline", and that are using in app links.
What precisely is the issue if I may ask? What are the 'app links' ?
As for the broken busybox 1.36.1 shell (the double prompt bug),
In cases where users can not remaster the iso (for what-ever reason, such as their vps host only allowing official distribution media, or simply because they find it complicated enough already to just dd the iso onto their usbstick), I see no way how to replace it and work around the issue.
By the time we get our first and seemingly only chance to slip something in (the httplist boot parameter), busybox shell is already in use.
IF there is no way to fix it, that it is to late to change the official iso, I fear those users will have to resort to an additional separate static busybox-ash that is not version 1.36.1 for their prompt (though a bunch of native tools and scripts are set to 'busybox ash' and thus wouldn't trigger their separate standalone busybox ash, I think. I'm just trying to think of solutions here... (in case it is to late to fix the release/iso)).
Edit: Or learn to wait a good second before typing your next command (in case your current prompt just suddenly ends (holding the first part of what you typed) and new prompt appears).
-
from reply#9(https://forum.tinycorelinux.net/index.php/topic,26861.msg173024.html#msg173024)
continued troubleshooting by @Juanito suggestion "Instead of startx, enter the first line of .xsession to troubleshoot."
...
Xfbdev: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory
tc@box:~$ ldd /usr/local/bin/Xfbdev
...
libpcre.so.1 => not found
...please advise at your convenience(naturally/humbly)
-
Hmm - I suspect that it’s one of the deps of Xfbdev that has a dep on pcre - I’ll take a look tomorrow.
-
temporary fix at my end:
tce-load -w -i pcre.tcz and startx works fine.
-
libXfont had a dep on pcre masked by glib2, which also used to have a dep on pcre.
libXfont will compile without pcre, but then doesn't want to work.
libXfont dep adjusted and TinyCorePure iso rebuilt.
-
@Juanito, thanks for the update and all your wonderful works!
-
..to add to the puzzle, the x86 libXfont doesn't have a dep on pcre and it works...
-
..to add to the puzzle, the x86 libXfont doesn't have a dep on pcre and it works...
while researching another topic i came across one of your posts from a few years ago that might be a clue?
32-bit uses Xvesa not Xfbdev
-
Both Xvesa and Xfbdev use libXfont (as opposed to libXfont2) and I tested with Xfbdev in both 32/64bit.
-
Yet another minor hiccup, i2c-hid.ko seems to have gained a dependency on driver/gpu/drm_panel.ko? in the new kernel.
Sadly this breaks the trackpad on my laptop :(
I am running corepure64.
Trying modpobe i2c-hid puts:
i2c_hid: Unknown symbol drm_panel_remove_follower (err -2)
...
in dmesg, and I have forgotten how to paste from a terminal window into firefox, so I am typing it in.
-
From this:
grep DRM_P config-6.6.8-tinycore
CONFIG_DRM_PANEL=y
# CONFIG_DRM_PANEL_AUO_A030JTN01 is not set
# CONFIG_DRM_PANEL_ORISETECH_OTA5601A is not set
# CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN is not set
# CONFIG_DRM_PANEL_WIDECHIPS_WS2401 is not set
CONFIG_DRM_PANEL_BRIDGE=y
# CONFIG_DRM_PANEL_MIPI_DBI is not set
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
CONFIG_DRM_PRIVACY_SCREEN=y
..you'd think the module was compiled in - @curaga?
-
Hi Juanito
CONFIG_DRM_PANEL and friends are set to yes so they are compiled in.
In TC15:
CONFIG_I2C_HID=y
CONFIG_I2C_HID_ACPI=m
# CONFIG_I2C_HID_OF is not set
CONFIG_I2C_HID_CORE=mACPI and CORE are modules.
i2c-hid is compiled in and should not show up as a module.
In TC14:
CONFIG_I2C_HID_ACPI=y
# end of I2C HID support
CONFIG_I2C_HID_CORE=yACPI and CORE used to be compiled in and CONFIG_I2C_HID didn't exist.
I unpacked TC15 corepure64.gz and modules64.gz and they both
contained i2c-hid.ko.gz.
-
That symbol seems to be in drm.ko. Which is unfortunate, because it's big and depends on agpgart too, adding both to base would mean a ~200kb increase. You'll need to install the graphics- extension, I'm afraid.
-
In TinyCorePure64 15.0 on my PC, alsa settings are not being preserved between boots.
I don't know how significant it is, but in 15.0 the permissions and owner settings for bootlocal.sh and bootsync.sh are different from what they were in 14.0 e.g. 15.0 has owner root:root and 14.0 has root:staff.
I'll keep fiddling.
thane
-
What commands are you using to store and restore your settings?
-
I followed tthe alsa.tcz info:
after adjusting alsamixer settings, did "sudo alsactl store";
added "usr/local/etc/alsa/asound.state" to opt/filetool.lst;
added "sudo alsactl restore" to opt/bootlocal.sh
No quotes in the actual text, of course.
Thane
-
If you store your settings then manually edit asound.state to change them and then restore without rebooting do the settings change?
-
The problem was here:
sudo alsactl store
[edit /usr/local/etc/alsa/asound.state]
sudo alsactl restore
alsa-lib parser.c:2783:(load_toplevel_config) Unable to find the top-level configuration file '/usr/local/etc/alsa/ucm2/ucm.conf'.
alsa-config adjusted and reposted
-
Hi Juanito, alsa settings are still not being saved between boots. Specifically it's the 'Master' setting not being saved. It looks like asound.state file is being updated when I do "sudo alsactl store" but after I reboot, alsamixer shows the original (muted) setting is back. Don't know what to look for in the asound.state file to see if the setting was actually updated there.
Not 100% sure this is an alsa issue (maybe I'm overlooking something in the save/restore process) since the asound.state file is the only thing I'm saving/restoring other than home and opt. Anyway I can work around this for now.
Thane
-
Hi thane
... It looks like asound.state file is being updated when I do "sudo alsactl store" but after I reboot, alsamixer shows the original (muted) setting is back. ...
If you open a terminal and enter:
sudo alsactl restoredoes it throw any errors or restore the correct volume level?
-
Well, this is embarrassing. Now the alsamixer settings save and restore. Since I tried it last I installed flaxpdf.tcz, gpicview.tcz, as well as evince.tcz (but deleted it later).
gpicview.tcz had a missing library error (libGLESv2) which I was going to report. Installing the libGLESv2.tcz extension fixed it, but probably a .dev file needs to be corrected.
Now I'm wondering if alsa (or alsa-config) might have a library issue too that one of the installs inadvertently corrected.
Sheesh.
thane
-
gpicview.tcz had a missing library error (libGLESv2) which I was going to report. Installing the libGLESv2.tcz extension fixed it, but probably a .dev file needs to be corrected.
cairo used to have a dep on libGLESv2, which masked the gtk2 dep on libGLESv2 - gtk2 dep file adjusted.
Now I'm wondering if alsa (or alsa-config) might have a library issue too that one of the installs inadvertently corrected.
You would see an error message if that were the case.
-
Hi Juanito, I agree about the error message, but it bothers me a bit when problems seem to fix themselves! Reverse cosmic rays...
Thanks to you and Rich for the help!
thane
-
See what i found on the web:
https://youtu.be/206f7nX4IGo (https://youtu.be/206f7nX4IGo)
-
Hi curaga
I know it's too late for this version, but I wonder if there's
any reason not to include a /lib64->/lib link in the x86_64
rootfs64.gz.
firefox_getLatest.tcz includes a command in the tce.installed
file for firefox to create that link.
This is a partial list of problems forum members had due
to /lib64 not being present:
https://forum.tinycorelinux.net/index.php/topic,21993.msg173865.html#msg173865
https://forum.tinycorelinux.net/index.php/topic,26512.msg171207.html#msg171207
https://forum.tinycorelinux.net/index.php/topic,26326.msg169980.html#msg169980
https://forum.tinycorelinux.net/index.php/topic,26342.msg169821.html#msg169821
https://forum.tinycorelinux.net/index.php/topic,26113.msg167596.html#msg167596
https://forum.tinycorelinux.net/index.php/topic,25633.msg164427.html#msg164427
-
It's just a matter of style. lib64 is ugly, and only required by external binaries. If you'd like to have it in, fine by me.
-
Perhaps because some distros are moving to 64bit only, less external binaries seem to require the symlink.
There's also the (small) risk that, if the symlink is included in the base, source compiled on tinycore will link against /lib64/ld-linux-x86-64.so.2
-
Hi Juanito
Thanks for the info. Leave it the way it is then.
-
There's also the (small) risk that, if the symlink is included in the base, source compiled on tinycore will link against /lib64/ld-linux-x86-64.so.2
This would be my concern. I get that it's a problem for some apps not compiled on TC, but is that really our problem? It seems like a tar pit that will just bring in other problems. If an external app needs the loader in /lib64 instead of /lib, there should be a script in the extension's tce.installed directory to take care of it then. At least that's how I've handled apps like Google Earth and Chrome.
-
Is there any (easy, I hope!) way to get the version number for all of the TCZ packages? I've been given a list of CVE numbers and I need to ensure that none of them reference packages we will be using in TinyCore. I looked at http://tinycorelinux.net/15.x/x86/tcz/, but (for example) the only zlib mention there is "zlib_base-dev.tcz", which doesn't show me that zlib is v1.3, which is what I need.
I thought the tcz link in the sources would've taken me to the tcz sources (which would have the version info), but it just displayed the text file listing all the tcz names.
-
http://www.tinycorelinux.net/15.x/x86/tcz/zlib_base-dev.tcz.info shows the version number is 1.3?
-
http://www.tinycorelinux.net/15.x/x86/tcz/zlib_base-dev.tcz.info shows the version number is 1.3?
Yes, it does. Does that mean I will need to go through all the packages, one at a time, and manually construct links link the one above in order to see the version info?
I can do that, I was just hoping there was an existing list somewhere. Oh well, thanks.
-
See attached for tc-15.x x86
-
Wow! Thanks, that is exactly what I was hoping to find!
-
Hi Juanito
Your version also captured entries from the
Change Log section like this:
aspell-dev.tcz Change-log: 2009/09/02 First Version by perthie
If you grep like this:
grep -E "^Version:" path/*.infoyou'll only get lines that begin (no white space) with "Version:".
-
Thanks - I’ll add that to my useful grep list 🙂