Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 199793
Summary: | hang at or near nash startup at boot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tom Horsley <horsley1953> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Brian Brock <bbrock> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | jonstanley, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | MassClosed | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-01-20 04:40:55 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
Tom Horsley
2006-07-22 02:51:00 UTC
I noticed that update offered me kernel 2139 today instead of 2157, so I gave it a whirl, and it spews a lot more stuff on my screen, but still hangs after it says "device-mapper initialized". Just prior to that there are messages about it recognizing the sdc and sdd disks, which are the Windows XP RAID disks I'd just as soon it didn't know about. Is there any way to tell the boot code: "No sdc and sdd aren't there - pretend you didn't see them"? I guess 2139 was from an out of date mirror. I tried some more experiments today, and I was back to kernel 2157 again, and finally got it to boot with a few errors printed from some of the init scripts later in the boot, but everything seems to be working. What I did was modify the initrd image init script. The original script that was installed along with the kernel contained these lines that appear to be related to the Windows RAID disks: rmparts sdd rmparts sdc dm create isw_deichhibbi_RAID_Volume1 0 312602112 striped 2 128 8:32 0 8:48 0 dm partadd isw_deichhibbi_RAID_Volume1 Adding some additional echo commands revealed that the hang happens on the partadd command, so I removed just the partadd command, and no more hang. It gets all the way through the boot and everything seems to be working the way I want it to. I had previously tried removing more stuff and always got kernel panics (but that may also have been because I wasn't building the initrd image exactly correctly). Anyway, the minimal change seems to be to remove partadd and ignore any errors that happen later in the boot related to device mapper stuff. I am having a similar problem with FC5, 2.6.17-1.2187_FC5smp but the point of commonality seems to be an ASUS motherboard, the ASUS P4P800S with 2.8GHz P4. If I enable hyperthreading, the machine locks up. The exact point seems to be more-or-less random, but with previous kernels, it was typically after the boot when I've already had X running. With the most recent kernel (above), it locks when switching to runlevel 5. I can try to repeat this, booting only to run level 3 to see if I can actually get there. It is unclear to me whether this is X related or not, but running with hyperthreading disabled definitely gets me running. 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. |