Re: fsck failure at boot

[Tom Sightler <ttsig tuxyturvy com>]

On Fri, 2006-04-21 at 16:03 -0400, Jason Dixon wrote: 
> QLogic Fibre Channel HBA Driver (a0000002002738a8)
> ACPI: PCI interrupt 0000:02:01.0[A]: no GSI
> qla2300 0000:02:01.0: Found an ISP2300, irq 63, iobase  
> 0xc00000080fc00000
> qla2300 0000:02:01.0: Configuring PCI space...
> qla2300 0000:02:01.0: Configure NVRAM parameters...
> qla2300 0000:02:01.0: Verifying loaded RISC code...
> qla2300 0000:02:01.0: Waiting for LIP to complete...
> qla2300 0000:02:01.0: LIP reset occured (f800).
> qla2300 0000:02:01.0: LOOP UP detected (2 Gbps).
> qla2300 0000:02:01.0: Topology - (F_Port), Host Loop address 0xffff
> scsi4 : qla2xxx
> qla2300 0000:02:01.0:
> QLogic Fibre Channel HBA Driver: 8.00.00b21-k
>    QLogic QLA2310 -
>    ISP2300: PCI-X (66 MHz) @ 0000:02:01.0 hdma+, host#=4, fw=3.03.02 IPX
>    Vendor: APPLE     Model: Xserve RAID       Rev: 1.26
>    Type:   Direct-Access                      ANSI SCSI revision: 05
> qla2300 0000:02:01.0: scsi(4:0:0:0): Enabled tagged queuing, queue  
> depth 32.
>    Vendor: APPLE     Model: Xserve RAID       Rev: 1.26
>    Type:   Direct-Access                      ANSI SCSI revision: 05
> qla2300 0000:02:01.0: scsi(4:0:0:1): Enabled tagged queuing, queue  
> depth 32.
> SCSI device sdb: 980451328 512-byte hdwr sectors (501991 MB)
> SCSI device sdb: drive cache: write back
> sdb: sdb1
> Attached scsi disk sdb at scsi4, channel 0, id 0, lun 1

The firmware looks pretty old in your Qlogic adapter, that might be a
possibility, but I doubt it.

We have quite a few RHEL4 systems using Qlogic 2340 adapters to talk to
Xserve RAID systems and haven't seen anything like this at all although
I'll admit that we use the with LVM, not simple partitions.

I just reread your first message and it actually looks like the system
is getting to the "fsck" before udev has a chance to actually make the
device node, did you rebuild your initrd after adding the Qlogic device?
If the device is not getting loaded during the initrd process, but
rather during the "Initializing Hardware..." phase then I could see how
that's possible.

Another possible workaround would be to simply tell the system not to
attempt to fsck that drive by changing your fstab to:

/dev/sdb1 /san ext3     defaults     1 0

Later,
Tom