On 01/09/2022 15:12:57+0200, Arnd Bergmann wrote:
On Thu, Sep 1, 2022, at 2:49 PM, Alexandre Belloni wrote:
On 01/09/2022 13:55:19+0200, Arnd Bergmann wrote:
The only reliable fix I can see would be to disable CONFIG_RTC_HCTOSYS_DEVICE. I think this is Alexandre's plan for the long run anyway, but I don't know if there has been any progress in convincing distros to turn it off.
This is still my plan but systemd mandates RTC_HCTOSYS and I couldn't convince Lennart otherwise.
Ah, I forgot that systemd actually needs it. So I guess there is currently no way to use systemd on 32-bit machines that are meant to survive 2038, regardless of whether systemd and glibc are built with a 64-bit time_t or not, right?
Well, it doesn't actually need it. It could as well go and read the RTC and decide what to do with the time it gets. The main reason they want it is because the log timestamps are correct earlier when the kernel does it.
Is there perhaps a way to change the logic in a way that it does not depend on the current time but instead depends on a property of the RTC device itself, so we make systems break immediately instead of by surprise in 2038?
The safe thing to do is really to not use hctosys and have a systemd unit that reads the RTC from userspace. See https://github.com/systemd/systemd/issues/17737 for the whole discussion.
As far as I remember, the workaround was only needed for certain devices that may set the time to something after 2038 on a depleted battery, but other devices would have a better failure case, right?
Yes, this is the main cause, anything able to set the system time after 2038 with a 32bit userspace will cause that (and basically I think this is only hctosys). The issue is that many RTCs don't have a default value for the time registers after power failure. This is usually not an issue as there is also a bit allowing to detect whether the time is correct. note that this will also be an issue once we actually reach 2038 with a 32bit userspace.