Description of problem: I downloaded the august 18 boot.iso and tried to ftp install rawhide. I answer all of the questions, click on next to start the install and then nothing. No errors, no messages, no packages. The system still respondes to keystrokes. I can switch windows, but after an hour of waiting no packages download. I tried two different ftp sites (yes they are updated with todays packages) and the same results. Version-Release number of selected component (if applicable): whatever is in the august 19th boot.iso How reproducible: always Steps to Reproduce: 1. boot august 19th boot.iso 2. do a ftp install 3. answer all questions, start install, then nothing Actual results: no packages are downloaded Expected results: packages should download Additional info:
OK a little more information. The delay I am seeing is during the modification of anaconda.log during: 08:10:17 INFO : moving (1) to step installpackages 08:10:17 INFO : Preparing to install packages 08:10:17 DEBUG : Member: vixie-cron.i386 4-4.1-58.fc6 - u 08:10:19 DEBUG : Adding Package vixie-cron - 4:4.1-58.fc6.i386 in mode u 08:10:19 DEBUG : Member: rhpl.i386 0-0.188-1 - u 08:10:21 DEBUG : Adding Package rhpl - 0.188-1.i386 in mode u 08:10:21 DEBUG : Member: ncurses.i386 0-5.5-23.20060715 - u 08:10:24 DEBUG : Adding Package ncurses - 5.5-23.20060715.i386 in mode u 08:10:24 DEBUG : Member: elfutils-libs.i386 0-0.123-1.fc6 - u it takes about an hour to finish filling it. Then the download begins but dies. It might have to do with: 4> <4>============================================= <4>[ INFO: possible recursive locking detected ] <4>2.6.17-1.2571.fc6 #1 <4>--------------------------------------------- <4>anaconda/432 is trying to acquire lock: <4> (&bdev->bd_mutex){--..}, at: [<c04658bb>] __blkdev_put+0x1f/0x11f <4> <4>but task is already holding lock: <4> (&bdev->bd_mutex){--..}, at: [<c0465b4e>] do_open+0x6b/0x3b2 <4> <4>other info that might help us debug this: <4>1 lock held by anaconda/432: <4> #0: (&bdev->bd_mutex){--..}, at: [<c0465b4e>] do_open+0x6b/0x3b2 <4> <4>stack backtrace: <4> [<c04037db>] show_trace_log_lvl+0x58/0x159 <4> [<c0403d9e>] show_trace+0xd/0x10 <4> [<c0403e3b>] dump_stack+0x19/0x1b <4> [<c042bddb>] __lock_acquire+0x765/0x97c <4> [<c042c563>] lock_acquire+0x4b/0x6c <4> [<c05f37ee>] mutex_lock_nested+0xcb/0x214 <4> [<c04658bb>] __blkdev_put+0x1f/0x11f <4> [<c04659d4>] blkdev_put+0xa/0xc <4> [<c0465e26>] do_open+0x343/0x3b2 <4> [<c0466030>] blkdev_open+0x1f/0x48 <4> [<c045d83c>] __dentry_open+0xb8/0x186 <4> [<c045d978>] nameidata_to_filp+0x1c/0x2e <4> [<c045d9b9>] do_filp_open+0x2f/0x36 <4> [<c045da00>] do_sys_open+0x40/0xbb <4> [<c045daa7>] sys_open+0x16/0x18 <4> [<c0402e57>] syscall_call+0x7/0xb <4>DWARF2 unwinder stuck at syscall_call+0x7/0xb <4>Leftover inexact backtrace: <4> [<c0403d9e>] show_trace+0xd/0x10 <4> [<c0403e3b>] dump_stack+0x19/0x1b <4> [<c042bddb>] __lock_acquire+0x765/0x97c <4> [<c042c563>] lock_acquire+0x4b/0x6c <4> [<c05f37ee>] mutex_lock_nested+0xcb/0x214 <4> [<c04658bb>] __blkdev_put+0x1f/0x11f <4> [<c04659d4>] blkdev_put+0xa/0xc <4> [<c0465e26>] do_open+0x343/0x3b2 <4> [<c0466030>] blkdev_open+0x1f/0x48 <4> [<c045d83c>] __dentry_open+0xb8/0x186 <4> [<c045d978>] nameidata_to_filp+0x1c/0x2e <4> [<c045d9b9>] do_filp_open+0x2f/0x36 <4> [<c045da00>] do_sys_open+0x40/0xbb <4> [<c045daa7>] sys_open+0x16/0x18 <4> [<c0402e57>] syscall_call+0x7/0xb <6>kjournald starting. Commit interval 5 seconds
*** This bug has been marked as a duplicate of 201773 ***