Package: coreutils
Version: 9.1
Hardware: Raspberry Pi B+ (ARMv6)
OS: Raspberry Pi OS Bookworm 32-bit
**Summary**
The `who` command displays a large garbage number instead of the login
timestamp on Raspberry Pi B+ (ARMv6) running Bookworm.
**Steps to reproduce**
1. Upgrade Raspberry Pi B+ from Bullseye to Bookworm
2. Log in via SSH
3. Run `who`
**Expected output**
```
pi pts/0 2026-03-28 23:12 (192.168.1.155)
```
**Actual output**
```
pi pts/0 -7277349980266658240 . 2386 (192.168.1.155)
```
**Investigation**
The data in utmp is correct. Running `utmpdump /var/run/utmp` shows proper
timestamps. The issue is in how `who` reads and interprets the timestamp
field.
The root cause appears to be the time_t size change in glibc 2.36, where
time_t was extended from 32-bit to 64-bit on 32-bit ARM to address the year
2038 problem. The `who` binary in coreutils 9.1 does not handle this
correctly on ARMv6.
**System information**
```
$ file /usr/bin/who
/usr/bin/who: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-armhf.so.3,
BuildID[sha1]=c6dc2242888186e91a05821c53acda562d7737ea, for GNU/Linux
3.2.0, stripped
$ ldd /usr/bin/who
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
/usr/lib/arm-linux-gnueabihf/libarmmem-v6l.so (0xb6f30000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6da4000)
/lib/ld-linux-armhf.so.3 (0xb6f4f000)
$ who --version
who (GNU coreutils) 9.1
$ who
pi pts/0 -7277349980266658240 . 2386 (192.168.1.155)
$ sudo utmpdump /var/run/utmp
[shows correct timestamps]
```
**Workaround**
Using `utmpdump /var/run/utmp` displays correct timestamps. The `who`
command is the only affected tool confirmed so far.
**Notes**
This only affects ARMv6 hardware (Raspberry Pi B+). The Pi B+ is the only
Raspberry Pi model that uses ARMv6 and is not supported by the 64-bit
version of Raspberry Pi OS, making the 32-bit Bookworm image the only
upgrade path for this hardware.
