Bug 125749
Summary: | up2date SEGV's on new RHEL3u2 install | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | James Antill <james.antill> | ||||
Component: | rpm | Assignee: | Jeff Johnson <jbj> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Mike McLean <mikem> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | msw | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-06-11 13:34:54 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
James Antill
2004-06-10 20:40:02 UTC
Created attachment 101048 [details]
gdb --args python /usr/sbin/up2date -l
Hmmm, -0.14 not what is in QU2, afaik. you might want to upgrade. No matter. Do the following: cd /var/lib/rpm rm __db* /usr/lib/rpm/rpmdb_verify Packages If that fails, the fix is mv Packages Packages-ORIG /usr/lib/rpm/rpmdb_dump Packages-ORIG |\ /usr/lib/rpm/rpmdb_load Packages and until rpmdb_verify passes. Then rpm --rebuilddb -vv to regenerate the indices. Finally, rpm -qa -vv to verify that the headers are intact. If that passes, I think you are alright. If not, append the output of rpm -qa -vv and I'll tell you what to do. According to both up2date and ... https://rhn.redhat.com/network/software/packages/name_overview.pxt?package_name=rpm&channel_arch_ia32=&channel_arch_ia64=&channel_arch_x86_64=&search_subscribed_channels=1 0.14 is the latest for RHEL3. I did all the rpm rebuild stuff, and none of it printed out anything that looked like an error. And I thought it had fixed itself, but then realised that I was running via. sudo and so /usr/bin was in front of /usr/sbin so consolehelper was fork()ing the actual up2date which was still SEGV'ing (apart from "up2date -u" not doing anything everything works fine). Attached is the tar file of stdout/stderr for the: rpm -qa -vv Just in case the above wasn't clear, I did: cd /var/lib/rpm rm __db* /usr/lib/rpm/rpmdb_verify Packages rpm --rebuilddb -vv rpm -qa -vv [ran up2date ... ] rpm -qa -vv > /tmp/rpmqavv_stdout 2> /tmp/rpmqavv_stderr OK, your database is find, that's the 1st step. The strace showed rpmdb activity, easily identified by pread(2) calls. up2date can segfault with bad data in /var/spool/up2date as well. Can you try up2date with -vv? that turns on rpm debugging, and I can often guess what the problem is from seeing the spew. If it looks like a hdr read in /var/spool/'up2date, you might try nuking that file, or all the headers there. Network problems can corrupt rpm hdrs, and the format was never designed to detect errors. So segfaults can/will happen sometimes. Arggggh, the header problems I'd seen before happened just after up2date opened the .hdr files. But, yes, going through the packages to install I realized that "up2date -u squid" was not working and a "rm /var/spoool/up2date/squid*" fixed everything. Resolved. |