Bug 474846 - F10: file system check happens at boot before all scsi devices are created
F10: file system check happens at boot before all scsi devices are created
Status: CLOSED DUPLICATE of bug 481470
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
10
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
: 484588 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 11:08 EST by Frank Samuelson
Modified: 2014-03-16 23:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-02 10:14:30 EDT
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 Frank Samuelson 2008-12-05 11:08:21 EST
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 11:39:29 EST
Did this work fine in Fedora 9 and earlier?
Comment 2 Bill Nottingham 2008-12-05 11:40:25 EST
Also, can you try the mkinitrd in updates-testing?b
Comment 3 Frank Samuelson 2008-12-05 12:24:01 EST
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 06:16:13 EST
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 10:53:08 EST
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 10:35:47 EST
*** Bug 484588 has been marked as a duplicate of this bug. ***
Comment 7 Bill Nottingham 2009-04-02 10:14:30 EDT

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

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