[PATCHv3 1/3] base-files: use hwclock --systz

[Hannu Nyman]

Rosen Penev kirjoitti 8.1.2021 klo 5.30:
> The date -k patch is non standard and will be removed in the next
> commit.
>
> ...
>
> --- a/package/base-files/files/etc/init.d/system
> +++ b/package/base-files/files/etc/init.d/system
> @@ -27,7 +27,7 @@ system_config() {
>   		ln -sf "/usr/share/zoneinfo/$zonename" /tmp/localtime && rm -f /tmp/TZ
>   
>   	# apply timezone to kernel
> -	busybox date -k
> +	hwclock --systz
>   }
>   
>   reload_service() {


I suspect that this proposed modification causes a noticeable difference to 
the previous way:
After reboot, the early part of the log seems to be in UTC instead of the 
local timezone, as earlier. (Likely sysfixtime has understood the timestamp 
of the last file in /etc wrongly)

Here is a extract from system log of the router with busybox 1.33 in a simple 
reboot. I touched a file in /etc just before reboot, so sysfixtime should set 
roughly correct time early in the boot process. There should be just approx. 
one minute jump when NTP corrects time (from the most-recent-file based boot 
time as set by sysfixtime), instead of two hours + 1 minute.

Sun Jan 10 16:37:50 2021 daemon.info procd: - init complete -
Sun Jan 10 16:37:52 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)
Sun Jan 10 18:38:56 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=7262.868194


Something has prevented the normal timezone handling there.


Doing the same reboot with a 2 Jan 2021 build without buysybox 1.33 makes the 
time shift jump look again normal. There is just the expected one minute jump:

Sun Jan 10 19:04:01 2021 daemon.info procd: - init complete -
Sun Jan 10 19:05:03 2021 user.notice ntpd: Time set, stratum=16 interval=32 
offset=60.906955
Sun Jan 10 19:05:05 2021 user.notice nlbwmon: Reloading nlbwmon due to ifup 
of lan6 (br-lan)


It is of course possible that this might be due to some change in base-files 
or kernel last week, but that is hard to believe.

I suspect that the "hwclock --systz" does something slightly different than 
our "date -k", at least on routers without a real RTC.

My proposal would be to revert your removal of the date-k patch and continue 
using it the previous way.

(I will try to test with date-k reverted if things then work ok with 1.33. 
Might be that this is something different.)


Ps. Let's just focus to the Busybox version upgrade, without doing these 
"let's remove OpenWrt-specific patches" cleanup at the same time. This clock 
handling change is quite separate from the 1.31 --> 1.33 version bump (unless 
1.33 really prevents the previous way).