Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 216361 - install/upgrade hangs after dependency stage with crash in squashfs
Summary: install/upgrade hangs after dependency stage with crash in squashfs
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 6
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
Blocks: 427887
TreeView+ depends on / blocked
Reported: 2006-11-19 22:21 UTC by Eric Smith
Modified: 2008-02-08 04:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-02-08 04:24:57 UTC

Attachments (Terms of Use)

Description Eric Smith 2006-11-19 22:21:23 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20061108 Fedora/ Firefox/

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> Call trace:
[left stuff in trace not copied]
<4> DWARF2 unwinder sutck at system_call+0x73/0x83
<4> leftover inexact backtrace:

(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:

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:

Comment 1 Eric Smith 2006-11-20 20:09:46 UTC
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.

Comment 2 Jon Stanley 2008-01-08 01:47:30 UTC
(This is a mass-update to all current FC6 kernel bugs in NEW state)


I'm reviewing this bug list as part of the kernel bug triage project, an attempt
to isolate current bugs in the Fedora kernel.

I am CC'ing myself to this bug, however this version of Fedora is no longer

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!

Comment 3 Jon Stanley 2008-02-08 04:24:57 UTC
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!

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