Bug in coreutils 9.0-8 on Fedora 36 armhfp 32-bit system

Ask Fedora
,
1

Information about the system where the bug happens

$ lsb_release  -a
LSB Version:	:core-4.1-arm:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 36 (Thirty Six)
Release:	36
Codename:	ThirtySix
$ uname -rv
5.19.6-200.fc36.armv7hl #1 SMP Wed Aug 31 17:58:17 UTC 2022
$ rpm -q coreutils
coreutils-9.0-8.fc36.armv7hl
$ rpm -q util-linux
util-linux-2.38-1.fc36.armv7hl

The bug itself

$ who -a
           system boot  1970-01-04 15:35
           run-level 3  1970-01-08 05:11
LOGIN      tty1         1970-01-07 20:01               482 id=tty1
user     + ttyAMA0      1970-01-09 17:37   .           483
user     + pts/0        504588700852756167   .           645 (192.168.X.X)
$ pinky
Login    Name                 TTY      Idle   When             Where
meta     Metta Crawler        ttyAMA0  00:14  1970-01-09 17:37
meta     Metta Crawler        pts/0           504588700852756167 192.168.X.X
$ date
Tue Sep  6 06:53:18 PM EDT 2022

The time of day is wrong in the output of who and pinky despite the clock being set right and date is showing the actual time.

$ last reboot | head -n 1
reboot   system boot  5.19.6-200.fc36. Tue Sep  6 22:33   still running

The last program shows the correct time. All three programs, last, who and pinky read utmp-style files.

last comes from util-linux not coreutils.

Both who and pinky have an identical function, time_string().

/* Return a time string.  */
static char const *
time_string (const STRUCT_UTMP *utmp_ent)
{
  static char buf[INT_STRLEN_BOUND (intmax_t) + sizeof "-%m-%d %H:%M"];

  /* Don't take the address of UT_TIME_MEMBER directly.
     Ulrich Drepper wrote:
     "... GNU libc (and perhaps other libcs as well) have extended
     utmp file formats which do not use a simple time_t ut_time field.
     In glibc, ut_time is a macro which selects for backward compatibility
     the tv_sec member of a struct timeval value."  */

I haven’t tried rawhide yet but I will.

2

Sigh

https://pagure.io/releng/issue/10387

3

Several things may not function properly if the RTC is not set to UTC. You can see the settings for Local, Universal, and RTC, as well as the time zone with timedatectl. RTC and Universal should be the same with Local offset according to the time zone.

If the RTC is not set to UTC then the timedatectl command should give a warning with instructions on how to set that.
It is always recommended that RTC is set to UTC.

1 Like
4

Did you read Issue #10387: F37: System wide change: Retire the ARMv7 architecture - releng - Pagure.io ?

5

Your issue appears to be improper display of times. The RTC setting has a bearing on that so I point out what might be a factor.

I do not have nor use any ARMv7 architecture devices so that is not even in my ballpark.

BTW, except for some special cases fedora stopped supporting 32 bit architecture devices with fedora 34, over a year past.

1 Like
6

I see what you mean, but it’s still supported for f36, so it’s still fair game to ask about it during the f36 lifecycle. If it’s a raspberry pi 4, then it also supports aarch64, though you’ll need to reinstall.

7

Create 32-bit Fedora armhfp VM

8

It’s a Marvell Clearfog Pro

9

Are you sure? They removed armhfp from koji.