recover from broken yum transaction

Panu Matilainen pmatilai at laiskiainen.org
Tue Sep 23 09:03:10 UTC 2008


On Mon, 22 Sep 2008, seth vidal wrote:

> On Mon, 2008-09-22 at 15:47 -0300, Alexandre Oliva wrote:
>
>> Right.  The problem is when you agree to "update x", i.e., "install
>> x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or
>> sys.stdout.flush raise an exception within callback) before it gets to
>> install x-N+1.  Then RPM still ends up removing x-N, although
>> sometimes what I saw looked more like a --justdb removal (files and
>> libraries left behind, but package gone from the rpmdb), but in
>> others, as in the most recent case, elfutils libraries were really
>> gone.
>
> The above really isn't possible. If you can recreate this then please
> file a bug. File the bug against rpm but please cc me on it.

I wouldn't call it impossible, in fact I just managed to reproduce it with 
this:
--- a/yum/rpmtrans.py
+++ b/yum/rpmtrans.py
@@ -374,6 +374,7 @@ class RPMTransaction:
                  self.total_installed += 1
                  self.complete_actions += 1
                  self.installed_pkg_names.append(hdr['name'])
+                raise IOError
              return fd
          else:
              self.display.errorlog("Error: No Header to INST_OPEN_FILE")


Without having yet looked deeper into it, it probably comes down to this 
in rpmtsRun():
     /*
      * XXX This has always been a hack, now mostly broken.
      * If install failed, then we shouldn't erase.
      */

The hack in question is easily fooled, and so rpm is ultimately 
responsible for the damage that results from yum code tracebacking in the 
transaction callback. Rpm needs fixing (I'll go look into it right now), 
but I'd suggest you go and comb through the ts callback code in yum - you 
do NOT want it tracebacking, especially on "trivial" things like 
sys.stdout operations failing.

 	- Panu -




More information about the fedora-devel-list mailing list