Description of problem: When installing the latest rawhide (20060831), the installation dies and jumps into the python debugger. Version-Release number of selected component (if applicable): 20060831 How reproducible: 100% Steps to Reproduce: 1. Attempt to NFS install rawhide-20060831 Actual results: When writing to disk finally starts, the following error is seen: Traceback (most recent call last): File "/usr/bin/anaconda", line 944, in ? anaconda.intf.run(anaconda) File "/usr/lib/anaconda/text.py", line 540, in run anaconda.dispatch.gotoNext() File "/usr/lib/anaconda/dispatch.py", line 123, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 200, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/packages.py", line 138, in turnOnFilesystems anaconda.id.diskset.savePartitions () File "/usr/lib/anaconda/partedUtils.py", line 865, in savePartitions self.refreshDevices() File "/usr/lib/anaconda/partedUtils.py", line 870, in refreshDevices self.closeDevices() File "/usr/lib/anaconda/partedUtils.py", line 877, in closeDevices self.stopMPath() File "/usr/lib/anaconda/partedUtils.py", line 591, in stopMPath dmraid.stopAllMPath(DiskSet.mpList) File "/usr/lib/anaconda/dmraid.py", line 280, in stopAllMPath stopMPath(mp) File "/usr/lib/anaconda/dmraid.py", line 270, in stopMPath mp.deactivate() File "/usr/lib/python2.4/site-packages/block/device.py", line 488, in deactivate self._MultiPath__map.remove() File "/usr/lib/python2.4/site-packages/block/__init__.py", line 15, in dm_log raise Exception, message Exception: device-mapper: remove ioctl failed: Device or resource busy Entering debugger... > /usr/lib/python2.4/site-packages/block/__init__.py(15)dm_log() -> raise Exception, message (Pdb) Expected results: No error should be seen. Additional info: There is the appearance of memory corruption on the latest ia64 builds. Not sure if this is related or not...
This still happening?
Created attachment 135812 [details] /tmp/anacdump.txt Seeing this with rawhide-20060907 i386
See comment#2 ... seeing this against rawhide-20060907
Also with rawhide-20060908
jlaska and dkl, <4>============================================= <4>[ INFO: possible recursive locking detected ] <4>2.6.17-1.2630.fc6 #1 <4>--------------------------------------------- <4>lvm/614 is trying to acquire lock: <4> (&md->io_lock){----}, at: [<f8a5d42f>] dm_request+0x18/0xcd [dm_mod] <4> <4>but task is already holding lock: <4> (&md->io_lock){----}, at: [<f8a5d42f>] dm_request+0x18/0xcd [dm_mod] <4> <4>other info that might help us debug this: <4>1 lock held by lvm/614: <4> #0: (&md->io_lock){----}, at: [<f8a5d42f>] dm_request+0x18/0xcd [dm_mod] <4> <4>stack backtrace: <4> [<c04037db>] show_trace_log_lvl+0x58/0x171 <4> [<c0403db6>] show_trace+0xd/0x10 <4> [<c0403e53>] dump_stack+0x19/0x1b <4> [<c042be6f>] __lock_acquire+0x765/0x97c <4> [<c042c5f7>] lock_acquire+0x4b/0x6c <4> [<c04296ec>] down_read+0x2d/0x3f <4> [<f8a5d42f>] dm_request+0x18/0xcd [dm_mod] <4> [<c04c7ce0>] generic_make_request+0x28e/0x29e <4> [<f8a5c437>] __map_bio+0xc0/0xee [dm_mod] <4> [<f8a5ccdd>] __split_bio+0x158/0x3a0 [dm_mod] <4> [<f8a5d4d6>] dm_request+0xbf/0xcd [dm_mod] <4> [<c04c7ce0>] generic_make_request+0x28e/0x29e <4> [<c04c99b2>] submit_bio+0xa1/0xa9 <4> [<c047e9ca>] dio_bio_submit+0x4f/0x61 <4> [<c047f7c3>] __blockdev_direct_IO+0x8fa/0xc52 <4> [<c046657f>] blkdev_direct_IO+0x30/0x35 <4> [<c04449e3>] generic_file_direct_IO+0x88/0xe4 <4> [<c0444bea>] __generic_file_aio_read+0xb7/0x1ad <4> [<c0445bbc>] generic_file_read+0x87/0x9b <4> [<c045f6c8>] vfs_read+0xa9/0x15b <4> [<c045fa54>] sys_read+0x3b/0x60 <4> [<c0402e57>] syscall_call+0x7/0xb <4>DWARF2 unwinder stuck at syscall_call+0x7/0xb <4>Leftover inexact backtrace: <4> [<c0403db6>] show_trace+0xd/0x10 <4> [<c0403e53>] dump_stack+0x19/0x1b <4> [<c042be6f>] __lock_acquire+0x765/0x97c <4> [<c042c5f7>] lock_acquire+0x4b/0x6c <4> [<c04296ec>] down_read+0x2d/0x3f <4> [<f8a5d42f>] dm_request+0x18/0xcd [dm_mod] <4> [<c04c7ce0>] generic_make_request+0x28e/0x29e <4> [<f8a5c437>] __map_bio+0xc0/0xee [dm_mod] <4> [<f8a5ccdd>] __split_bio+0x158/0x3a0 [dm_mod] <4> [<f8a5d4d6>] dm_request+0xbf/0xcd [dm_mod] <4> [<c04c7ce0>] generic_make_request+0x28e/0x29e <4> [<c04c99b2>] submit_bio+0xa1/0xa9 <4> [<c047e9ca>] dio_bio_submit+0x4f/0x61 <4> [<c047f7c3>] __blockdev_direct_IO+0x8fa/0xc52 <4> [<c046657f>] blkdev_direct_IO+0x30/0x35 <4> [<c04449e3>] generic_file_direct_IO+0x88/0xe4 <4> [<c0444bea>] __generic_file_aio_read+0xb7/0x1ad <4> [<c0445bbc>] generic_file_read+0x87/0x9b <4> [<c045f6c8>] vfs_read+0xa9/0x15b <4> [<c045fa54>] sys_read+0x3b/0x60 <4> [<c0402e57>] syscall_call+0x7/0xb is interesting and might be leading to the failure. Adding Peter and Eric ....
I'm moving this to the device-mapper.
Lock backtrace mentioned in comment 5 is only warning (and false positive in this case, we have bug 204311 for this problem) and it should not cause fail in correct lvm command. Reassigning back to anaconda.
We have not seen this in a long time as far as I can tell. Closing it.