my heart skips many beats recalling the number of systems that have failed during a simple physical<br> relocation. Even let them cool down for several hours before moving them 30 feet on a cart with soft tires and padding and drives gently removed and shock and static protected separately. failed reoots, mobo's die, hard drives fail to ever spin back up, power supplies drop a rail, ram never works again, etc.<br>
<br>I've tried for years to get "the people who make decisions" to do the simple following process:<br><br>when time for an upgrade to a server OS (major version change like RHEL4->RHEL5)<br>1. Buy new server and do fresh new OS install<br>
2. migrate old data to new system and begin testing.<br>3. Once testing is complete and new system taking the load, wipe the old drives and sell the old system.<br>4. stop storing junk<br><br><br><div class="gmail_quote">
On Wed, Nov 30, 2011 at 2:46 PM, Rich Faulkner <span dir="ltr"><<a href="mailto:rfaulkner@34thprs.org">rfaulkner@34thprs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<u></u>
<div>
Disk controller in this case is an Adaptec 3805 running RAID 5EE.<br>
<br>
My thoughts were same lines: old OS, time for upgrade and possible h/w failure impending or in progress...<br>
<br>
Thanks for the input all! RinL<div><div class="h5"><br>
<br>
<br>
On Wed, 2011-11-30 at 13:44 -0500, Michael B. Trausch wrote:
</div></div><blockquote type="CITE">
<pre>On 11/30/2011 01:25 PM, Lightner, Jeff wrote:
> A couple of things:
>
> 1) You're not using RH 3.4.6-2 - the message tell you your kernel
> was copiled by that version of gcc. To see the version of RH you're
> running do "cat /etc/issue" and/or "cat /etc/redhat-release".
Indeed. 2.6.9 was used for RHEL4 from the looks of it, so it's likely
that he's using that (which is ending support soon anyway).
> 2) The way RedHat does things is it releases a base package from
> upstream then appends it own versioning to that so 2.6.9-42.ELsmp is
> NOT the same as 2.6.9 on any other system as it may have backported
> bug and security fixes in it. (That being said kernel is handled
> differently than many other packages so you can actually get kernel
> updates from the RedHat yum repositories that might be newer than
> 2.6.9x.
This is generally true regardless of the distribution; most
distributions patch the kernel in some way. One reason that I prefer
using upstream, vanilla kernels is that it's easier to get support for
them than for distro-kernels (at least, IME, YMMV).
> You should NOT attempt to download and compile a newer
> kernel manually as it would no longer be RHEL supported at that
> point.
Only while the locally-compiled kernel is actually running. If you have
a problem with the kernel, the first thing to do is to determine if it
is present in the vanilla kernel; if so, file the bug there and file a
bug with the distribution to reference the upstream bug. Otherwise, if
you cannot reproduce, you have viable information that you can give to
the distributor to say "this problem exists in your kernel version x.y.z
pl eleventyone-foo but not upstream release x.y.z" and that is at least
something to go on.
> If you're using RHEL and paying a subscription fee you can call them
> for support. If you're NOT paying for a subscription fee and using
> them for support you might want to consider moving to CentOS which is
> a binary compile of RHEL sources. It doesn't require subscription
> fees but also doesn't have a support number. (Of course you
> wouldn't want to worry about this until you've solved your base
> issue.)
This would be the one case where it's likely easier to get support for
the distro kernel, though I'd still be inclined to troubleshoot as far
as I can before I start asking for support from the distributor, in the
interest of reducing the amount of back-and-forth communication I have
to do. What can I say... I'm lazy!
> My thought is as Mike said that it is likely an issue with the disk
> controller or disks themselves.
Possibly, though even so, the kernel shouldn't be attempting to deref a
NULL pointer unless the kernel image itself is somehow corrupted or
modified. The thing is that in that case, it'd be very likely that the
kernel wouldn't work at all (and in what I'd call a safe/secure system,
it shouldn't because it should be somehow meaningfully signed, but
that's neither here nor there).
If the kernel's not corrupt and there is indeed a problem with the disk
controller or the disk itself, it shouldn't be able to cause the kernel
to crash by deref'ing a NULL pointer; the kernel should be able to catch
such an issue and freeze the FS to save it from any further problems. A
panic would be warranted, IMHO, but with hopefully a more meaningful
message.
--- Mike
_______________________________________________
Ale mailing list
<div class="im"><a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a>
</div></pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" target="_blank">http://mail.ale.org/mailman/listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" target="_blank">http://mail.ale.org/mailman/listinfo</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>-- <br>James P. Kinney III<br><br>As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as
they please, and those who survive will be left to contemplate the
outcome.<br>- <i><i><i><i>2011 Noam Chomsky<br><br><a href="http://heretothereideas.blogspot.com/" target="_blank">http://heretothereideas.blogspot.com/</a><br></i></i></i></i><br>