[elrepo] Question about kernel-ml

[Joe Henley]

Alan,

Thanks for your help.  And on the week-end, too!!!

>> I used yum to install the most recent version of the ml kernel for EL5.
>>  It installed 2.6.39-4.... (only) and without any problems.
>>
>> When I rebooted and attempted to run it, it panicked.  It gave me
>> several screens-full of messages, but nothing into /var/log/messages.  I
>> tried twice with the same results.
>>
>> Since this is such unusual behavior with stuff from elrepo, I suspect I
>> have missed something very basic.
> 
> Hi Joe,
> 
> This is a suitable location to discuss your kernel-ml issue.
> 
> I'm sorry to read of the panic'ing problem. To be absolutely clear,
> was it a true panic (which ended with a line with the word "panic"
> therein) or was it an oops? If the latter, then a sequence of oops,
> one after the other would account for several screens worth of text
> and could account for the kernel being so fatally injured that a panic
> was never even possible.

Yes, you are correct.  I double checked (tried again to boot into 
kernel-ml) and it was a series of "oops".

> That being said, there could be something "odd" with your hardware
> configuration. However, I am more inclined to suspect that for you,
> the kernel-ml-2.6.39-4.1.el5.elrepo package is "A Kernel Too Far". [1]
>  If my supposition is true, I would be interested to know how the
> other kernel-ml package that we have available for EL5 systems
> behaves. Perhaps you are unaware that there are two package sets in
> the EL5 repository? Obviously without any help or guidance, yum will
> pick the newer version . . .
> 
> The two package sets available are:
> 
> kernel-ml-2.6.35-14.1.el5.elrepo
> kernel-ml-2.6.39-4.1.el5.elrepo

Yes, you are correct again.  I removed the 2.6.39 version and then 
installed the 2.6.35 version and it does seem to working fine.

> [1] http://blog.toracat.org/2011/03/a-kernel-too-far/
> 
> A few tips when testing a totally new and different kernel -- Always
> perform the first boot into single-user mode, with "rhgb" disabled. If
> a "#" prompt is obtained, check that the kernel is still viable by a
> "date; sleep 5; date". Quickly grab copies of the logs to the /root/
> directory and remember to "sync" straight after the copy has
> completed.

Thanks for all your help.

Joe