From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.8) Gecko/20061108 Fedora/1.5.0.8-1.fc5 Firefox/1.5.0.8 Description of problem: Every time I try to either upgrade or do a fresh install from the FC6 x86_64 DVD, it completes the dependency checking, reports on one VT (2?) "INFO: moving (1) to step confirminstall", then hangs. Another VT (4?) reports a crash in squashfs: <3> VSF: brelse: Trying to free free buffer <4> BUG: warning at fs/buffer.c:1277/__brelse() (Not tainted) <4> <4> Call trace: [left stuff in trace not copied] show_trace+0x34/0x47 dump_stack+0x12/0x17 __find_get_block+0x153/0x16c __getblk+0x1d/0x245 :squashfs:squashfs_read_data+0x10d/0x57c :squashfs:squashfs_readpage+0x146/0x416 __do_page_cache_readahead+0x162/0x1da blockable_page_cache_readahead+0x56/0xb5 page_cache_readahead+0xd6/0x1af do_generic_mapping_read+0x126/0x41d __generic_file_aio_read+0x16c/0x1bf generic_file_read+0xac/0xc5 vfs_read+0xcb/0x171 sys_read+0x45/0x6e system_call+0x7e/0x83 <4> DWARF2 unwinder sutck at system_call+0x73/0x83 <4> leftover inexact backtrace: <4> (I appologize for any typos.) The sha1sum of the ISO matches. I've dd'ed a copy of the DVD back into a file, and the sha1sum still matches, so it is not a bad DVD. Note that the dependency checking has completed when this happens, and leaving the system along for hours at this point does not accomplish anything. This is NOT the bug reported elsewhere that dependency checking is slow. The actual bug might be in the kernel or the squashfs utilities. It may be related to bug 211237. However, 211237 is about a crash in random testing which would not affect normal users, while this case causes a complete inability to install. The system configuration is: Asus A8V Deluxe motherboard AMD Athlon 64 X2 4800+ dual core CPU 2 GB of PC3200 ECC DDR memory (two 1 GB DIMMs) two Seagate Barracuda SATA drives, attached to Via chipset ports on motherboard Sapphire AGP graphics card using ATI Radeon 9550 (RV350) USB keyboard and mouse The disks are each have two partitions. /dev/sda1 and /dev/sdb1 are used as a RAID 1 (/dev/md0) for /boot /dev/sda2 and /dev/sdb2 are used as a RAID 1 (/dev/md1) for an LVM physical volume The LVM physical volume contains partitions for root (/), swap, and /home. The system is running FC5 x86_64; there was no problem installing that. I have successfully installed from the same DVD onto another machine not using RAID, and that was successful. It is possible that this problem is provoked by the use of RAID, but I have not proven that. Version-Release number of selected component (if applicable): FC6 x86_64 DVD How reproducible: Always Steps to Reproduce: 1. Fresh install FC6 x86_64 to a system with the disk configured with RAID 1 and LVM as described above, *or* update FC6 x86_64 onto a working FC5 system with the disk configured as above. Actual Results: Installer hangs *after* dependency checking stage Expected Results: Install/upgrade completes successfully Additional info:
I spent most of yesterday trying to isolate this problem. After I started an install, I left VT4 displayed so that I would be able to scroll back. It turns out that there *was* an error reading the DVD, which let to a whole series of squashfs tracebacks. After this happens, any command issued to the shell on VT2 will hang, though it is still possible to switch VTs, and the mouse cursor still tracks on the X display. I've tried two DVD+Rs written on two burners, a Liteon SHW-1635S and an NEC 3540. Both DVD+Rs pass media checks on those burners as well as an older TDK. However, apparently a random-access read (vs. sequential of the media check) consistently fails on a particular block with either DVD+R on the NEC 3540 drive, which is the one I was trying to use for installation. It is always the same block number; it seems like it may be a data-dependent firmware bug in the NEC. Putting the TDK burner into the machine solved the problem. It seems that the real problem is that there is no mechanism for I/O errors of this nature to propogate to the user interface, which will apparently wait forever.
(This is a mass-update to all current FC6 kernel bugs in NEW state) Hello, I'm reviewing this bug list as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug, however this version of Fedora is no longer maintained. Please attempt to reproduce this bug with a current version of Fedora (presently Fedora 8). If the bug no longer exists, please close the bug or I'll do so in a few days if there is no further information lodged. Thanks for using Fedora!
Per the previous comment in this bug, I am closing it as INSUFFICIENT_DATA, since no information has been lodged for over 30 days. Please re-open this bug or file a new one if you can provide the requested data, and thanks for filing the original report!