Bug 106848 - hangs, not erasing, and more
hangs, not erasing, and more
Product: Red Hat Linux Beta
Classification: Retired
Component: rpm (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-10-11 18:16 EDT by Ted Kaczmarek
Modified: 2007-04-18 12:58 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-19 07:21:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ted Kaczmarek 2003-10-11 18:16:25 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031003

Description of problem:
The dreaded hang is back.
rpm -q always return nothing on first attempt after a boot.
rpm -e fails, kill -9 and removing __db*'s not making a difference.
rpm --rebuilddb fails

Version-Release number of selected component (if applicable):
rpm-4.2.1-0.30 2.4.22-1.2088.nptl

How reproducible:

Steps to Reproduce:
1.Boot Fedora with kernel 2.4.22-1.2088.nptl
2. Open terminal, rpm -q
3. rpm -e

Actual Results:  Doesn't query on first attempt, erase not working and rebuilddb
not working.

Expected Results:  rpm -q works on first attempt, erase doesn't hang, rebuilddb
doesn't hang.

Additional info:

It seems work ok when erasing single packages, but multiple packages kill it
almost every time. Then after a while I can erase two packages, but then rpm -q
will fail again. I have yet to succesfully erase three packages with this
kernel/rpm version.
futex(0x403a8fb0, FUTEX_WAIT, 0, NULL

Hope this is helpful.
Comment 1 Jeff Johnson 2003-10-13 11:47:52 EDT
I need more details to even attempt a guess. AFAIK rpm is
doing the same job as always for thousands of people.

So what's different about your box?
Comment 2 Ted Kaczmarek 2003-10-19 07:21:46 EDT
After having filesystem issues and fsck'ing it, this problem has not been
happening anymore. Vlose this baby out, and I will make a note to myself to stay
away from the 2.6.0-test.X kernels :-)


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