On Tue, 18 Feb 2025 at 17:39, Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> wrote: > > On 18/02/2025 17:05:23+0100, Arnd Bergmann wrote: > > On Tue, Feb 18, 2025, at 16:40, Alexandre Belloni wrote: > > > On 18/02/2025 15:51:24+0100, Arnd Bergmann wrote: > > >> On Tue, Feb 18, 2025, at 14:30, Alexandre Belloni wrote: > > >> > > >> I don't know how many 32-bit machines are affected by the bug > > >> where they return a random time, or if they are more or less > > >> common than in the past. > > > > > > This is going to break some of the Marvell board that RMK uses because I > > > guess he is not updating his userspace. > > > > > > Also, I'd note that OpenEmbedded switched to 64-bit time_t by default > > > just last year. > > > > > > I'm not against removing the workaround but keeping it doesn't actually > > > break anyone, it is still possible to set the time properly from > > > userspace as it should be done anyway so I'm not sure about the urgency. > > > The impact is mostly about messages timestamp in the boot log, before > > > being able to run hwclock or any similar tool. > > > > > > Or am I missing anything? > > > > The main problem with the current approach is that it suddenly > > breaks systems in the future (at the time_t overflow), which is > > the opposite of how the rest of the time_t conversion worked. > > Yes, it will suddenly stop setting the time on boot which the platform > can (and will) survive because it will probably then start NTP. However, > without the workaround, systemd will just crash on boot, bricking the > device. So as I see it, on one hand, I have mostly recoverable breakage > and on the other breakage that mean going on the field and reflashing > the device because the system will probably not be able to do any OTA > anymore. You guys think that all devices have a network connection? Even in 2038 I don't think that will be anywhere close to true, since there are a ton of 32-bit embedded devices out there running linux with no network. Just my company has thousands. I'm using rtc-pcf8563 with systemd on i.MX6 (majority has no internet), and I just removed this check locally. That way my devices can keep time until 2070 (EPOCH+100Y), which is currently the upper limit of the rtc-pcf8563. > > > > > We now have distros with systemd that advertize support [1], > > and we know this breaks every single machine they run on that > > uses an RTC to set the time. > > No, this breaks systems that only rely on RTC_HCTOSYS without a > fallback. > > RTC_HCTOSYS alone is anyway pretty bad idea and no one interested in > time should use it because it can be off up to a second which can take > 4 to 7 days to resolve by selewing and not stepping. Anyone serious > should use hwclock or similar to set the system time precisely after > boot so the offset will be closer to a few ms. > Suits me fine. I do think that documenting this would be nice, since most of the hardware seems to be able to handle dates after Y2038 - it's mostly a userspace issue now. -- Regards Einar Jón
