Boot path should always try to set hardware clock, but not err out

[ericonr]

From #musl:

16:53 <arnd> khem, ericonr: they sort-of have a point that the situation is broken: the kernel's behavior is absurdly broken but kept for backwards compatibility with a hack that dates back to the early 1990s.  Whichever program calls settimeofday the first  time after boot decides whether the kernel uses normal UTC behavior or MS-DOS compatible RTC-is-localtime.
16:54 <arnd> If /sbin/init doesn't do this but something else calls settimeofday() with a non-zero TZ offset later, it all goes wrong
16:55 <arnd> So if settimeofday() is either not available (on rv32) or disabled and returns -ENOSYS, the init task should just continue
16:57 <ericonr> arnd: I assume the kernel is hardcoded to use UTC on such on such archs?
16:58 <arnd> yes, the logic to do the timewarp is still there, but there are no other callers
16:59 <ericonr> I guess you still need to call it where available, otherwise some other application can force a sudden time warp >.<
16:59 <arnd> I don't think there are any distros that actually try to use the timewarp code, though setting the kernel timezone is still done sometimes
17:00 <arnd> any sane /sbin/init implementation does the same as the busybox variant

From 03-console-setup.sh:

if [ -n "$HARDWARECLOCK" ]; then
    msg "Setting up RTC to '${HARDWARECLOCK}'..."
    TZ=$TIMEZONE hwclock --systz \
        ${HARDWARECLOCK:+--$(echo $HARDWARECLOCK |tr A-Z a-z) --noadjfile} || emergency_shell
fi

This means that

• we only try to set the kernel timezone when HARDWARECLOCK is set, which means a badly behaved application can force a time warp by calling settimeofday(0, some_tz) as root.
• our init of choice, runit, never calls settimeofday(), which means for safety reasons we should always try to set the kernel timezone, and defaulting to UTC is entirely reasonable.
• On some archs (and maybe at some point even some kernels?), this command can error out, so || emergency_shell is also wrong there.