Bug 185302
| Summary: | x86_64 machine won't boot, startup recursively segfaults. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Linda Wang <lwang> |
| Component: | kernel | Assignee: | Jason Baron <jbaron> |
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | knoel |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-11-21 20:21:57 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: | |||
This request is not planned for inclusion in the next update. The decision is based on weighting the priority and number of requests for a component as well as the impact on the Red Hat Enterprise Linux user-base: other components are considered having higher priority and the number of changes we intend to include in update cycles is limited. Product Management has reviewed and declined this request. You may appeal this decision by reopening this request. |
Description of problem: somehow, the version was 'missing' from the broken build. Things get *really* unhappy when uname returns null. Sometimes you see recursive segfaults. Sometimes you see "kernel too old" messages, sometimes, you see nothing at all, just a hang. Reviewing the older 686-smp kernels that had similar problems showed that they too had broken utsname's. Checking the build logs did show that there was indeed some differences in the generation of version.h between the two builds. It also only seemed to happen when the build system is *really* busy. Like say, during a mass-rebuild of every package. Or when it's near a freeze, and everyone wants to get their fixes into the buildsystem asap. Perfect timing for a bug of this nature. So what was the actual cause ? The kernel specfile did a build in the following way.. make -s ARCH=$Arch nonint_oldconfig > /dev/null make -s ARCH=$Arch include/linux/version.h make -s ARCH=$Arch %{?_smp_mflags} %{make_target} make -s ARCH=$Arch %{?_smp_mflags} modules || exit 1 The 2nd line was added at some point to work around some bug or other which subsequently was fixed upstream. (Lesson #2: Document *why* you're adding a workaround). It's totally unnecessary now. A majority of the time, it was harmless. But under the right conditions, it did *totally* the wrong thing, and you ended up with an empty .kernelrelease Version-Release number of selected component (if applicable): 2.6.9-34.EL How reproducible: Boot a i686-smp kernel Steps to Reproduce: 1.build a kernel 2.boot the kernel randomly. 3. Actual results: booting mysteriously panics Expected results: booting not mysteriously panic Additional info: