Red Hat Bugzilla – Bug 171356
raid setups broken with latest update.
Last modified: 2015-01-04 17:22:38 EST
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):
Steps to Reproduce:
1. Boot machine
Actual Results: hanging
Expected Results: normal boot
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
Same here. BAD. May be MD related.
Same here. Two SATA disks, RAID1. Very bad.
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.
I doubt that smartd has anything to do with it for
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.
I'm glad someone was able to quickly rule out smartd.
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.
I see this problem using both UP and SMP kernels on dual-Xeon box. Also running
software RAID1 over SCSI.
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.
I also see the bug in 1380 on a dual Xeon with RAID1 on SCSI.
The test kernel (1381) appears to work okay.
Confirming that the test kernel (1381) corrects the problem for me as well.
IDE MD RAID1, UP kernel, AMD64, ASUS K8V SE Deluxe
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.
*** Bug 171540 has been marked as a duplicate of this bug. ***
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...
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!