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