Bug 474846 - F10: file system check happens at boot before all scsi devices are created
Summary: F10: file system check happens at boot before all scsi devices are created
Keywords:
Status: CLOSED DUPLICATE of bug 481470
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 10
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 484588 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-12-05 16:08 UTC by Frank Samuelson
Modified: 2014-03-17 03:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-02 14:14:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

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 ***


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