Bug 185302 - x86_64 machine won't boot, startup recursively segfaults.
Summary: x86_64 machine won't boot, startup recursively segfaults.
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jason Baron
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-13 15:30 UTC by Linda Wang
Modified: 2013-03-06 05:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-21 20:21:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Linda Wang 2006-03-13 15:30:36 UTC
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):

How reproducible:

Boot a i686-smp kernel

Steps to Reproduce:
1.build a kernel
2.boot the kernel randomly.
Actual results:

booting mysteriously panics

Expected results:

booting not mysteriously panic

Additional info:

Comment 2 Daniel Riek 2006-11-21 20:19:03 UTC
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.

Comment 3 RHEL Product and Program Management 2006-11-21 20:21:59 UTC
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.