hash changed for external rpm

Mike McLean mikem at redhat.com
Wed Mar 24 21:17:16 UTC 2010


On 03/24/2010 11:40 AM, Connie Sieh wrote:
>> Generally speaking, you should not attempt to solve koji issues by
>> making direct db changes.
>
> I was not trying to fix the issue but understand it better.  The rpm at
> the repo has the hash that was in the database but when koji gets it and
> checks it is different.  I was trying to verify where koji was getting the
> "wrong" hash from.  I still do not know where the wrong hash is coming
> from because it is correct in the actual external repo.

Fair enough. I've just seen more than a few folks alter their db 
unnecessarily and I tend to caution against it.

> How does koji download the rpm.  I have assumed that yum does the heavy
> lifting to get the rpm from the external repo.  Could there be a
> incompatability between how the rpm hash was added to the external repo as
> this is a RHEL 5 repo and thus used the RHEL 5 rpm to add the hash vs the
> code that is in Fedora 12?

Yes, koji doesn't download external rpms. Yum does.

An external rpm is added to the database when a kojid instance makes a 
call to update the buildroot contents. It gets this data by querying the 
rpmdb from the buildroot. So if the entry is in your db, then at some 
point kojid found it in a buildroot. Yum should flat out refuse to 
install an rpm that doesn't match its sigmd5, so I doubt the data could 
have been incorrect at the time of the build.

As for possible incompatibilities. I don't think the sigmd5 header in 
rpm has changed in a long time. Plus, if yum/rpm got the sigmd5 value 
wrong, it wouldn't have matched the contents and it would have refused 
to install in the buildroot.

Also keep in mind that all the yum/rpm operations in kojid use the 
yum/rpm of the host system, not the buildroot.

> I verifyed that the external repo rpm has NOT changed.

How did you verify this?

> So I looked in the database rpminfo table for termcap and did see the
> dbb204 hash.  I changed it to the 586d65 hash just to see if it would now
> match. I reran the build.  Now it gets the "rpm" hash right but the
> database is wrong.  How do I resync the repodata from my external
> repository?  I have done way too many regen-repo in an attempt to fix
> this.
>
> ----------------------------------------------------------------------------
> 5366 build (dist-sl5, bash-3.2-24.el5.src.rpm): open (sl6) -> FAILED:
> GenericError: hash changed for external rpm:
> termcap-5.5-1.20060701.1.noarch at dist-sl5-external-repo-base
> (586d659bf4699215a13ba57a4422bb34 -> dbb20448cc979898c065cc4e551a926c)
> ----------------------------------------------------------------------------

So let me see if I've got the order of things correct.
1. Got hash changed error showing dbb2* -> 586d*
2. Determine that the sigmd5 for the rpm in question really is dbb2*
3. Check database, find rpminfo entry showing dbb2*, changed it to 586d*
3. Now the same build reports the opposite hash change: 586d* -> dbb2*

It seem, as you said, that 586d* is the mystery here. Showed up in one 
buildroot unexpectedly and now seems to have disappeared. Let's see what 
turns up in the db.

Try running these queries:

select payloadhash, external_repo.name from rpminfo left outer join 
external_repo on external_repo_id = external_repo.id where rpminfo.name 
= 'termcap' and version='5.5' and release='1.20060701.1' and arch='noarch';

select rpminfo.name, version, release, arch, payloadhash, 
external_repo.name from rpminfo left outer join external_repo on 
external_repo_id = external_repo.id where payloadhash = 
'586d659bf4699215a13ba57a4422bb34';

Also, look at the repo used for task 5366 and compare it to the repo 
used for task 5329. Look at the repodata pertaining to termcap as well 
as the pkgorigins file. Unfortunately the repodata does not include 
sigmd5, but it should at least show if the rpm changed between the two 
repos.


More information about the buildsys mailing list