Hola,
2009/6/4 Dario Hernan slacker.ar@gmail.com
el problema es que aunque te deje los dos kernel instalados si no estas frente al server no podes hacer nada si con el nuevo kernel no levanta el equipo.
para la actualizacion del kernel siempre se recomienda estar frente al servidor para poder solucionar ocacionales problema.
Cierto...bueno, si tienes configurada la "ILO" es posible arrancar la máquina en remoto.
Un problema que puede haber al cambiar la versión de kernel, es el que aparece cuando tienes hardware cuyo software no está incorporado al "árbol" del kernel. Es decir, los fabricantes del hardware ofrecen los drivers en formato fuente para que los compiles, pero no los han sometido a revisión del equipo de desarrolladores del kernel y por lo tanto éstos no lo han incorporado a la distribución del kernel.
Es el caso de algunas placas de red que vienen con un diskette con el driver para compilar, o cuyo driver hay que bajar de un sitio del fabricante. En estos casos la compilación del módulo solamente sirve para la versión y release del kernel que tienes funcionando cuando compilas. Al actualizar el kernel, cambia la versión y el módulo compilado ya no sirve... y te quedas sin red, o placa gráfica, o lo que sea.
Para evitar esto hace falta usar hardware certificado, apto para servidor, con drivers reconocidos en el árbol del kernel, o bien instalar el autoinstalador DKMS que resuelve el problema pero según entiendo no se instala por defecto en CentOS, posiblemente porque el ambiente de desarrollo también es opcional. Al arrancar con un kernel nuevo, o instalar una nueva versión de un módulo, dkms recompila los módulos con sus dependencias.
Salvo este detalle no he conocido problemas para actualizar, aunque de todas maneras prefiero hacerlo en forma manual y no automática, cuando estoy cerca y con tiempo para atender potenciales problemas.
Los administradores que manejan servidores realmente críticos deberían tener dos sistemas, uno en producción y uno de prueba, probar las funciones críticas a cada actualización y leer los release notes de *todas* las nuevas versiones de cada paquete involucrado, pero creo que esto está fuera del alcance del 99% de nosotros. En todo caso conviene siempre saber con certeza el estado del servidor (paquetes instalados, versiones, parámetros de comportamiento como carga promedio, etc) mientras está funcionando OK, para poder detectar problemas tempranamente y poder volver al estado seguro cuando los haya.
Perdonad mi ignorancia, pero esto que comentas es cuando se cambía de versión de kernel, en CentOS 5.3, hasta el final de vida de su ciclo de mantenimiento debería ser 2.6.18, no va a cambiar de versión.
Otra historia es el cambio de release para los parches aplicados al kernel (las actualizaciones del kernel vía yum o up2date), pero siempre sobre la misma versión, la 2.6.18. Así que si compilamos un módulo con las cabeceras del 2.6.18 (del source del paquete del kernel de los repos de CentOS) debería funcionar para todas las actualizaciones.
Otra historia muy diferente es bajarse las fuentes de kernel.org, compilar y actualizar...entoces si estoy con vosotros. Pero si no te sales de los repos de CentOS y mantienes la versión no se debería tener ningún problema.