Output of "who -a" on 32-bit system is corrupt

This forum is for topics dealing with problems with software specifically in the ARMv7h repo.

Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Sun Aug 14, 2022 6:36 pm

On 64-bit
$this->bbcode_second_pass_code('', '
$ date
Sun Aug 14 14:27:07 EDT 2022
$ uptime
14:28:53 up 34 min, 1 user, load average: 0.00, 0.02, 0.26
$ yay -Qo /usr/bin/who
/usr/bin/who is owned by coreutils 9.1-1
$ who -b
system boot Aug 14 13:54
$ who -a
system boot Aug 14 13:54
LOGIN ttyAMA0 Aug 14 13:55 296 id=AMA0
LOGIN tty1 Aug 14 13:55 295 id=tty1
user + pts/0 Aug 14 13:55 . 301 (10.10.10.10)
$ df -hT /run/utmp
Filesystem Type Size Used Avail Use% Mounted on
run tmpfs 483M 628K 482M 1% /run
')

On 32-bit armv7l
$this->bbcode_second_pass_code('', '
$ date
Sun Aug 14 14:21:41 EDT 2022
$ uptime
14:28:49 up 1 day, 6:22, 1 user, load average: 0.00, 0.00, 0.00
$ who -b
system boot Jan 12 00:49
$ yay -Qo /usr/bin/who
/usr/bin/who is owned by coreutils 9.1-1
$ who -a
system boot Jan 12 00:49
LOGIN ttyS0 Jan 1 11:00 6081 id=tyS0
LOGIN tty1 Jan 2 16:14 270 id=tty1
user + pts/0 Jun 3 19:36 . 7624 (10.10.10.10)
$ df -Th /run/utmp
Filesystem Type Size Used Avail Use% Mounted on
tmpfs tmpfs 198M 49M 150M 25% /run
')
The system has been up for one day in August yet who shows it booted in January and it shows I logged in back in June.
df shows that utmp is on tmpfs so it could not have any residue in it from before the system booted.

The /run/utmp file is created at boot by systemd-tmpfiles.
$this->bbcode_second_pass_code('', '
$ systemd-tmpfiles --cat-config | grep /run/utmp
F! /run/utmp 0664 root utmp -
')
The "F" is somewhat undocumented. I was able to find a description in the source code.
$this->bbcode_second_pass_code('', '
$ grep TRUNCATE_FILE tmpfiles.c |head -n 1
TRUNCATE_FILE = 'F', /* deprecated: use f+ */
')
The "!" is in the man page for tmpfiles.d and it means "only at boot".
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby robg » Mon Aug 15, 2022 9:12 am

Could this be related to the bit-issue reported for wget? Does applying the suggested build flags (-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64) help?
robg
 
Posts: 185
Joined: Tue Jan 05, 2021 8:22 am

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Thu Aug 18, 2022 12:23 am

When you run who -a do you see the same thing? I want to know if it's just me.
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby robg » Fri Aug 19, 2022 12:11 pm

I am currently relying on a 64bit RPI setup, and don't have another SD card to spare. But surely someone else could quickly confirm it?
robg
 
Posts: 185
Joined: Tue Jan 05, 2021 8:22 am

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Sun Aug 21, 2022 5:27 pm

$this->bbcode_second_pass_code('', '
$ pwd
/pool/src/coreutils
$ grep -EC 1 'buildflags|CFL' PKGBUILD
source=("https://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.xz"{,.sig})
options=(buildflags)
validpgpkeys=('6C37DC12121A5006BC1DB804DF6FD971306037D9') # Pádraig Brady
--
cd $pkgname-$pkgver
export CFLAGS="$CFLAGS -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64"
./configure \
')
That did not seem to work.
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Mon Aug 22, 2022 12:50 am

adding --disable-year2038 to the ./configure line worked, except some of the test failed.

$this->bbcode_second_pass_code('', '
# Maintainer: Sébastien "Seblu" Luttringer
# Contributor: Bartłomiej Piotrowski <bpiotrowski@archlinux.org>
# Contributor: Allan McRae <allan@archlinux.org>
# Contributor: judd <jvinet@zeroflux.org>

pkgname=coreutils
pkgver=9.1
pkgrel=1
pkgdesc='The basic file, shell and text manipulation utilities of the GNU operating system'
arch=('any')
license=('GPL3')
url='https://www.gnu.org/software/coreutils/'
depends=('glibc' 'acl' 'attr' 'gmp' 'libcap' 'openssl')
source=("https://ftp.gnu.org/gnu/$pkgname/$pkgname-$pkgver.tar.xz"{,.sig})
validpgpkeys=('6C37DC12121A5006BC1DB804DF6FD971306037D9') # Pádraig Brady
sha256sums=('61a1f410d78ba7e7f37a5a4f50e6d1320aca33375484a3255eddf17a38580423'
'SKIP')

prepare() {
cd $pkgname-$pkgver
# apply patch from the source array (should be a pacman feature)
local filename
for filename in "${source[@]}"; do
if [[ "$filename" =~ \.patch$ ]]; then
echo "Applying patch ${filename##*/}"
patch -p1 -N -i "$srcdir/${filename##*/}"
fi
done
:
}

build() {
cd $pkgname-$pkgver
./configure \
--prefix=/usr \
--libexecdir=/usr/lib \
--with-openssl \
--enable-no-install-program=groups,hostname,kill,uptime \
--disable-year2038
make
}

check() {
cd $pkgname-$pkgver
make check
}

package() {
cd $pkgname-$pkgver
make DESTDIR="$pkgdir" install
}

# vim:set ts=2 sw=2 et:
')

make check-TESTS check-local

FAIL: tests/mv/part-symlink
FAIL: tests/misc/xattr.sh
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby robg » Mon Aug 22, 2022 11:09 am

This is a weird situation. I have read up on the buildflags (_FILE_OFFSET_BITS=64 & _TIME_BITS=64) and the GNU year2038 module (see here, here, and here). It seems that `--disable-year2038` only serves the purpose of building software with 32bit time types; unless `--disable-year2038` is set, the GNU year2038 module enforces 64bit types via _TIME_BITS=64. Now, since 64bit time types are the supposed default, and since you obtained a working coreutils package with `--disable-year2038`, I can only surmise that one of the coreutils dependencies must have been build with 32bit time types, leading to an incompatibility with the (correct) 64bit-time coreutils.
robg
 
Posts: 185
Joined: Tue Jan 05, 2021 8:22 am

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Tue Aug 23, 2022 5:42 pm

Test that failed:
FAIL: tests/mv/part-symlink

Is due to
mv: setting attribute 'security.SMACK64' for 'security.SMACK64': Operation not permitted

Which is because the fsetxattr(2) can only run as root (or some capability setting(s) but I don't have time to figure out which one(s)). I'm not sure it it's supposed to be that way. The man page for fsetxattr(2) does not say that EPERM occurs when the owner of the file calls it. It says this:
$this->bbcode_second_pass_code('', 'EPERM The file is marked immutable or append-only. (See ioctl_iflags(2).)
')
Being unable able to mv your own file without getting an error is not cute.

Details that show more-or-less what the test that fails is doing:
$this->bbcode_second_pass_code('', '$ rm /tmp/k
$ touch /tmp/k
$ chmod u-w /tmp/k
$ echo foo > k
$ strace -o mv.strace -f mv -f k /tmp/k
mv: setting attribute 'security.SMACK64' for 'security.SMACK64': Operation not permitted
$ magic-utility-that-parses-strace-output...(just kidding, I did it by hand)
...
7175 renameat(AT_FDCWD, "k", AT_FDCWD, "/tmp/k") = -1 EXDEV (Invalid cross-device link)
7175 unlinkat(AT_FDCWD, "/tmp/k", 0) = 0
7175 openat(AT_FDCWD, "k", O_RDONLY|O_LARGEFILE|O_NOFOLLOW) = 3
...
7175 fgetxattr(3, "security.SMACK64", NULL, 0) = 1
7175 fgetxattr(3, "security.SMACK64", "_", 1) = 1
7175 fsetxattr(4, "security.SMACK64", "_", 1, 0) = -1 EPERM (Operation not permitted)
7175 write(2, "mv: ", 4) = 4
7175 write(2, "setting attribute 'security.SMAC"..., 59) = 59
7175 write(2, ": Operation not permitted", 25) = 25
7175 write(2, "\n", 1) = 1
')

The file is moved, it's only after that SMACK doesn't succeed.
$this->bbcode_second_pass_code('', '$ echo foo > k
$ mv -f k /tmp/k
mv: setting attribute 'security.SMACK64' for 'security.SMACK64': Operation not permitted
$ cat /tmp/k
foo
$ ls -l k
ls: cannot access 'k': No such file or directory
')
Maybe it's a sMACK configuration issue but I've always left SMACK alone and used whatever defaults it comes with.
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Tue Aug 23, 2022 6:39 pm

$this->bbcode_second_pass_quote('', 'I')t seems that `--disable-year2038` only serves the purpose of building software with 32bit time types; unless `--disable-year2038` is set, the GNU year2038 module enforces 64bit types via _TIME_BITS=64. Now, since 64bit time types are the supposed default, and since you obtained a working coreutils package with `--disable-year2038`, I can only surmise that one of the coreutils dependencies must have been build with 32bit time types, leading to an incompatibility with the (correct) 64bit-time coreutils.

in year2038.m4 there are these comments:
dnl On many systems, time_t is already a 64-bit type.
dnl On those systems where time_t is still 32-bit, it requires kernel
dnl and libc support to make it 64-bit. For glibc 2.34 and later on Linux,
dnl defining _TIME_BITS=64 and _FILE_OFFSET_BITS=64 is needed on x86 and ARM.

It might be a glibc and/or kernel issue.
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Re: Output of "who -a" on 32-bit system is corrupt

Postby Mettacrawler » Wed Aug 31, 2022 7:44 pm

I don't think it's a kernel but it might be a libc issue. It only affects certain programs. For instance /usr/bin/date and /usr/bin/last are not affected while the both deal with the time-of-day. /usr/bin/last is very similar to /usr/bin/who in that they both read files in utmp format.

/usr/bin/last is part of util-linux not coreutils.

I did find that /usr/bin/pinky is affected along with /usr/bin/who. /usr/bin/pinky also reads utmp files.

Both /usr/bin/who and /usr/bin/last have an identical function, time_string().
$this->bbcode_second_pass_code('', '
/* 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." */
')

Adding ./configure ... --disable-year2038 fixes both of them.
Mettacrawler
 
Posts: 56
Joined: Sun Mar 18, 2018 7:19 pm

Next

Return to ARMv7h

Who is online

Users browsing this forum: No registered users and 1 guest