Bug 372421 - yum should have some form of journaling
yum should have some form of journaling
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-09 05:01 EST by Carl-Johan Kjellander
Modified: 2014-01-21 18:00 EST (History)
4 users (show)

See Also:
Fixed In Version: 3.2.7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-09 08:33:22 EST
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 Carl-Johan Kjellander 2007-11-09 05:01:10 EST
Description of problem:
The problem is, if a large yum update fails, say for instance a major upgrade
from F7 to F8, you are stuck with half an upgrade and an inconsistent rpm
database. For instance my upgrade on x86_64 got stuck cleaning up libgfortran:

  Cleanup   : libgnomeui-devel             ################### [2704/3121] 
  Cleanup   : libXvMC                      ################### [2705/3121] 
  Cleanup   : GConf2                       ################### [2706/3121] 
  Cleanup   : games-menus                  ################### [2707/3121] 
  Cleanup   : gnome-user-docs              ################### [2708/3121] 
  Cleanup   : pax                          ################### [2709/3121] 
  Cleanup   : libgfortran                  ################### [2710/3121] 
  Cleanup   : libgfortran                  ################### [2711/3121] 

And then it was frozen.

Version-Release number of selected component (if applicable):
The latest one for F7.

How reproducible:
I has happened to me over 10 times since the FC2 era.

Steps to Reproduce:
1. Use systems normally and do incremental upgrades, and sometimes
   big ones between versions of fedora. Add extra third party repos
   and remove those. Normal use for the OS so to speak.
  
Actual results:
Yum hangs, gets stuck, fails or some app you are updating crashes,
like Xorg for instance killing yum in the process. You'll get halfway
through and have an inconsistent database in the process.

Expected results:
Yum should have sort of a journal, so that it can restart were it left
off and finish what it started. It's no use having a journaling filesystem
if the OS tools can make the system unupgradeable which is the end result
of having it break halfway through clean-up.

Another thing would be for yum to break up the upgrade into smaller consistent
batches that it can apply one at a time, so if an upgrade breaks, you don't
have to redo the whole 1600 packages. I kinda don't like that there is several
hours of work between the upgrading and subsequent cleanup of a package. That
is just begging for something to go wrong in between, and actually increases
the risk of errors thousandfold.

Additional info:
What I usually do to work around these broken upgrades is to do:

  rpm -Uvh --force *.rpm

inside the /var/cache/yum dirs and try to force the upgrade once more.
Really annoying and takes hours if you have 1600 rpms to redo.

And is there anything I can do with my stuck yum this time (on libgfortran)
but to kill it?
Comment 1 Seth Vidal 2007-11-09 08:33:22 EST
yum has a journal.

go to /var/lib/yum

look at the transaction-all-$time and transaction-done-$time files

if you take the entries from transaction-done and remove them from
transaction-all you can pass the entries, verbatim, to a yum shell

so remove the entries of transaction-done from transaction-all
then run:
yum shell transaction-all

it'll take you to a prompt
just type 'run'


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