Bug 171356 - (FC3_MD) raid setups broken with latest update.
raid setups broken with latest update.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
: 171540 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-20 20:47 EDT by Jørgen Thomsen
Modified: 2015-01-04 17:22 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-11-04 16:51:15 EST
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 Jørgen Thomsen 2005-10-20 20:47:47 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461; SV1; i-NavFourF)

Description of problem:
2.6.12-1.1378_FC3 is working fine
2.6.12-1.1380_FC3 is hanging af remounting root as read/write

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

How reproducible:
Always

Steps to Reproduce:
1. Boot machine
2.
3.
  

Actual Results:  hanging

Expected Results:  normal boot

Additional info:

ASUS A7N8X-E Deluxe with two SATA disks in SW RAID

Filesystem             Size   Used  Avail Use% Mounted on
/dev/md1                21G   897M    19G   5% /
/dev/md0               207M    39M   158M  20% /boot
/dev/md5               116G    31G    80G  28% /data
/dev/sdb3               11G   477M   9.4G   5% /data1
none                   398M      0   398M   0% /dev/shm
/dev/md4                11G   2.5G   7.4G  25% /home
/dev/sda3               11G    59M   9.8G   1% /tmp
/dev/md2                21G   4.6G    16G  24% /usr
/dev/md3                21G   3.9G    16G  20% /var
/dev/hda1              122G   1.3G   115G   2% /data2
Comment 1 Mike Bird 2005-10-21 00:15:40 EDT
Same here.  BAD.  May be MD related.
Comment 2 Mogens Kjaer 2005-10-21 02:36:03 EDT
Same here. Two SATA disks, RAID1. Very bad.
Comment 3 Karl DeBisschop 2005-10-21 10:24:09 EDT
Same with me. software raid1 of 2 SCSI disks. 

last message is 

Remounting root filesystem in read-write mode: 

(it does not succeed)

In my case, the next message in a normal bootup is smartd starting to monitor
the disks - but I presently can't see of smartd is part of the problem because I
cannot thake those machine down in the middle of a work day.
Comment 4 Mogens Kjaer 2005-10-21 11:21:35 EDT
I doubt that smartd has anything to do with it for
two reasons:

1. I have SATA disks and don't run smartd
2. If the remount of the root filesystem had
succeeded, it would have been dirty after the
reboot with the old kernel.
Comment 5 Karl DeBisschop 2005-10-21 11:37:17 EDT
I'm glad someone was able to quickly rule out smartd.
Comment 6 Mike Bird 2005-10-21 11:45:36 EDT
We're pretty sure MD is the key.  We had four successes on non-MD systems and
four failures on MD systems before we killed the rollout.
Comment 7 Jack Tanner 2005-10-21 15:28:07 EDT
I see this problem using both UP and SMP kernels on dual-Xeon box. Also running
software RAID1 over SCSI.
Comment 8 Dave Jones 2005-10-21 21:26:12 EDT
http://people.redhat.com/davej/kernels/Fedora/FC3 has a test kernel that backs
out the MD changes in the last errata. This should get things working again.
Comment 9 Allen Kistler 2005-10-22 00:44:35 EDT
I also see the bug in 1380 on a dual Xeon with RAID1 on SCSI.
The test kernel (1381) appears to work okay.
Comment 10 Mace Moneta 2005-10-22 12:32:34 EDT
Confirming that the test kernel (1381) corrects the problem for me as well.

IDE MD RAID1, UP kernel, AMD64, ASUS K8V SE Deluxe
Comment 11 Yan-Fa Li 2005-10-23 18:17:35 EDT
also seeing this on a single Athlon XP running in a RAID1 configuration over
U160 SCSI (LSI) on kernel 1380, previous 1378 ran just fine.
Comment 12 Dave Jones 2005-10-25 03:46:13 EDT
*** Bug 171540 has been marked as a duplicate of this bug. ***
Comment 13 Stephen Warren 2005-10-26 22:45:43 EDT
Hmmm. I just got hit by this, and the fix has been available about 5 days. Isn't
it time to roll it out so that "yum update" picks it up, so it doesn't cause
problems for more people? Or, at the very least, remove 1380 from FTP site so
people don't pick it up...

Comment 14 Aleš Kosina 2005-11-02 15:55:09 EST
Should I submit another bug if I have same problems on Fedora Core 4 with kernel 
2.6.13-1.1532_FC4smp. I have upgraded from version 2.6.11-1.1369_FC4smp...

My boot is as follows:
Uncompressing Linux... Ok, booting the kernel.
Rad Hat nash version 4.2.15 starting
EXT3-fs: unable to read superblock
mount: error 22 mounting ext3
ERROR opening /dev/console!!!!: 2
error dum2'ing fd 0 to 0
error dum2'ing fd 0 to 1
error dum2'ing fd 0 to 2
switchroot: mount failed 22
Kernel panic - not syncing: Attented to kill init!


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