efa-project.org

If yum fails due to lack of RAM ("Cannot allocate memory"), then the EFA updater ignores this and proceeds regardless.

The rest of the update completed (although ^Z to suspend it to check the RAM just froze the entire update process, so I rebooted and tried again) but the kernel update was skipped and now it's impossible to resolve this using the stock configuration. yum list only shows .642 series kernels now, and the .696 headers package that I couldn't remove as some software is already using it.

I resumed the suspended yum transaction for the kernel update, but all that did was remove the old kernel (the one actually in use, .642) without completing installing the new one.

Now the current kernel (.696) isn't actually an available package. I removed the .696 packages (except headers) in an attempt to reinstall them, and this worked, but now I can't put them back. In a copy/paste error I removed the .642 kernel-devel package, but now I can't put that one back either.

It would have been preferable to detect that yum failed originally, and suspend/abort the EFA update, as it would have avoided yum getting itself thoroughly confused by crashing out in the middle of an update.

(I guess EFA needs more RAM that it did in the past — I've increased the VM memory allocation.)

Ah, I see …

I had a feeling that EFA update was manipulating yum — kernel updates were blocked in /etc/yum.conf (which I can see was modified earlier this evening), which is why yum was furtively ignoring all attempts to get it to update the kernel.

Once the first yum update fell over, EFA update ignored the error, rewrote yum.conf to ignore the kernel and then updated all the other packages in a second phase. The post-kernel-update reboot didn't run though, so it somehow knew that there was no new kernel to reboot for, but didn't stop the update process before blocking future kernel updates.

Fixing in 3.0.2.2. Adding error checking to kernel update phase.