Re: recover from broken yum transaction

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

 



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:

http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=cf896fc7ccc135aeb94d69739bb625fc44934377

and

http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=0aed92573666a4e09650e5a5c0f25357ac957d2a

...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@xxxxxxxxxx>
Red Hat

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

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux