Hello Markus,
I have made an update from CRUX 3.6 to 3.7. Now I have discovered that the output of the "who" command is empty.
For me the output of the "who" command has never listed all the users currently logged in to the system, because my login manager (greetd) does not write to /run/utmp. Since learning of this behaviour I stopped paying any attention to the output of "who". But your next observation reveals a more fundamental issue.
I found out that /var/run/utmp does not exist. But I have an empty file /run/utmp with a timestamp of the last boot time.
With a proper installation of the core/filesystem package from the ISO, /var/run in the former path should be a symlink to /run. Your report of a missing /var/run/utmp motivated me to inspect one of my own 3.6->3.7 upgrades, and I then discovered that /var/run had been left intact, not converted to a symlink during the upgrade! (This particular upgrade took place with the rc4 ISO, but I suspect that the September 26 release ISO would have behaved the same way.) As discussed on #crux-devel [1] the setup script calls pkgadd with the '-f' flag during upgrades. But if /var/run had been non-empty when you booted the installation media (as it was on the machine that I just inspected), then pkgadd might have quietly refused to recursively delete that directory even when called with the '-f' flag. As a result, you have a broken installation of the core/filesystem port, and misleading output from the "who" command. The volatile nature of the contents under /var/run distinguishes this run of 'pkgadd -u -f' from the corresponding attempt to force update the opt/linux-firmware port. Because everything under /lib/firmware/qcom/LENOVO/21BX was already known to be owned by the old version of linux-firmware, 'pkgadd -u -f' could proceed with the update even though this path is a symlink in the newer version. In contrast, it looks like pkgadd was unwilling to clean out the contents of /var/run left behind from the last boot of your 3.6 system, and so the symlink never got created properly. Tim has responded already with a simple fix. But the related issue of symlink handling in pkgutils [2] is still unresolved. Thanks Markus, for giving us another reason to revisit this long-standing bug in pkgutils. -- John [1] https://libera.irclog.whitequark.org/crux-devel/2022-09-23 [2] https://crux.nu/bugs/index.php?do=details&task_id=15