Red Hat Bugzilla – Bug 466996
while updating, yum removed the currently booted kernel
Last modified: 2014-01-21 18:06:45 EST
I've got a laptop following rawhide. During the transition to kernel 2.6.27, ext4dev got changed to ext4 and before this info was widely publicised, I had several kernels that wouldn't boot. I kept going back to booting a working older kernel. After the third 2.6.27 kernel update was installed, yum? removed the oldest and currently booted kernel, leaving me with an unbootable system.
I'm 99% sure that yum didn't used to do this, that the currently booted kernel was always one that was kept.
Just thought I should add that it's possible that the last update where the booted kernel was removed could have been done through packagekit. I don't know if that matters since it ultimately operates through yum but maybe it does so at a lower level where it applies it's own logic?
Are you sure you were running it when it was removed?
What is installonly_limit set to?
Going to set to PK, unless something looks suspicious.
Shouldn't be PK specific, PK just does a yum transaction.
I'm positive given that the newer kernels wouldn't boot due to the ext4dev filesystem not being supported. I couldn't run the new kernels so I had to keep running the old one. After it was removed and my laptop no longer booted, I went digging and found that the ext4dev -> ext4 transition was the cause. I'll see if I can duplicate it. I'll boot the oldest kernel before the next new kernel update.
I've had the same happen with plain rpm -Fhv *.rpm in a dir which accidentally had a newer kernel rpm in it. I'd expect rpm not to remove the currently running kernel.
Well rpm is going to remove the currently running kernel. rpm has no mechanisms included to stop itself from doing that.
Yum, otoh, has a bunch of code in place to keep it from doing that.
To expand on that: rpm -F does an _upgrade_ if you have those pacakges installed, upgrade means remove the installed version and install the new version.
yum upgrade kernel-<version>
...is more intelligent, because it knows kernels should only be installed and not upgraded (but then installonly_limit will then remove the old versions again, if configured to do so).
RPM doesn't know any of this, and just does what you tell it to (one of many reasons not to use it directly).
I don't see how the installonly_limit could make yum uninstall the running kernel though ... which is why I wondered if it was PK (or that a different kernel was running).
On my system, installonly_limit=3, which I have never changed.
I've tried and can't duplicate this. I'm not sure what combinations of things caused it but it at least doesn't happen regularly.
Okay, if you can reproduce, then please reopen. Thanks.