View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000082 | Rocky-Linux-8 | dnf | public | 2022-02-03 09:43 | 2024-01-21 23:43 |
Reporter | Alex Corcoles | Assigned To | Release Engineering | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | open | ||
Summary | 0000082: dnf needs-restart does not work well on Raspberry Pi | ||||
Description | Hi, I think I got the update that supposedly fixes #190. dnf needs-restart now checks the uptime by looking at the mtime of /proc/1. This might work on other environments, but on a Raspberry Pi 4, this file has an mtime of 1970 and I cannot even touch it to fix it. So dnf needs-restart is completely borked there. Help? Álex | ||||
Tags | No tags attached. | ||||
To be clear, I think the bug is the mtime on /proc/1 on a Raspberry Pi. On other systems it's apparently the boot time. | |
Just adding an update here: I'm 99.9% certain this is because the Raspberry Pi has no internal clock, and so it defaults to Jan 1, 1970 (epoch) when the system does its early boot. I'm still pondering this issue, but I don't really have a good solution right now. Best bet as a workaround (for now) is to patch that DNF plugin to use a different source for system boot time. I would expect this same behavior on any system with no internal clock, a dead CMOS battery, etc. Still brainstorming if there's a better solution to this. |
|
Yeah, I had no idea that the RPI has no clock :( Everything fits that explanation, IMHO. My only concern is that I don't think RHEL 8 supports any hardware with a "malfunctioning" clock, so they might be hesitant to patch the DNF plugin to do the proper thing (although I *think* that's the most correct solution). I am happy to file a bug (to the CentOS 8 bug tracker, corresponding to the DNF plugin RPM, I assume?) and see how that plays out. (If you have a more direct communication with upstream, maybe you want to report that yourself?) Thinking out a little bit, the other options I can think of: * Do something similar to fake-hwclock. However, fake-hwclock specifically seems to be a systemd service, so I think it would be too late for this to work. And I didn't see anything like a kernel command-line parameter that lets you set a custom time. * Find a way to change the mtime of /proc/1 when the date is set via NTP. I only thought to remount /proc, but that doesn't seem to change anything * Create an alternate package just for Rocky Linux 8 / RPI that overrides the DNF plugin. I think this option is worse than all other proposals. Let me know your thoughts. If I don't hear anything, I'll file a bug to CentOS 8 Stream python3-dnf-plugins-core in 1-2 days. Cheers, Álex |
|
I filed https://bugzilla.redhat.com/show_bug.cgi?id=2082295 , following the instructions at https://github.com/rpm-software-management/dnf-plugins-core#bug-reporting-etc . | |
In case anyone is serious, this likely is fixed in EL9: https://gitlab.com/redhat/centos-stream/rpms/dnf-plugins-core/-/blob/c9s/0006-Fix-boot-time-derivation-for-systems-with-no-rtc.patch?ref_type=heads |
|
Dang, I updated to Rocky 9 and I get: $ sudo dnf needs-restarting -r Core libraries or services have been updated since boot-up: * dbus * dbus-broker * glibc * linux-firmware * systemd after a reboot :( |
|
BTW, some time ago, dnf needs-restarting -r started working properly in EL9 on RPI4. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2022-05-03 14:46 | Skip Grube | Note Added: 0000113 | |
2022-05-03 16:48 | Alex Corcoles | Note Added: 0000115 | |
2022-05-05 18:19 | Alex Corcoles | Note Added: 0000116 | |
2023-08-10 18:18 | Alex Corcoles | Note Added: 0004324 | |
2023-09-16 12:07 | Alex Corcoles | Note Added: 0004621 | |
2024-01-21 23:43 | Alex Corcoles | Note Added: 0005611 |