Bug 171781 - kernel-2.6.12-1.1380 will not mount stripped scsi drives ( hangs at mount / )
kernel-2.6.12-1.1380 will not mount stripped scsi drives ( hangs at mount / )
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-26 08:13 EDT by Clay Campbell
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-03 15:54:20 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 Clay Campbell 2005-10-26 08:13:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Description of problem:
After updating to kernel 2.6.12-1.1380, my machine would no longer mount my root partition, which is actually 2 stripped SCSI drives in an older PowerEdge 1400SC

Rolling back to the previous kernel booted correctly.

My other poweredge 1500sc are fine with the new kernel, but they don't have stripped drives (/dev/md1) 

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1380

How reproducible:
Always

Steps to Reproduce:
1. Select newest kernel at grub
2. wait for system to hit init 1 and start to mount /
3. hangs at mount /
  

Actual Results:  Nothing, no disks no boot

Expected Results:  rolling back to previous kernel, machine mounts / and boots as expected

Additional info:
Comment 1 Clay Campbell 2005-10-26 13:33:27 EDT
I meant to say 

Actual Results:  no / mounted so no further boot progress and no helpful logs
generated obviously

instead of

Actual Results:  Nothing, no disks no boot

Comment 2 Alex Butcher 2005-10-26 19:29:16 EDT
I think I'm experiencing the same problem. None of my filesystems are on SCSI
discs; they're all LVs within md RAID0 and RAID1 sets on 2 PATA discs hanging
off a Promise PDC20276. Booting with 1380 halts after the message about mounting
the first LV (/home). A few plain ext2/ext3 partitions mount successfully prior
to this. I'm pretty sure the next partition normally mounted is another LV on
the same (RAID1) set as the first LV to be mounted.

My guess is that this is an LVM issue, rather than a RAID0 issue.
Comment 3 Clay Campbell 2005-10-27 13:44:09 EDT
FYI to Alex Butcher, my PowerEdge 2550 with hardware (RAID)LSI Logic MegaRAID
driver mounted using 2.6.12-1.1380_FC3smp no problems.  

I was expecting trouble with it too after the stripped drives in the PE 1400sc
wouldn't mount.  Were you using _FC3smp?  I wasn't on the PE1400sc that had
problems.
Comment 4 Alex Butcher 2005-10-27 15:13:56 EDT
My system is a P4, therefore UP, so I'm using the non-SMP kernel, also.

Clay, are you using LVM on your PE1400sc?
Comment 5 Clay Campbell 2005-10-27 16:07:33 EDT
No LVM here.

Here is a little dmesg info about my PE1400sc 

SCSI subsystem initialized
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled.  Depth 4
(scsi0:A:0): 6.600MB/s transfers (16bit)
(scsi0:A:0): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
SCSI device sda: 35566478 512-byte hdwr sectors (18210 MB)
SCSI device sda: drive cache: write through
SCSI device sda: 35566478 512-byte hdwr sectors (18210 MB)
SCSI device sda: drive cache: write through
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi0:A:1:0: Tagged Queuing enabled.  Depth 4
(scsi0:A:1): 6.600MB/s transfers (16bit)
(scsi0:A:1): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
SCSI device sdb: 35566478 512-byte hdwr sectors (18210 MB)
SCSI device sdb: drive cache: write through
SCSI device sdb: 35566478 512-byte hdwr sectors (18210 MB)
SCSI device sdb: drive cache: write through
Attached scsi disk sdb at scsi0, channel 0, id 1, lun 0
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7899 Ultra160 SCSI adapter>
        aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

Good news that you aren't using smp either, maybe the smp works where the
non-smp fails?

C
Comment 6 Alex Butcher 2005-10-30 14:16:32 EST
The removal of the 'stacked md' patch in kernel-2.6.12-1.1381_FC3 appears to
have fixed this issue for me.
Comment 7 Clay Campbell 2005-11-01 06:30:35 EST
kernel-2.6.12-1.1381_FC3 worked for me too.

dmesg from a working kernel-2.6.12-1.1381_FC3 md

md: raid1 personality registered as nr 3
md: Autodetecting RAID arrays.
md: autorun ...
md: considering sdb7 ...
md:  adding sdb7 ...
md: sdb6 has different UUID to sdb7
md: sdb5 has different UUID to sdb7
md: sdb3 has different UUID to sdb7
md: sdb2 has different UUID to sdb7
md: sdb1 has different UUID to sdb7
md:  adding sda7 ...
md: sda6 has different UUID to sdb7
md: sda5 has different UUID to sdb7
md: sda3 has different UUID to sdb7
md: sda2 has different UUID to sdb7
md: sda1 has different UUID to sdb7
md: created md5
md: bind<sda7>
md: bind<sdb7>
md: running: <sdb7><sda7>
raid1: raid set md5 active with 2 out of 2 mirrors
md: considering sdb6 ...
md:  adding sdb6 ...
md: sdb5 has different UUID to sdb6
md: sdb3 has different UUID to sdb6
md: sdb2 has different UUID to sdb6
md: sdb1 has different UUID to sdb6
md:  adding sda6 ...
md: sda5 has different UUID to sdb6
md: sda3 has different UUID to sdb6
md: sda2 has different UUID to sdb6
md: sda1 has different UUID to sdb6
md: created md4
md: bind<sda6>
md: bind<sdb6>
md: running: <sdb6><sda6>
raid1: raid set md4 active with 2 out of 2 mirrors
md: considering sdb5 ...
md:  adding sdb5 ...
md: sdb3 has different UUID to sdb5
md: sdb2 has different UUID to sdb5
md: sdb1 has different UUID to sdb5
md:  adding sda5 ...
md: sda3 has different UUID to sdb5
md: sda2 has different UUID to sdb5
md: sda1 has different UUID to sdb5
md: created md2
md: bind<sda5>
md: bind<sdb5>
md: running: <sdb5><sda5>
raid1: raid set md2 active with 2 out of 2 mirrors
md: considering sdb3 ...
md:  adding sdb3 ...
md: sdb2 has different UUID to sdb3
md: sdb1 has different UUID to sdb3
md:  adding sda3 ...
md: sda2 has different UUID to sdb3
md: sda1 has different UUID to sdb3
md: created md3
md: bind<sda3>
md: bind<sdb3>
md: running: <sdb3><sda3>
raid1: raid set md3 active with 2 out of 2 mirrors
md: considering sdb2 ...
md:  adding sdb2 ...
md: sdb1 has different UUID to sdb2
md:  adding sda2 ...
md: sda1 has different UUID to sdb2
md: created md1
md: bind<sda2>
md: bind<sdb2>
md: running: <sdb2><sda2>
raid1: raid set md1 active with 2 out of 2 mirrors
md: considering sdb1 ...
md:  adding sdb1 ...
md:  adding sda1 ...
md: created md0
md: bind<sda1>
md: bind<sdb1>
md: running: <sdb1><sda1>
raid1: raid set md0 active with 2 out of 2 mirrors
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

...

md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

Thanks guys!

C
Comment 8 Matthew Miller 2006-07-10 16:25:58 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 9 Doug Ledford 2007-07-03 15:54:20 EDT
The previous comments reflect that this issue was resolved by a kernel update. 
Closing this out.

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