From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: On booting the newer kernel, fsck.ext3 finds the entry in fstab with 'LABEL=/data', is unable to resolve it and fails. This entry corresponds to a hardware RAID. Previously during the boot, mdadm reports "No arrays found in config file". I suspect that /proc/partitions may be in error since: (1) On booting either old or new kernel, fstab-sync gives the same fstab file and mdadm.conf remains fixed; (2) the /proc/partitions differ. I will attach the /proc/partitions below. Also, I am not sure if this is germane but: The system has a software raid and hardware raid. The old working kernel yielded 4 groups of partitions: sda, sdb, sdc and md. The new failing kernel yields 3 groups of partitions sda, sdb and md. It is not clear to me why. Version-Release number of selected component (if applicable): fails for kernel-2.6.14-1.1637; works for kernel-2.6.14-1.1532 How reproducible: Always Steps to Reproduce: 1. In grub, choose one or the other kernel 2. 3. Actual Results: New kernel fails at the point fsck.ext3 tries to check /data (hardware raid). Old kernel completes whole boot. Expected Results: Both kernels should complete boot. Additional info:
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.