Red Hat Bugzilla – Bug 819571
Software updates fail when a redundant kernel removal isn't done first
Last modified: 2013-02-13 16:32:36 EST
Description of problem:
When ever I run updates on Fedora 16 I get a failure to complete due to running out of space in /boot. My boot partition was set to the recommended size of 100 meg when i built the machine last year, which seems to be too small now espacially as the updater isn't carrying out removals before it tries to install new items/updates.
Version-Release number of selected component (if applicable):
Version of updater in the Fedora 16 - ( I think it was also a problem with 15, but I didn't use 15 as much as I do 16 now.
Happens everytime I run updates as so far all have included a new Kernel.
Steps to Reproduce:
1. When updates are indicated - choose to install them.
2. Do not remove any old Kernel yourself first, but allow the update process to flag the old kernel it's going to remove during update.
3. Enter the authentication password.
Soon after the update process starts and dependencies if any have been flagged, and you've entered the authentication password, the update stops with a Transaction error indicated.
Looking at the details of the error message it show there was a lack of space on /boot. typically it's short by a few megabytes.
In the details it does give advice about running yum-complete-transaction, but that doesn't work for me. In fact when Ive run this command
"yum-complete-transaction", the system gets stuck in a loop which never ends, untill Fedora kills the process itself after about an hour.
Aslo at the point the update process stopped, I also find software management application will not work either, for me it often says the application can't initialise.
After reading about the transaction issues and how to clean them up, the only way I find to fix my update processes is to run the following.
Stage one.. Run the following commands
Start "Software Management" search for the Kernel which the update process was supposed to be removing and remove it now.
Rerun update process.
This time it generally runs right through as it no longer has to remove a kernel and finds enough space in /boot.
I would expect the Fedora update process to remove the old Kernel (and old software) itself first so as to make space for the new updates.
If the update process was configured to do the removals first it should avoid the issue of running out of /boot space. It looks to me that even though it has flagegd a kernel for removal it isn't doing it before it has attempted to install the new one and updated software. And this is causing the system to run out of space on /boot part way through.
Also yum-complete-transaction is not reliable process to run, as it's causing me lockups due to loops.
I am running both a 64 bit version of Fedora on one machine and a 32 bit version on another, both have the same update bug. Both can be solved by the same methods.
I assume this same problem is reproducible using a simple:
too, would be nice if you could verify that. If so...
I believe removals are always done last, and I don't think there's any way around that design/policy decision.
My only suggestion would be to consider reducing the default
in /etc/yum.conf to 2
I could be wrong, but iirc, the default /boot partition size since since (at least) f16 is supposed to be 500mb
(In reply to comment #2)
> I assume this same problem is reproducible using a simple:
> 'yum update'
> too, would be nice if you could verify that. If so...
> I believe removals are always done last, and I don't think there's any way
> around that design/policy decision.
> My only suggestion would be to consider reducing the default
> in /etc/yum.conf to 2
I just tried 'Yum update' on one of my other Fedora systems which also has 100 meg /boot partition and I found yum update had no problems at all. It also had to remove an old kernel but seems to have done it before it actually installed the new kernel, going by the output in the terminal, as it listed the removal of the old kernel before it listed it had installed the new kernel.
I shall try the option to restrict old kernels and see how that goes the next time.
It would be worth flagging that using 'yum-complete-transaction' as suggested by the error mesages when updater failed, can cause the transactions the command attempts to complete, to be re-run repeatedly untill Fedora gets tired and actually kills the process.
And even after that, Fedora is left with hung transactions so updater or software manager won't initialise. I had that each time I ran 'yum-complete-transaction'.
But eventually located the tip about using
'yum-complete-transaction --cleanup-only' instead, which after use allowed me to run software management and remove the old kernel. then run updater again.
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '16'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 16's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 16 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" and open it against that version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.