Bug 474846

Summary: F10: file system check happens at boot before all scsi devices are created
Product: [Fedora] Fedora Reporter: Frank Samuelson <rhbugzilla0811.20.cudgel>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: eager, geoff+bugzilla.redhat.com, notting, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-02 14:14:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frank Samuelson 2008-12-05 16:08:21 UTC
Description of problem:
My Fedora 10 computer has two scsi drives that I have placed in the fstab:
LABEL=D1                /data1                  ext3    defaults         1 2
LABEL=D2                /data2                  ext3    defaults        1 2
When I boot my F10 machine, rc.sysinit attempts to check the filesystems before the scsi devices for these drives are created.  This leads to fsck.ext3 failing and dropping me to a repair prompt.  This happens regardless of how I describe the drives in the fstab:
/dev/disk/by-label/D1   /data1                ext3    defaults         1 2
/dev/disk/by-label/D2   /data2                ext3    defaults        1 2

I created a work around by putting a short sleep command into rc.sysinit before the "Checking filesystems" happens.  The computer always boots correctly with this sleep in place.

Version-Release number of selected component (if applicable):
Fedora 10 initscripts

How reproducible:
Happens about half the time with no fix.

Additional info:
The hardware for which devices are not yet created are two Seagate Barracuda 160G ST1181677LCV SCSI hard drives :
Host: scsi4 Channel: 00 Id: 01 Lun: 00
  Vendor: SEAGATE  Model: ST1181677LCV     Rev: 0002
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi4 Channel: 00 Id: 02 Lun: 00
  Vendor: SEAGATE  Model: ST1181677LCV     Rev: 0002
  Type:   Direct-Access                    ANSI  SCSI revision: 03
The drives become /dev/sdb and /dev/sdc
They are connected to a 
00:08.0 SCSI storage controller: Adaptec AHA-2940/2940W / AIC-7871
        Flags: bus master, medium devsel, latency 64, IRQ 16
        I/O ports at e800 [disabled] [size=256]
        Memory at febff000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at febe0000 [disabled] [size=32K]
        Kernel driver in use: aic7xxx
        Kernel modules: aic7xxx

Let me know if you need more info.

Comment 1 Bill Nottingham 2008-12-05 16:39:29 UTC
Did this work fine in Fedora 9 and earlier?

Comment 2 Bill Nottingham 2008-12-05 16:40:25 UTC
Also, can you try the mkinitrd in updates-testing?b

Comment 3 Frank Samuelson 2008-12-05 17:24:01 UTC
The system's previous OS was RHEL 4, which worked fine.

I will try the mkinitrd in updates-testing this weekend.

Comment 4 Frank Samuelson 2008-12-06 11:16:13 UTC
Two questions:

Where is the mkinitrd in updates-testing?  I am looking in http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/10/

Do I just need to install it, or should I create a new image with which to boot?

Comment 5 Geoff Childs 2009-02-07 15:53:08 UTC
I'm experiencing the same problem using a 3ware RAID adapter. It occurs roughly every other boot. This didn't happen at all in Fedora 9.

Packages:
mkinitrd-6.0.71-3.fc10.x86_64
kernel-2.6.27.12-170.2.5.fc10.x86_64

A 'yum install mkinitrd --enablerepo=updates-testing' gives 'Package mkinitrd-6.0.71-3.fc10.x86_64 already installed and latest version'.

Has any progress been made on this issue? Am quite happy to test any updates/changes/suggestions.

Comment 6 Bill Nottingham 2009-02-10 15:35:47 UTC
*** Bug 484588 has been marked as a duplicate of this bug. ***

Comment 7 Bill Nottingham 2009-04-02 14:14:30 UTC

*** This bug has been marked as a duplicate of bug 481470 ***