Hello John. On 02.10.2022 20:29, jmcquah@disroot.org wrote:
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.
This has been exactly the issue on my system too: The old folder /var/run/ did still have some contents in it so it had not been deleted.
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.
Exactly. I have also noticed I had to use "pkgadd -f" while upgrading "linux-firmware" when still being on CRUX 3.6 because of a symlink.
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.
For the /var/run issue I am unsure if this case should have been handled by pkgutils: At least on my system there have been some leftovers which had been owned by old unrelated port versions or even by no port. I think generally deleting a folder which has some contents in it automatically is not a good idea. For the "linux-firmware" issue I think it could be right to be handled by pkgutils, also without "-f" parameter. If all files which need to be deleted belong to the same port which is about to be updated they can safely be removed.
-- John
[1] https://libera.irclog.whitequark.org/crux-devel/2022-09-23 [2] https://crux.nu/bugs/index.php?do=details&task_id=15
Best regards Markus Heinz