Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: Stefann on May 02, 2025, 05:31:58 AM
-
Hi,
I hope I do this right but anyway...
When I startup tiny core the time is not synced.
running getTime.sh as user also does not sync it
running with sudo does
What I did:
Give clock a 3minute error, than REBOOT....
tc@hp510:~$ sudo reboot
==================
after reboot:
tc@hp510:~$ date
Fri May 2 13:20:09 CEST 2025. //this is wrong
tc@hp510:~$ getTime.sh
tc@hp510:~$ date
Fri May 2 13:20:21 CEST 2025. //still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Fri May 2 11:18:06 CEST 2025. //OK now
tc@hp510:~$
For reference, my extlinux.conf:
DEFAULT gui16
LABEL gui16
KERNEL /tce/boot/vmlinuz16
INITRD /tce/boot/core16.gz
APPEND quiet host=hp510 tz=CET-1CEST,M3.5.0,M10.5.0/3 waitusb=5:UUID="ab0b387d-7533-4e69-a8ac-ee5ab733c5f7" tce=UUID="ab0b387d-7533-4e69-a8ac-ee5ab733c5f7"
tested on TC16
also tested on TC15 >> same behaviour
In itself this is not a big deal, I can easily add sudo getTime.sh to boot local.sh
Just want to understand whether I do something wrong
-
It runs automatically if you are using dhcp for your network. But it will timeout after 60s if the network does not have an address.
If you use a static network configuration, the you need to manage it all manually.
-
As far as I understand (I'm not a guru) I'm using dhcp:
- I'm assigning it a fixed address from my router but I consider that dhcp (right?)
- I have no config files in .filetool.lst, only network related is "usr/local/etc/httpd/httpd.conf" but that is apache only I think.
- also not other files in /opt or /opt (but I may overlook something)
And I'm booting below 60seconds:
- I'm booting in 39seconds towards a ssh prompt
So I feel "it should have worked" out of the box.
Note: running 32bit version on 64bit Via Eden cpu
Any "tip" on how to debug this further?
> like "where is it called" such that I can potentially check a bit what happens.
mmmh... maybe I should modify the getTime.sh such that it creates a logging
-
It’s not the boot time, it’s how long it takes for you to get a network address. ntp is also not instantaneous when syncing a time.
It’s called from /etc/init.d/tc-config. (Near the end). /etc/inti.d/settime.sh is what gets called.
-
thanks,
I'll check what happens.
ehh... if I got an ssh connection from a remote computer 39seconds after start, the network connection should also have been there within that 39seconds.
Anyway... no worry... I'll figure that out.
thanks for pointing me into a direction
(expect it to take a day or so before I have an update)
-
Hi Stefann
If you want a way to log whether your network is up or down:
tc@E310:~$ echo "$(date | tr '\n' ' ' && ifconfig | grep -q Bcast && echo Up || echo Down)"
Fri May 2 09:30:33 UTC 2025 Up
tc@E310:~$If the network was down, it would have printed:
Fri May 2 09:30:33 UTC 2025 Down
Just place something like this where ever you want to test the networks status:
echo "$(date | tr '\n' ' ' && ifconfig | grep -q Bcast && echo Up || echo Down)" >> /tmp/Network.log
-
Since he can ssh in, I suspect the problem is with name resolution of the ntp server, or ntp just being slow.
-
Hi Paul_123
Since he can ssh in, ...
You're probably right, I just wanted to offer a simple command for
logging network status.
-
1st: thanks Rich for the code-snippets, I'm not good at shell language so it gave a me a toolbox. Thnaks.
With that said...... I did some testing.
My main conclusion: time will only be updated at boot if clock battery is dead.
What i did:
Test1: set date to 1jan 2010 and try to run getTime.sh with sudo >> succeeds
I did not expect that, if i understand man-page correct it needs option -g to succeed with offset above 1000secs
But anyways.... this proofs getTime.sh always updates time even if it's a really big delta
tc@hp510:~$ sudo date 010101012010
Fri Jan 1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan 1 01:01:03 CET 2010
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 08:01:27 CEST 2025
Test2: set date to 1jan 2010 and try to run settime.sh with sudo >> succeeds
Note: command took about 3seconds to run (not precise, just counted out loudly)
tc@hp510:/etc/init.d$ sudo date 010101012010
Fri Jan 1 01:01:00 CET 2010
tc@hp510:/etc/init.d$ date
Fri Jan 1 01:01:03 CET 2010
tc@hp510:/etc/init.d$ sudo ./settime.sh
tc@hp510:/etc/init.d$ date
Sat May 3 08:06:01 CEST 2025
Test3: set date to 1jan 2016 and try to run settime.sh with sudo >> fails
No update (command now takes only a split second)
tc@hp510:/etc/init.d$ sudo date 010101012016
Fri Jan 1 01:01:00 CET 2016
tc@hp510:/etc/init.d$ date
Fri Jan 1 01:01:02 CET 2016
tc@hp510:/etc/init.d$ sudo ./settime.sh
tc@hp510:/etc/init.d$ date
Fri Jan 1 01:01:12 CET 2016
Test4: set date to 1jan 2010 and reboot >> succeeds
Alike test 1 set date to 1jan 2010, reboot.
now time is properly updated.
Analysis/rootcause:
below codesnippet of settime.sh shows it checks whether current date is later than 2015 and breaks without setting date if it is:
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
if [ "$XXX" -ge "2015" ];
then
break
fi
This effectively means:
- if clock battery is dead there will be a time update.
- if clock battery is "ok" there will not be a time update.
Whether this is wanted or unwanted behavior is open for discussion.
To be honest, as the update adds 3 seconds to the boot-time (or is it done in the background???) I'm totally ok that it does not.
This implies however that i will need to call sudo getTime.sh regularly with a crontab.
Note: I hope i did everything correct
for completeness & easy reference: full content of settime.sh
tc@hp510:/etc/init.d$ cat settime.sh
#!/bin/sh
# (c) Robert Shingledecker 2012
# Bela Markus 2015
# Wait for network to come up and then set time
CNT=0
until ifconfig | grep -q Bcast
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
if [ "$XXX" -ge "2015" ];
then
break
fi
if [ $CNT -gt 10 ];
then
/usr/bin/getTime.sh
if [ $NRT -gt 5 ];
then
break
fi
CNT=0
NRT=$((NRT+1))
fi
CNT=$((CNT+1))
sleep 1
done
fi
-
update......
no... its a bit different.
yes, test1,test2,test3 are as I said.
however test4 is slightly different....
test4/redo: set clock to 2010 and reboot >> clock is updated to 2025 BUT has 2h03m offset
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 10:17:06 CEST 2025 // note: this is correct
tc@hp510:~$ sudo date 010101012010
Fri Jan 1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan 1 01:01:03 CET 2010
tc@hp510:~$ sudo reboot
.........wait........
tc@hp510:~$ date
Sat May 3 12:23:55 CEST 2025 // this is roughly 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 12:24:03 CEST 2025 // even after time update that succeeded earlier still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 10:21:18 CEST 2025 // after an other time update it is correct now
tc@hp510:~$
test5, set clock to 2016 and reboot >> strangely enough, time is updated (???) also with 2h03m offset
strange, so settime.sh I demonstrated to NOT update with year=2016 but now it updates
And again 2h03m wrong
and again time only corrects after second getTime.sh call
tc@hp510:~$ sudo date 010101012016
Fri Jan 1 01:01:00 CET 2016
tc@hp510:~$ date
Fri Jan 1 01:01:01 CET 2016
tc@hp510:~$ sudo reboot
.........wait........
tc@hp510:~$ date
Sat May 3 12:29:11 CEST 2025 // again... roughly 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 12:29:23 CEST 2025 // again... even after time update that succeeded earlier still wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 10:26:20 CEST 2025 // again... after an other time update it is correct now
tc@hp510:~$
I post this now as "intermediate status"
I will think about how to move on this further.
I guess /etc/init.d/tc-config calls even other stuff.
I will look further but "hints" are welcome
-
test6, reboot on other computer I have from correct time >> 8minute offset after reboot
note: this computer is much slower takes much more time to reboot
note: this is actually my production system that runs my homecontrol system, normally donot like to test on it.
tc@huis:/krubo/work$ date
Sat May 3 10:43:05 CEST 2025 // this is correct time
tc@huis:/krubo/work$ sudo reboot
....wait....
tc@huis:~$ date
Sat May 3 10:54:39 CEST 2025 // this is about 8minutes wrong
tc@huis:~$ sudo getTime.sh
tc@huis:~$ date
Sat May 3 10:46:33 CEST 2025 // correct after 1x sudo getTime.sh
tc@huis:~$
back to my hp510 computer
note, this is a hp510 thin client, I use that as my staging system
modified settime.sh to add some logging.
included it in .filetool.sh
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
echo "end ifconfig check" >> /tmp/time.txt
echo $CNT >> /tmp/time.txt
if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
echo $XXX >> /tmp/time.txt
test7; reboot from correct time >> wanted to catch logging in time.tx but no logging is generated
tc@hp510:~$ date
Sat May 3 11:13:56 CEST 2025 //this is correct time
tc@hp510:~$ sudo reboot
.... wait .....
tc@hp510:~$ date
Sat May 3 13:19:16 CEST 2025 //again 2h03m wrong
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 13:19:28 CEST 2025 //again still wrong after 1x getTime.sh
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 11:16:25 CEST 2025 //correct after 2x getTime.sh
tc@hp510:~$ cd /tmp
tc@hp510:/tmp$ ls
aberr appserr k5_skip tce/ tcloop/ wm_errors
//????? no time.txt logfile?????
tc@hp510:/tmp$ cat /etc/init.d/settime.sh. //check that indeed modified settime.sh survived the reboot >> yes it did
#!/bin/sh
# (c) Robert Shingledecker 2012
# Bela Markus 2015
# Wait for network to come up and then set time
CNT=0
until ifconfig | grep -q Bcast
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
echo "end ifconfig check" >> /tmp/time.txt
echo $CNT >> /tmp/time.txt
if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
echo $XXX >> /tmp/time.txt
..........
ok... at this point a give it some rest
maybe later
maybe tomorrow
things need to sink in a bit and I have some other obligations.
-
ok...
I checked /etc/init.d/tc-config. (Near the end) and gave it a careful read > thanks Paul_123 for guiding me there
tc-config code snippet:
# After restore items
if [ -n "$NODHCP" ]; then
echo "${GREEN}Skipping DHCP broadcast/network detection as requested on boot commandline.${NORMAL}"
else
[ -z "$DHCP_RAN" ] && /etc/init.d/dhcp.sh &
[ -z "$NORTC" ] || /etc/init.d/settime.sh &
fiThis means that settime.sh will only be called IF nortc bootcode is set!
(mhh... to some point this is funny, that is actually the title of this thread :-) )
so... I included nortc bootcode...
test8, reboot from 2020 with nortc bootcode >> confirm settime.sh is executed; getTime.sh is not called
It becomes understandable:
- with nortc bootcode indeed settime.sh is called
- this takes 6 seconds to "wait for ifconfig >> which means that I "not really like to include this" in my boot sequence
- before calling getTime.sh it checks /bin/date -I, that returns a "2025" and resultantly getTime.sh is NOT called as was already identified in test3.
tc@hp510:~$ sudo date 010101012010
Fri Jan 1 01:01:00 CET 2010
tc@hp510:~$ date
Fri Jan 1 01:01:02 CET 2010. //so indeed set system to 2010, before the 2015 check
tc@hp510:~$ sudo reboot
.....wait....
tc@hp510:~$ date
Sat May 3 13:52:29 CEST 2025. //so time is updated to 2h03m wrong version
tc@hp510:~$ cd /tmp
tc@hp510:/tmp$ ls -l time.txt
-rw-r--r-- 1 root root 26 May 3 13:51 time.txt //yes, logging has been written now, so settime.sh has been called
tc@hp510:/tmp$ cat time.txt
end ifconfig check
6 //so ifconfig is detected after 6 loops of 1 second
2025 //so bin/date command gave 2025 year. and that means that getTime.sh is not called
What I think happens....
- setTime.sh sets the systemclock but NOT the HW clock.
- so on my one system I get 2h03m offset form HW clock at boot; on my other system I get 8min offset from HWclock.
text9, check HW clock >> indeed looks like hwclock is the bad guy
tc@huis:~$ sudo getTime.sh // make sure to have correct time
tc@huis:~$ date
Sat May 3 12:15:37 CEST 2025. // yes time is correct
tc@huis:~$ sudo hwclock --systohc //sync hwclock
tc@huis:~$ hwclock
Sat May 3 12:15:50 2025 0.000000 seconds. //hwclock is correct
tc@huis:~$sudo reboot
.... wait .....
tc@hp510:~$ date
Sat May 3 14:17:47 CEST 2025 //this seems 2h off
tc@hp510:~$ date
Sat May 3 14:18:12 CEST 2025
tc@hp510:~$ sudo getTime.sh
tc@hp510:~$ date
Sat May 3 12:18:20 CEST 2025. //so yes, it was 2hr off.. but... no longer 2hr03mins, I guess this is caused by timezone thing
tc@huis:~$sudo reboot. //try new reboot
.....wait....
tc@hp510:~$ hwclock
Sat May 3 12:22:12 2025 0.000000 seconds
tc@hp510:~$ date
Sat May 3 14:22:15 CEST 2025 // so yes, hwclock is correct, system time is not
So...
- unless nortc bootcode is set no time sync is done at all
- with nortc bootcode settime.sh is called but before calling getTime.sh the hardware clock is checked and unless it reports before 2015 getTime.sh is not called
- using "sudo hwclock --systohc" syncs the hw clock but does not properly take timezone into account >> I guess this is simply intended behaviour, just my ignorance on this.
For now I give it some rest.
things needs to sink in
-
looks like I need to use:
hwclock --systohc --utc
Which means.. overall conclusion (in case you got lost):
- if no nortc bootcode is set the clock will be updated from hw clock and NOT read from internet, settime.sh is not called, getTime.sh is also not called
- if nortc bootcode is set AND if dhcp is used, settime.sh is called.
- settime.sh takes (at least at my system) 6 seconds to wait for ifconfig, so this delays your boot (but it is called with "&" so nonblocking)
- settime reads hw lock and only calls getTime.sh IF hwclock reports before 2015. --> effectively: only with dead battery.
In practice this means that almost always you boot with hwclock without sync with internet.
In principle this works for me. I like that bootcycle is not unnecessary long.
It does however mean that some time-sync method needs to be there.
This can be by a regular crontab call of getTime.sh but:
- this does not set the hardware clock
- it does not have a safety mechanism for "unrealistic big offsets", the "must-be-in 1000sec window" behaviour is not present (maybe because of -q option, but that I don't know)
- in fact..... probably run ntpd daemon "the way it is intended" and not use the -q option, and sync hw clock weekly with a crontab
-
I’m a piCore guy, which uses nortc by default.
When I last checked ntpd will sync the hwclock if running as a daemon.
-
Well.... after many tests I figured it all out. Conclusion towards those also wanting to keep time uptodate.......
- and thanks Paul_123 for pointing me into directions including mentioning ntpd syncs hwclock
1/ bootoption nortc ONLY updates time from internet if no hw clock is present or functional.
- so it syncs to internet for RPI that donot have hw clock.
- it does NOT sync to internet for most X86 boards with functional hw clock.
- so "nortc" should be read as "no rtc present" (and not as "donot use rtc").
- supported by tests in all earlier posts
2/ to keep time current: add "sudo ntpd -p pool.ntp.org" to bootlocal.sh.
3/ Note that FAQ is outdated on this
- http://tinycorelinux.net/faq.html#bootcodes mentions "settime" bootcode which does no longer exist, it does not mention "nortc" bootcode
ntpd tested
- ntpd corrects a time offset
- ntpd syncs hwclock
- resource use is very minimal (mostly 0% when using top on old hp510 thin x86 client)
tc@hp510:~$ date //this time is same as time on laptop
Sun May 4 07:39:44 CEST 2025
tc@hp510:~$ sudo date 05040730 //set clock 10mins back
Sun May 4 07:30:00 CEST 2025
tc@hp510:~$ date //confirm, its 10min back
Sun May 4 07:30:03 CEST 2025
tc@hp510:~$ sudo hwclock --systohc --utc //sync hwclock to system clock
tc@hp510:~$ hwclock
Sun May 4 05:31:10 2025 0.000000 seconds //confirm hwclock is 2hrs earlier which is correct utc
tc@hp510:~$ date
Sun May 4 07:31:21 CEST 2025 //confirm systemtime is still in same ballpark, it's still 10mins off
tc@hp510:~$ sudo ntpd -p pool.ntp.org //start ntpd syncing
--- wait ----
tc@hp510:~$ date //confirm with clock of laptop, ntpd has succesfully synced time
Sun May 4 07:55:43 CEST 2025
tc@hp510:~$ hwclock //hwclock is now 10min behind system time, so ntpd did not (yet) sync hwclock
Sun May 4 05:45:27 2025 0.000000 seconds
--- wait ----
tc@hp510:~$ hwclock
Sun May 4 06:07:14 2025 0.000000 seconds
tc@hp510:~$ date
Sun May 4 08:17:52 CEST 2025 //hwclock still 10 minutes behind system time
--- wait ----
tc@hp510:~$ hwclock
Sun May 4 06:39:49 2025 0.000000 seconds
tc@hp510:~$ date
Sun May 4 08:39:51 CEST 2025 //hwclock is synced to system time
-
Some doc's in TC doesn't have being updated for long time.
I see in the wiki it has:
https://wiki.tinycorelinux.net/doku.php?id=wiki:boot_options#deprecated_boot_options (https://wiki.tinycorelinux.net/doku.php?id=wiki:boot_options#deprecated_boot_options)
-
Note, I am very well aware tiny core is run by volunteers, and with great respect I very much like the project.
It's a bit too much for me to volunteer as maintainer, but I took the time to minutely report my findings especially with the intend to help others.
With that said:
I feel current wiki text is not correct, this text (and more information I did find on this forum before posting) brought me to start this topic with title "geTime.sh not working at startup".
current wiki on nortc bootcode says: "Set UTC time at boot, internet required"
This is not correct: the nortc bootcode will NOT set UTC if rtc is present, it only does that if no functional rtc is present.
Suggestion: "use if no rtc (real time clock) present, to set UTC time at boot without functional rtc"
Alternatively change settime.sh to comply with current wiki text (not tested suggestion to initialize to unrealistic value to force internet sync):
code snippet:
................
do
[ $((CNT++)) -gt 60 ] && break || sleep 1
done
if [ $CNT -le 60 ]
then
CNT=9999
NRT=0
#suggested addition (not tested)
#force system clock to unrealistic value to trigger waiting for successful internet sync
sudo date 010101012010
while sleep 0
do
XXX=$(/bin/date -I)
XXX=${XXX:0:4}
# this comparison breaks out with functional rtc without the above suggested addition
if [ "$XXX" -ge "2015" ];
then
break
fi
..........
Note:
personally I would change the wiki, not settime.sh because the sync adds boottime which I donot want to spend if I have a functional rtc.
However... I think it makes sense to add a bootcode like "ntpd" that enforces "sudo ntpd -p pool.ntp.org". This does not only sync systemtime but also syncs the rtc to have a "good start from rtc" at next boot. I will now do that in bootlocal.sh but as ntpd is already in the package starting ntpd with a standard bootcode would be nice
So.... I kind of hope some maintainer can fix the wiki. and maybe copy ntpd bootcode suggestion in TC17.
And if not: it will help those struggling with the issue and search the forum.
-
You should be able to edit the wiki yourself?
-
I think I cannot > just checked the page and don't think I have editing rights.
If I click "page source" I get: "This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong."
note: I have never in my lifetime edited a wiki page so I may do something wrong
(also: can I just "do" that? not stepping on toes?)
-
Hi Stefann
I think I cannot ...
Now you can. :)
-
@Rich: thanks
wiki updated: "Use if no rtc (real time clock) present, to set UTC time at boot without functional rtc, Internet required."
To double check, I tested at both my systems:
- HP510 thin client with VIA Eden x86 processor, 1GHz, 2core, 64bit running on TC16/32bit
- other thin client with VIA Eden x86 processor, 500MHz, 1core running on TC15/32bit
in both cases:
- used nortc bootcode
- modified settime.sh to include logging and added it to .fieltool.lst
- gave date a 5minute offset, synced to hwclock, checked.
- reboot
- logging confirmed settime.sh was called and conditions to sync with internet were met
- but 1st "date" call reported "2025" and getTime.sh call was skipped as result of <2015 check
>> so indeed no internet time sync
It's a bit strange, also found below code snippet in tc-config.
- This basically "does not set system clock" in case of nortc bootcode.
- This means that 1st date call in settime.sh is towards uninitialised system clock
>>>I guess system clock "auto initialises" towards hwclock.
- Maybe not at all processors, maybe just my VIA Eden processors
- Modified wiki text makes clear to only use nortc without hw clock. in case of hwclock present it keeps the behaviour "undefined" which is probably correct. One could dig in deeper but I guess this gives enough warning to trigger a potential someone having a problem in future.
And in case one has a hwclock:
- better not use nortc bootcode
- without internet keep running from hwclock
- with internet add "sudo ntpd -p pool.ntp.org" to filetool.sh to keep syncing system clock and hwclock to "real time"
if [ -n "$NORTC" ]; then
echo "${BLUE}Skipping rtc as requested from the boot command line.${NORMAL}"
else
while [ ! -e /dev/rtc0 ]; do usleep 50000; done
if [ -n "$NOUTC" ]; then
/sbin/hwclock -l -s &
else
/sbin/hwclock -u -s &
fi
fi