Bug 216361 - install/upgrade hangs after dependency stage with crash in squashfs
install/upgrade hangs after dependency stage with crash in squashfs
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
6
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks: 427887
  Show dependency treegraph
 
Reported: 2006-11-19 17:21 EST by Eric Smith
Modified: 2008-02-07 23:24 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-07 23:24:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Smith 2006-11-19 17:21:23 EST
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:
Comment 1 Eric Smith 2006-11-20 15:09:46 EST
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-07 20:47:30 EST
(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!
Comment 3 Jon Stanley 2008-02-07 23:24:57 EST
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.