Torizon OS not 2038 aware

Feature Requests
, ,
1

I’m using a Colibri iMX6DL 512MB V1.1A board and I tested if setting the date to 2038 will work. Setting the date was successful by setting it via

 date --set "2038-07-02 10:29:21"

I played around with my app, then suddenly the system rebooted and does not come up anymore. On the console I get the error message:

ostree-prepare-root: stat(/rootfs/ostree/deploy/torizon/deploy/e4e3b13d26ab8a104275700c1410ed317cb904539702c81370a492ad349c209f.0) failed: Value too large for defined data type
ERROR: There's no '/dev' on rootfs

Here is the complete boot log:

Commercial temperature grade DDR3 timings, 64bit bus width.
Trying to boot from MMC1


U-Boot 2022.07-6.6.1+git.e092e3250270 (Jan 01 1970 - 00:00:00 +0000)

CPU:   Freescale i.MX6DL rev1.4 996 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 45C
Reset cause: POR
DRAM:  512 MiB
PMIC:  device id: 0x10, revision id: 0x21, programmed
Core:  72 devices, 17 uclasses, devicetree: separate
MMC:   FSL_SDHC: 1, FSL_SDHC: 0
Loading Environment from MMC... OK
In:    serial@2020000
Out:   serial@2020000
Err:   serial@2020000
Model: Toradex 0079 Colibri iMX6DL 512MB V1.1A
Serial#: 11370950
Net:   eth0: ethernet@2188000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
973 bytes read in 1 ms (950.2 KiB/s)
## Executing script at 18280000
6668 bytes read in 2 ms (3.2 MiB/s)
65273 bytes read in 4 ms (15.6 MiB/s)
69 bytes read in 2 ms (33.2 KiB/s)
Applying Overlay: colibri-imx6_panel-cap-touch-7inch_adapter_overlay.dtbo
1975 bytes read in 3 ms (642.6 KiB/s)
11571712 bytes read in 305 ms (36.2 MiB/s)
5071839 bytes read in 134 ms (36.1 MiB/s)
Kernel image @ 0x14200000 [ 0x000000 - 0xb09200 ]
## Flattened Device Tree blob at 18200000
    Booting using the fdt blob at 0x18200000
   Loading Ramdisk to 1fb29000, end 1ffff3df ... OK
   Loading Device Tree to 1faf6000, end 1fb28fff ... OK
   
     Starting kernel ...

[    1.513020] physmap-flash 8000000.sram: map_probe failed
[    1.523903] physmap-flash a000000.sram: map_probe failed
Starting version 250.5+
ostree-prepare-root: stat(/rootfs/ostree/deploy/torizon/deploy/e4e3b13d26ab8a104275700c1410ed317cb904539702c81370a492ad349c209f.0) failed: Value too large for defined data type
ERROR: There's no '/dev' on rootfs.

This sounds like a 2038 problem.

1 Like
2

Hi

1/2 OT, but busybox on Linux BSP seems being as well not 2038 aware

#  date --set "2037-08-02 10:29:21"
Sun Aug  2 10:29:21 EEST 2037
#  date --set "2038-08-02 10:29:21"
date: invalid date '2038-08-02 10:29:21'

# ls -l `which date`
lrwxrwxrwx    1 root     root            19 Mar  9  2018 /bin/date -> /bin/busybox.nosuid

Edit. I don’t have 64 bit module. I mean issue on 32bits iMX7. timedatectl as well isn’t Y2038 compatible. Hope it’s just glibc compiled without -D_TIME_BITS=64.
Did any body try bitbaking for 32 bitter with kernel’s CONFIG_COMPAT_32BIT_TIME=n ? If I’m not missing something, it should help revealing Y2038 incompatible parts, isn’t it?

3

Greetings @moberza,

We are already aware there are various packages in our BSP that are not 2038 friendly at the present time. While it’s on our radar it’s not urgent for the current version of our BSP. Since the current version of our software won’t be supported for that long in any case.

So then just to ask. Is this just something you were just testing to see? Or is it something you need in the near future?

Best Regards,
Jeremias

4

This is something I just wanted to test to see, if it is already working. Since my target product might be in use for 10 years, its now the time to test this stuff. I will suggest using a Colibri íMX8 and 64 bit software, to avoid this problem.
But I’m surprised that the y2038 is still an unsolved problem on 32bit systems.

1 Like
5

Just to confirm we are seeing this too on an apalis-imx6-like system. Also interested in a fix since it’s conceivable that our devices will also still be in use in that timeframe. (But understand it will likely happen with a future OS update)