If I look at the process table, it seems that the systemctl reload is being stucked forever:
/usr/bin/systemctl reload-or-restart --marked
If I attempt to kill the systemctl reload process, the update process is concluded as complete (only I choose to kill the systemctl process).
The host seems to be ok after reboot. So, why is it so? In fact, I have a quite number of AlmaLinux 9 hosts in my environment. Doing individual job killing is very inefficient. I remember that I had the same issue when updating 9.1 to 9.2. Thanks.
I updated a couple of machines yesterday from 9.2 to 9.3. One refused to start thanks to an EPEL dependency, but the other went through with no problems. Is there something unusual in your setup? BTW, 9.1 → 9.2 had no hiccoughs either.
Not sure if a setup can be considered unusual. Majority of the hosts had the same problem, while some small amount could go through though.
I spent some closer look, looking at the process table (ps auxww), and found that the problem was due to dracut-ing an initramfs-…-kdump file. A process “pkgconf” was listed as dead mode (D).
I then tried turning off kdump service (systemctl mask kdump), and everything goes ok since then. I don’t think that I need kdump files. So, this seems to solve the problem.
That may be a side effect of the change. I updated a handful machine and so far no issues with EPEL. But that may change over time or with specific packages.
No, it’s a timing issue. EPEL can lag behind by a few days up to a couple of weeks. Typically what happens is that in EPEL wants of , but following the upgrade the version available is <version+n>, so registers a problem and the whole upgrade aborts. Perfectly correct behaviour by DNF, the solution is either to be involved in EPEL maintenance, or to be patient until the issues are sorted.
Both RHEL and AlmaLinux release their point update content en masse – all at once.
So far RHEL has released before AlmaLinux.
There are thus two timepoints on the timeline: A (RHEL release) and B (AlmaLinux release)
EPEL starts to build for new target a bit before A, so they can release for new EL right after A.
Anything that EPEL releases before B can “break” AlmaLinux system. Thus from A ta B is risky.
However, EPEL is not one. It is many package collections with many maintainers. They do not all build at the same time nor release at the same time. Therefore, the release of some EPEL packages, “timepoint C”, can be clearly after B. Thus from A to C is risky.
One can contact EPEL to report issue so that the maintainers of relevant packages know to better prioritize their time.
Hello all
Yesterday I launched the next update on my test server Alma Linux 9.2 [kernel-5.14.0-284.30.1.el9_2.x86_64]. After a reboot, the server could not boot into the new kernel [kernel-5.14.0-362.8.1.el9_3.x86_64] While I configured it to work in the old kernel. Please tell me where to look for the problem? I think that the problem is in the old hardware and its drivers… Thank`s
