Tiny Core Base > TCB Talk
Re: Tiny Core v17.0 upgrade issues
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: ---error while loading shared libraries: libusb-1.0.so.0: cannot open shared object file: No such file or directory
--- End code ---
I 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: ---tc@huis:/opt$ sudo /usr/local/sbin/rsyslogd
rsyslogd: pidfile '/var/run/rsyslogd.pid' and pid 4789 already exist.
--- End code ---
However... nothing gets logged.
I did set debugging to level 2 in the rsyslog.conf file
--- Code: ---$DebugFile /var/log/log_debug.txt
$DebugLevel 2 # 0=off, 2 = full debug
--- End code ---
After 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: ---$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
--- End code ---
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
Juanito:
Ref:
--- Code: ---cat /etc/ld.so.conf
/usr/local/lib
--- End code ---
..tells the loader to look in /usr/local/lib as well as /lib and /usr/lib, which are searched by default.
If a library has been manually added the following command is required before the library will be found:
--- Code: ---sudo ldconfig
--- End code ---
Stefann:
Thanks,
It’s strange because “just upgrading core.gz and vmlinuz” works. It derails with the application update.
I will have to go step by step tomorrow.
Takes quite some time because after each step I need to reboot and carefully test.
A full application update is also not superfast. Took about 20 mins today.
I will post progress.
Stefann:
SOLVED!!
[edit] almost... usb-serial is not working now but it worked earlier
sooo.....
My target system is a Via Eden 500MHz single core very low power 32bit cpu running my home automation.
I also have a dual core Via Eden 1GHz cpu system that I normally use as test system.
I had TC17 already running on that test system but had not verified libUSB and rsyslog.
So what I did today:
- bring latest version of my application to the test system and try to run it on TC17
- it appeared to work with both libUSB and rsyslog.
==> Now I got suspicious towards update corruption on my target system
I did a compare of onboot.lst between the systems -> they where identical
I did a compare of the tce/optional folder between systems -> that did show major differences
I copied tce/optional folder from test system to target system
I did a reboot of target system
BANG.... all working. Application fully runs. rsyslog works. libUSB works
So...
What I suspect...
- To do the application update on the target system I used the gui over VNC as I donot feel very comfortable with the command line commands for apps-maintenance.
- the gui over vnc however already takes 40% cpu load of this "not so powerful 500MHz single core cpu"
- running the apps update took about 20mins during which the gui was completely frozen
- Afterwards I did a recheck on update and "it showed no lost items"
But....
- I expect the upgrade process had issues
- and although the gui for apps-maintenance is handy, with this slow processor it does not allow proper checking of logging on "whether all went ok"
- issues I wold consider "not super strange". I basically ran the system on close to 100% cpu use for 20mins. Disk being a compact flash card.
Anyways... result...
I can confirm TC17 runs on Via Eden 500MHz 32bit single core cpu
- including samba
- including ssh
- including vnc
- including libUSB
- including gcc (yes I tested a recompile of some part)
- including rsyslog
[edit]
still problem with usb-serial-6.18.2-tinycore.tcz kernel extension
I used to get text-data but when I run
cat /dev/ttyUSB0
I now get binary characters.
I guess it has something to do with settings
It's a bit strange as this 6.18.2 version DID work on TC17 core.gz and vmlinuz before I did upgrade all other apps.
I will figure this out I think
---------
Thanks for the replies & reading,.. I was a bit stuck yesterday.
Upgrading is always kind of a headache as its is a quite "big" thing
Very beneficial about upgrading of tinycore is that a simple rename of core.gz, vmlinuz, tce/optional and tce/onboot.lst allows you to switch between upgrade and original. VERY convenient!!!!
going forward..
- On a next update I will use the command line tools.
- That will give me better logging
- and NOT consume 40% cpu for vnc
Navigation
[0] Message Index
[#] Next page
Go to full version