[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: recover from broken yum transaction

On Tue, 2008-09-23 at 12:03 +0300, Panu Matilainen wrote:
> 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.

 I think Seth meant "I find it impossible that rpm has a bug/feature
which would allow this to happen" ... but he's just way too much of a
raving optimist :).

>  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.

 I think I've worked around the "normal" cases on the yum side with:




...although it doesn't "fix" the patch above, I think it'll work around
the ssh case ... Alexandre, if you can reproduce it can you try it with
the latest from the yum-3_2_X branch?

James Antill <james antill redhat com>
Red Hat

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]