Bug 171356 (FC3_MD)
Summary: | raid setups broken with latest update. | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jørgen Thomsen <joergen> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 3 | CC: | ales, amk, bugzilla, cmarco, dblistsub-redzilla, ihok, jukka.lehtonen, kdebisschop, mgb, misek, mk, moneta.mace, pfrields, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2005-11-04 21:51:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jørgen Thomsen
2005-10-21 00:47:47 UTC
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 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. 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! |