Bug 174900
Summary: | fsck.ext3 unable to resolve LABEL; mdadm; /proc/partitions | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <chernoff> | ||||||||||
Component: | kernel | Assignee: | Dave Jones <davej> | ||||||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> | ||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 5 | CC: | jonstanley, pfrields, wtogami | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | x86_64 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | MassClosed | ||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2008-01-20 04:39:40 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: | |||||||||||||
Attachments: |
|
Description
Need Real Name
2005-12-03 18:12:39 UTC
Created attachment 121800 [details]
/proc/partitions: success and failure
/proc/partitions created by successful boot and at point of failure for
failed boot
what type of controller is the hardware raid ? (What module does it use?) The hardware raid is LSI MegaRAID SATA 300-8X The driver is megaraid_mbox See attachment for lsmod and dmesg output Created attachment 121960 [details]
lsmod and dmesg output
Is it possible for you to get the boot messages from the failing system ? Maybe by booting into single user mode ? (Or serial console if you have a cable & 2nd machine) On failing system, after it dumps you into "repair filesystem", I did dmesg | dd of=/dev/fd0 which I attach next Created attachment 122020 [details]
dmesg from failing boot
This problem persists in 2.6.14-1.1644, .1653, .1656 A comparison of the working and failing scripts above shows that there a variety of (minor?) differences in the boot logs but an obvious one shows up immediately after the messages SCSI subsystem initialized megaraid cmm: 2.20.2.6 (Release Date: Mon Mar 7 00:01:03 EST 2005) megaraid: 2.20.4.6 (Release Date: Mon Mar 07 12:27:22 EST 2005) The working boot continues with megaraid: probe new device 0x1000:0x0409:0x1000:0x3008: bus 11:slot 14:func 0 whereas the failing boot does not. This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you. The bug continues in version 1830. megaraid_mbox fails to detect hardware raid on boot Original problem present in all kernels beyond 2.6.13-1.1532: Specifically, in 2.6.14-1.1637, ...1644, ...1653, ...1656 and 2.6.15-1.1830, ...1831, ...1833 and 2.6.16-1.2069 and ...2096 megaraid_mbox fails to detect hardware raid on boot First noted in 2.6.14-1.1637, the bug continues in all subsequent kernel versions in 2.6.14-1.xxxx, 2.6.15-1.xxxx and 2.6.16-1.xxxx including most recently 2.6.16-1.2108, 2111 and 2115 can you paste your /etc/modprobe.conf here ? I think you may need an entry for megaraid_mm as well as megaraid_mbox Created attachment 131758 [details]
modprobe.conf
This conf file works for 2.6.13-1.1532 and fails for later
kernels.
ok, as I guess, you're lacking the other module on which megaraid_mbox is dependant. Try adding this line: alias scsi_hostadapter megaraid_mm to your /etc/modprobe.conf, and then recreate the initrd. (Either remove and reinstall the newest kernel, or run mkinitrd by hand with the various parameters depending on which kernel version you're updating). [This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you. A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you. (this is a mass-close to kernel bugs in NEEDINFO state) As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. If you believe that this bug was closed in error, please feel free to reopen this bug. |