Tiny Core v17.0

[Juanito]

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

Changelog for 17.0:
* kernel updated to 6.18.2
* glibc updated to 2.42
* gcc updated to 15.2.0
* binutils updated to 2.45.1
* e2fsprogs base libs/apps updated to 1.47.3
* util-linux base libs/apps updated to 2.41.2

* provides.sh: Update scripts to work with https mirrors from mbartlett21
* tce-update: Undo changes around fetchzsync from mbartlett21
* tc-functions: Update https checking from mbartlett21
* tc-functions: Change subshell from mbartlett21
* update-everything: Add /usr/local/bin to PATH from mbartlett21
* shutdown.sh: handle empty lines in /opt/.xfiletool.lst from mbartlett21
* 50-udev-default.rules: expanded input device permissions from bdantas

[Stefann]

No reactions after a week.
Just want to say: super thanks!
This week is quite busy, no time for updates.
Next week I will update my hp510 thin client with Via Eden dual core 1G 64bit processor.
If that is succesfull my ultra low power Via Eden 500MHz single core 32bit system will follow.
The latter is running my home control system so I need to be a bit careful. The first I use as staging system.

Having said that…
What is best way to upgrade?
Do I need to make a new usb installer and start from scratch?

Last time I just copied core.gz and vmlinuz. That would however not do anything with modules.gz.
I actually also donot know what modules.gz is good for.

I’m running tinycore in frugal mode booting from internal compact flashdrive.

[Juanito]

core.gz = rootfs.gz + modules.gz

You can replace core.gz and vmlinuz to update, but I would recommend using a different tce folder so that you don't have problems with old extensions that are no longer compatible.

[Rich]

Hi Stefann

... You can replace core.gz and vmlinuz to update, ...

In addition, you will need to replace any kernel module extensions you
are using, for example:

Code: [Select]

alsa-modules-KERNEL.tcz
filesystems-KERNEL.tcz
graphics-KERNEL.tcz
i2c-KERNEL.tcz
wireless-KERNEL.tcz
etc
Where the  KERNEL  part looks something like  6.12.11-tinycore.

A better plan would be to create a new tce directory as Juanito
suggested and download new copies of all of your extensions
from the TC17 repo.

You can simplify the process if you  cd  to the tce/optional/
directory you want to clone.
Then:

Code: [Select]

ls -1 *.tcz > Ext.lstThat's a  dash one  after  ls.
Move the  Ext.lst file to your new  tce/optional/  directory.

Grab a copy of the latest  FetchExt.sh  script from here:
https://forum.tinycorelinux.net/index.php/topic,23034.msg178902.html#msg178902
Place it in your new  tce/optional/  directory and make it executable.
Read the  Define Variables  section of the script, or run:

Code: [Select]

./FetchExt.sh -h
For  Intel  type processors run this:

Code: [Select]

KString="\-[0-9]+.[0-9]+.[0-9]+-tinycore.*.tcz"
sed -i -E 's|'$KString'|-KERNEL.tcz|g' Ext.lst
For  Arm  type processors run this:

Code: [Select]

KString="\-[0-9]+.[0-9]+.[0-9]+-piCore.*.tcz"
sed -i -E 's|'$KString'|-KERNEL.tcz|g' Ext.lst
Then run:

Code: [Select]

for F in $(cat Ext.lst); do ./FetchExt.sh "$F"; doneThat should populate your new  tce/optional/  directory with new
versions of all of your extensions.

[Stefann]

oops...
Thanks @rich...
however... I found some time and already started.

On my HP510 thin client with Via Eden 1GHz dual core 64bit processor
Im using the 32bit iso because this is the staging system for my ultra low power Via Eden 500MHz single core 32bit system
Its a frugal install from the internal compact flash
Its a headless system reachable by ssh & VNC with samba file-service

What I did:
1/
- download the core-17.0.iso to my MacBook
- copied core.gz to /mnt/sda1/tce/boot/core17.gz
- copied vmlinuz to /mnt/sda1/tce/boot/vmlinuz17
- changed /mnt/sda1/tce/boot/extlinux/extlinux.conf to boot from core17.gz & vmlinuz17
sudo reboot

==> succesfull!
==> both ssh & VNC connection work, samba works

2/
made copy of the tce/optional folder to make sure I can revert back.

3/
Using the VNC gui:
- apps, update
- process
wait about 10 minutes.
==> All successfully updates BUT some apps require python3.14 (was running on 3.9, coming from TC15)

4/
installed python3.14.tcz
==> success

5 (still to be done)/
Now I need to update some python3.9 modules I installed myself, will do that later

Question: so far so good? or do I need to revert back to step 2 and follow your guidance?

[Rich]

Hi Stefann

... Question: so far so good? or do I need to revert back to step 2 and follow your guidance?

Sounds like you have it under control.You said you ran
apps, update. There's an  update-everything  command
that handles it all in one shot.

[Stefann]

Thanks!

Yes I updated all in one go.
Used the corebook to help me.
In “normal live” I work from the commandline by ssh. But for these update things I like using the gui for reason it requires me to do a lot of things I very rarely do. And be aware that I’m absolutely not an expert.
The reason I asked is that I only marginally did understood your guidance.
And… I prefer understanding what I do, as that helps a lot when things go wrong.
Still thanks. I did reread it 5 times and I think I start to understand it (lol). Learning is fun.

So…
I did the apps update from the gui.
As indicated by the corebook you can select all apps together by selecting the first, holding shift, and selecting the last.


All in all….
I’m doing a much better job than last year. TC15-to-16.
Last year I only updated core.gz and vmlinuz. I was totally not aware that I should have done something with the apps. The initial reply from @juanito did guide me to that (thanks).

It’s all a bit tricky as the systems are headless. So if I loose them I have to physically unmount them and get a keyboard and monitor from the attic.

[thane]

I agree that burning a new 17.0 ISO DVD would have been the cleanest approach (which is what I've done in the past for major upgrades), but when I tried a found my last DVD burner has had it. So basically did what's suggested here (replaced core.gz, vmlinuz, kernel extensions, and did an update everything). Also did an update .dep files and found I had a couple of missing dependencies, and cleaned out a few that don't seem to be needed anymore. Working OK so far, but yes it wouldn't surprise me if there's a few loose ends...

thane

[GNUser]

What is best way to upgrade?

This is the way I do it, in 4 easy steps:

While running the old version of TCL (e.g., TCL16):

1. I replace /boot/corepure64.gz and /boot/vmlinuz64 with the new version from TCL17

2. I find the extensions that need to match the kernel version:

Code: [Select]

$ cd /etc/sysconfig/tcedir/optional
$ find . -name "*$(uname -r | sed 's/-.*//')*"I write down the above extensions on a piece of paper

3. I use Rich's  FetchExt.sh  script to download the new kernel-version-specific extensions into the  optional  directory. Make sure the  TC  and  ARCH  variables at the top of the script are correct (TC should be the new version that you are upgrading to) (FetchExt.sh can be obtained here: https://forum.tinycorelinux.net/index.php/topic,23034). For example:

Code: [Select]

$ cd /etc/sysconfig/tcedir/optional # if you just did step 2 above, you are already in the correct directory and don't need to do this  cd  again
$ FetchExt.sh graphics-KERNEL ipv6-netfilter-KERNEL # just an example--fetch all the extensions that you wrote down in step 2

At this point (with new corepure64.gz, new vmlinuz64, and new extensions that need to match the kernel version), you can go ahead and reboot. A normal reboot is all you need--you'll be running the new version of TCL after the reboot

After rebooting into the new version of TCL (e.g., TCL17):

4. When booting is complete, you just need to update the rest of the extensions (i.e., the non-kernel-version-specific ones), which can be done easily enough with one command:

Code: [Select]

$ update-everything

[Stefann]

Thanks all!

I'm learning a lot.

So basically:
- replacing core.gz & vmlinuz is enough to have the new linux version after reboot.
But....
- IF one is running kernel specific tcz extensions things will/may fail at reboot
So...
- One needs to make sure that any kernel specific tcz extensions are updated BEFORE reboot
---> kernel specific tcz extensions are recognised because their name ends with -#.#.#-tinycore with #.#.# being the kernel version.
---> update canNOT be done with the normal apps-update method because that updates *.tcz extensions to current kernel version and the objective is to update to the "kernel version after reboot".
---> update needs to be done with the fetch script made by Rich as referenced by both Rich & GNUser in previous posts.

After reboot linux is updated, but applications not yet.
- update applications after reboot:
---> either by the appstool in the guy
---> or by the tce-update command from command line

And while the above is enough to update, before doing the update:
- one may want to rename & keep the previous core.gz and vmlinuz
- one may want to copy the tce/optional directory to a backup location

Unrelated:
I'm happy to find python3.14 in TC17! I was still running 3.9 and already run into situations that a newer version was required.
It may have been in TC16 without me noticing because when I upgraded to TC16 last year I was not aware I should have done an application update as well.
So: thanks Juanito!

And also:
- I can confirm TC17 32bit x86 runs on Via Eden 1GHz dual core 64bit processor
(using 32 bit core.gz because this is staging system for my 32bit via eden system)

[Vaguiner]

please enable ntsync, it is a must have now

# CONFIG_NTSYNC is not set

[Juanito]

Is it still experimental?

[Rich]

Hi Juanito
No, it's not listed under  drivers/staging
It's under  drivers/misc/

[Stefann]

Well,
I updated my Via Eden 500MHz single core system.
I succeeded the upgrade and my homecontrol application is running agin.
- including samba, ssh and vnc so that is nice.

Some things....
1/
After updating the applications I got this error:

Code: [Select]

error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directoryI was able to fix that by adding libusb.tcz to the onboot.lst
The system is coming from TC15. with TC15 I only had libusb-compat-dev.tcz which apparently did load libusb.tcz as a dependancy but now it does not do that anymore.
Anyways... I got it fixed

[edit] NO... its not working. need to dig deeper

2/ rsyslog is not working
I'm starting it from bootlocal.sh and I tried to run it manual but than it complains its already running:

Code: [Select]

tc@huis:/opt$ sudo /usr/local/sbin/rsyslogd
rsyslogd: pidfile '/var/run/rsyslogd.pid' and pid 4789 already exist.However... nothing gets logged.

I did set debugging to level 2 in the rsyslog.conf file

Code: [Select]

$DebugFile /var/log/log_debug.txt
$DebugLevel 2 # 0=off, 2 = full debugAfter a reboot I indeed get an enormous /var/log/log_debug.txt file
However... nothing obviously wrong
But no logging

My rsyslog.conf file:

Code: [Select]

$WorkDirectory /var/log

$ModLoad imudp
$UDPServerRun 514
$ModLoad imtcp
$InputTCPServerRun 514
$ModLoad imklog
$ModLoad imuxsock

$template MyFormat,"%timegenerated:1:19% %msg:::drop-last-lf%\n"
$template FullFormat,"%timegenerated% %HOSTNAME% %syslogtag%%msg%\n"

$DebugFile /var/log/log_debug.txt
$DebugLevel 2 # 0=off, 2 = full debug

#example
# $outchannel log_rotation,/var/log/log_rotation.log, 52428800,/home/me/./log_rotation_script
#  activate the channel and log everything to it
# *.* :omfile:$log_rotation
#
# /home/me/log_rotation_script:
# mv -f /var/log/log_rotation.log /var/log/log_rotation.log.1

# ------------- User section -------------------
# max 100k debugfile = 1000 lines x 100chars

# Need script: /var/log/rotate:
# tail -n 500 /var/log/${1} > /var/log/${1}.tmp
# cat /var/log/${1}.tmp > /var/log/${1}
# rm -f /var/log/${1}.tmp

# Heat Control: HeatPump and CV
$outchannel heat_log, /var/log/heatlog.txt,  100000, /var/log/rotate heatlog.txt
local1.=info   :omfile:$heat_log;MyFormat


# Solar Thermal
$outchannel solar_log,/var/log/solarlog.txt, 100000, /var/log/rotate solarlog.txt
local1.=notice :omfile:$solar_log;MyFormat

# Main (normal main logging)
$outchannel main_log, /var/log/mainlog.txt,  100000, /var/log/rotate mainlog.txt
local1.=debug  :omfile:$main_log;MyFormat

# EVSE
$outchannel evse_log, /var/log/evselog.txt,  100000, /var/log/rotate evselog.txt
local2.=notice  :omfile:$evse_log;MyFormat

# Weather
$outchannel weather_log, /var/log/weatherlog.txt,  100000, /var/log/rotate weatherlog.txt
local3.=notice  :omfile:$weather_log;MyFormat

# PV, enphase and solaredge
$outchannel PV_log, /var/log/PVlog.txt,  100000, /var/log/rotate PVlog.txt
local3.=info  :omfile:$PV_log;MyFormat

# Debug, catch all that have not been catched before
$outchannel debug_log,/var/log/debuglog.txt, 100000, /var/log/rotate debuglog.txt
Any tips??

[edit]
I reverted back to original /mnt/sda1/tce/optional folder
So running TC17 updated core.gz and vmlinuz only. no tcz extension updates.
==> this runs fine!
libusb and rsyslog both working

[Stefann]

Note,
on the libusb...
I have the feeling the file "may be there", in /usr/local/lib
But can probably not be found in runtime.
I checked and the libusb tcz applications did not change (did they?)
So its probably a search path

I cannot check this assumption at this moment because I reverted back for reason the system is running my home automation and I cannot leave that in a non-functional state. I will need to find time to continue tomorrow.

But..... anyone who triggers on this and has some hint towards "search path" on /usr/local/lib libraries is welcome.
Note... I cannot imagine it's the gcc compiler as I'm not compiling anything. I'm just running an executable that can suddenly not find the libusb-1.0.so.0