Bug 115250 - A custom RPM causes corruption when installed with KickStart and somtimes when installed manually
A custom RPM causes corruption when installed with KickStart and somtimes whe...
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: rpm (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-09 12:15 EST by John Kerbawy
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-10 08:01:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
rpm -Uvvvh foo that turns into a loop of rpmdbNextIterator errors (5.68 KB, text/plain)
2004-02-09 19:18 EST, John Kerbawy
no flags Details

  None (edit)
Description John Kerbawy 2004-02-09 12:15:06 EST
Description of problem:
I'm having a weird problem when installing a custom RPM via KickStart
and sometimes manually. I've been making 10-20 custom RPMs for a
platform based on Red Hat Enterprise Linux and one specific RPM has
problems when installed with Red Hat. After installation, "rpm -q
adminpage" returns the following error message:

error: rpmdbNextIterator: skipping h#      83 Header SHA1 digest: BAD
Expected(f51d34a13f0dbe3018085f8afa0a6e145a7fe758) !=
(b018b1f085ca909c92e43c1d1c6541422fbbd19b)

The entire RPM database is not corrupt as I'm able to query for any
other RPM and get back the correct information. When I install this
RPM manually, it normally installs correctly, but in the past, there
were instances where the same error message would scroll forever. I'd
like to think I'm doing something wrong with building the RPM, but
I've done almost 20 other RPMs that install with KickStart and
manually just fine. In the KickStart installation, these custom RPMs
are installed correctly by generating a new hdlist with genhdlist.

I have to admit that I'm basically stumped on this. I think it's a bug
with the RPM system as I've made custom RPMs before and there's
nothing special about the custom RPM in question. Please let me know
if I can provide more information to get this problem solved.



Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
1. KickStart Red Hat Enterprise 3 with my custom "adminpage" RPM
2. Reboot
3. Run "rpm -q adminpage"

Actual Results:  $ rpm -q adminpage
error: rpmdbNextIterator: skipping h#      83 Header SHA1 digest: BAD
Expected(f51d34a13f0dbe3018085f8afa0a6e145a7fe758) !=
(b018b1f085ca909c92e43c1d1c6541422fbbd19b)

Additional info:
Comment 1 John Kerbawy 2004-02-09 19:18:13 EST
Created attachment 97545 [details]
rpm -Uvvvh foo that turns into a loop of rpmdbNextIterator errors

After installing a custom RPM via KickStart, the attached file is a log of rpm
-Uvvvh of the same package that spins off in a loop saying "error:
rpmdbNextIterator: skipping h#	    84 Header SHA1 digest: BAD
Expected(ff3785df9025926e635b816f80e643b7b85a892b) !=
(5bca18c88d1145c02505bd3161b587515741c9be)"
Comment 2 Jeff Johnson 2004-02-09 22:43:48 EST
Check the package for a setuid/setgid file owned by user/group
that cannot be looked up.

Is that the problem?
Comment 3 John Kerbawy 2004-02-09 22:54:51 EST
Yep, that has to be it. In %pre, a group is supposed to be added and
then a user with that group gets added. Later on, one of the four
files that gets installed is setgid to the group that was supposed to
be added. I do recall a few times where adding the group failed so I
appended "|| :" to the groupadd line like the httpd RPM does. Thanks
for pointing this out and hopefully the RPM system can be fixed to
support such package building errors.
Comment 4 Jeff Johnson 2004-02-10 08:01:20 EST
Disabling setuid/setgid bits on file owned by user/group that
cannot be looked up has be removed in rpm-4.2.2-0.8 and later.

That isn't exactly "support" for package building errors.


Note You need to log in before you can comment on or make changes to this bug.