I’m running Fedora 37 aarch64 on my RockPro64, and needs-restarting -r still reports a reboot is required even after rebooting a couple times. The latest kernel, 6.0.16, is being used on the current boot. All the packages needs-restarting -r lists are the latest versions. I’m not sure how to debug this.
One thing possibly worth mentioning is that I have /root on a separate disk from /boot and /boot/efi.
Does the system work even after seeing that message?
Is that one of the popup notifications at the top of the screen?
If it is then it may be a message from gnome-software and not an actual issue. It is often that packagekit cache and dnf cache are out of sync. I see it frequently when my system is up to date with dnf but the packagekit cache has not yet updated.
I don’t have a RockPro64 but I do have a rpi4 with F37 aarch64. Have not updated it recently but will do so and see if I encounter the same error. (I need to finish a 3D print first so will be some time before I can provide any additional input.)
Yeah, the system works fine. I forgot to mention that I’m running Fedora Server, so there is no GUI or PackageKit.
The needs-restarting manpage says it “looks through running processes and tries to detect those that use files from packages that have been updated after the given process started.” So somehow it’s detecting that the processes have started before those packages have been updated.
proc_1_boot_time = int(os.stat('/proc/1').st_mtime)
with open('/proc/uptime', 'rb') as f:
uptime = f.readline().strip().split().strip()
proc_uptime_boot_time = int(time.time() - float(uptime))
return max(proc_1_boot_time, proc_uptime_boot_time)
My RockPro64 doesn’t seem to have a RTC. When I run this block in the bpython interpreter, the value of proc_1_boot_time is 4, which is Wed Dec 31 06:00:04 PM CST 1969
. The value of proc_uptime_boot_time is the correct uptime. So the get_boot_time() method should return the correct uptime.
I suspect the problem could have something to do with some processes starting when the clock was at the beginning of the UNIX epoch, so they are reported as having started before the most recent updates were applied.
I suspect you are correct. On my rpi4 I see the same thing when I run that command.
I have fully updated it and rebooted within the last hour and this is the result.
# needs-restarting -r
Core libraries or services have been updated since boot-up:
Reboot is required to fully utilize these updates.
More information: https://access.redhat.com/solutions/27943
In other words, it seems a bogus report since with no RTC the rpi4 and the RockPro64 have no way to know the actual time before the OS boots and is then able to get the time from an external source. The default time with no RTC is the beginning of the epoch as defined in computer time. Thu Jan 01 00:00:00 UTC 1970
I looked through dmesg output, and systemd starts before it detects that the system clock is wrong, then it advances the clock to the current time.
[ 4.427943] Run /init as init process
[ 4.431453] with arguments:
[ 4.431463] /init
[ 4.431470] rhgb
[ 4.431477] with environment:
[ 4.431484] HOME=/
[ 4.431490] TERM=linux
[ 4.431496] BOOT_IMAGE=(hd0,msdos2)/vmlinuz-6.0.16-300.fc37.aarch64
[ 4.468692] systemd: System time before build time, advancing clock.
Someone in the systemd channel on Libera.chat doesn’t believe it retroactively adjusts the start times of processes after advancing the clock, so the recorded time that a given process started may still be Dec 31, 1969.
When I run stat -c %z /proc/1 on my RockPro64:
1969-12-31 18:00:04.460000002 -0600
When I run stat -c %z /proc/1 on my regular PC (which has a RTC):
2023-01-06 14:55:04.783999995 -0600
The %z format checks the time of the last status change.
On my RockPro64, for an arbitrary process that started at a later time, like, say, dbus:
stat -c %z /proc/$(pgrep dbus | head -1)
2023-01-06 08:17:41.660000007 -0600
So it seems like systemd’s recorded real-time start time is the culprit.