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:
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)"
Check the package for a setuid/setgid file owned by user/group that cannot be looked up. Is that the problem?
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.
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.