Bug 466996 - while updating, yum removed the currently booted kernel
while updating, yum removed the currently booted kernel
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-14 20:25 EDT by Thomas J. Baker
Modified: 2014-01-21 18:06 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-26 06:30:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thomas J. Baker 2008-10-14 20:25:34 EDT
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.
Comment 1 Thomas J. Baker 2008-10-14 20:29:19 EDT
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?
Comment 2 James Antill 2008-10-14 22:55:15 EDT
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.
Comment 3 Richard Hughes 2008-10-15 03:23:28 EDT
Shouldn't be PK specific, PK just does a yum transaction.
Comment 4 Thomas J. Baker 2008-10-15 08:38:51 EDT
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.
Comment 5 Yanko Kaneti 2008-10-15 10:26:00 EDT
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.
Comment 6 seth vidal 2008-10-15 10:27:44 EDT
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.
Comment 7 James Antill 2008-10-15 10:43:26 EDT
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).
Comment 8 Thomas J. Baker 2008-10-15 10:55:21 EDT
On my system, installonly_limit=3, which I have never changed.
Comment 9 Thomas J. Baker 2008-10-22 11:30:00 EDT
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.
Comment 10 Richard Hughes 2008-10-26 06:30:16 EDT
Okay, if you can reproduce, then please reopen. Thanks.

Note You need to log in before you can comment on or make changes to this bug.