As the latest 4.5 kernel (2.6.9-55.0.12.EL) is unstable for me (crashes about once a day) I want to go back to the rock solid kernel that I had before the update (2.6.9-34.0.2.EL). If nothing else then to confirm it's not a kernel problem. Are there any current packages that might not work with this older kernel? As kernels don't get updated but installed the old kernel is still there and I would just need to change the grub.conf. Anything else? As this is a remote machine I would at least need to be able to login via ssh if not everything is ok.
Thanks.
Kai
Kai Schaetzl wrote:
As the latest 4.5 kernel (2.6.9-55.0.12.EL) is unstable for me (crashes about once a day) I want to go back to the rock solid kernel that I had before the update (2.6.9-34.0.2.EL). If nothing else then to confirm it's not a kernel problem. Are there any current packages that might not work with this older kernel? As kernels don't get updated but installed the old kernel is still there and I would just need to change the grub.conf. Anything else? As this is a remote machine I would at least need to be able to login via ssh if not everything is ok.
Hello Kai,
May I ask whether the nature of your crashes involve network code?
I have not been getting crashes but the latest kernel has been losing network connectivity at random times.
The only packages that may possibly not work with older kernels are packages related to the kernel like iptables or kernel modules. You should not have to worry about iptables as it has not been updated since release. I cannot say much else than that since I do not know what is on your box.
Christopher Chan wrote on Wed, 12 Dec 2007 22:28:24 +0800:
Hi Christopher, thanks for your reply!
May I ask whether the nature of your crashes involve network code?
No, it's likely more a filesystem issue. I posted earlier on the tenth in the message "unstable kernel after update to CentOS 4.5" about it.
From 6 kernel dumps 5 were with process dovecot-auth, one with "mv". As
dovecot-auth accesses user's home directories I assume it could be related to the corruption problem (which seems to be fixed, though, after I did a repair of that partition, it seems the earlier boots reflagged the filesystem as clean, but didn't repair it) I describe in that message.
If I go back to the old kernel and the problem persists it's not related to the new kernel but probably indeed a hardware problem.
The only packages that may possibly not work with older kernels are packages related to the kernel like iptables or kernel modules. You should not have to worry about iptables as it has not been updated since release. I cannot say much else than that since I do not know what is on your box.
Hm, kernel modules are coming with the kernel package as well, arent't they? And they are still around (in /lib/modules) unless I uninstall them, right? I didn't install or compile any extra modules. Are there other packages beyond iptables that hold modules? This is a non-X webserver-type machine, not clustered, simple IDE. So, should likely be fine to revert?
Kai
Kai Schaetzl wrote:
Christopher Chan wrote on Wed, 12 Dec 2007 22:28:24 +0800:
Hi Christopher, thanks for your reply!
May I ask whether the nature of your crashes involve network code?
No, it's likely more a filesystem issue. I posted earlier on the tenth in the message "unstable kernel after update to CentOS 4.5" about it.
From 6 kernel dumps 5 were with process dovecot-auth, one with "mv". As
dovecot-auth accesses user's home directories I assume it could be related to the corruption problem (which seems to be fixed, though, after I did a repair of that partition, it seems the earlier boots reflagged the filesystem as clean, but didn't repair it) I describe in that message.
If I go back to the old kernel and the problem persists it's not related to the new kernel but probably indeed a hardware problem.
That would be it won't it?
The only packages that may possibly not work with older kernels are packages related to the kernel like iptables or kernel modules. You should not have to worry about iptables as it has not been updated since release. I cannot say much else than that since I do not know what is on your box.
Hm, kernel modules are coming with the kernel package as well, arent't they? And they are still around (in /lib/modules) unless I uninstall them, right? I didn't install or compile any extra modules. Are there other packages beyond iptables that hold modules? This is a non-X webserver-type machine, not clustered, simple IDE. So, should likely be fine to revert?
I take it then that you do not have any third party modules then. In which case, it will be just fine to reboot with an older kernel. Just change the default entry set in grub.conf.
Christopher Chan wrote on Thu, 13 Dec 2007 07:42:27 +0800:
I take it then that you do not have any third party modules then. In which case, it will be just fine to reboot with an older kernel. Just change the default entry set in grub.conf.
Changed last night and so far am fine. There's one difference to the new kernel. The old kernel cannot load the new microcode. The new microcode.dat seems not to correspond well with the older microcode.ko. It throws an error. As I understand that is not a problem unless the CPU has a bug that manifests in my environment/usage. It's too early to say the crash problem is fixed, but I wonder if it is actually the new microcode that caused the problem.
Kai
on 12/13/2007 4:32 AM Kai Schaetzl spake the following:
Christopher Chan wrote on Thu, 13 Dec 2007 07:42:27 +0800:
I take it then that you do not have any third party modules then. In which case, it will be just fine to reboot with an older kernel. Just change the default entry set in grub.conf.
Changed last night and so far am fine. There's one difference to the new kernel. The old kernel cannot load the new microcode. The new microcode.dat seems not to correspond well with the older microcode.ko. It throws an error. As I understand that is not a problem unless the CPU has a bug that manifests in my environment/usage. It's too early to say the crash problem is fixed, but I wonder if it is actually the new microcode that caused the problem.
Kai
You can temporarily move the new microcode, or just stop the microcode_ctl program from running if you want to test that.
Scott Silva wrote on Thu, 13 Dec 2007 09:29:31 -0800:
You can temporarily move the new microcode, or just stop the microcode_ctl program from running if you want to test that.
I already stopped microcode_ctl via chkconfig, but I have to wait a few days before I go back to the new kernel to be sure the kernel crashes are gone with the current setup and the old kernel. So far it looks promising.
Kai
-
Christopher Chan -
Kai Schaetzl -
Scott Silva