Hola,<br><br><div class="gmail_quote">2009/6/4 Dario Hernan <span dir="ltr"><<a href="http://slacker.ar">slacker.ar</a>@<a href="http://gmail.com">gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
el problema es que aunque te deje los dos kernel instalados si no<br>
estas frente al server no podes hacer nada si con el nuevo kernel no<br>
levanta el equipo.<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
para la actualizacion del kernel siempre se recomienda estar frente al<br>
servidor para poder solucionar ocacionales problema.</blockquote><div class="h5"><br>
Cierto...bueno, si tienes configurada la "ILO" es posible arrancar la máquina en remoto. <br><br>
> Un problema que puede haber al cambiar la versión de kernel, es el que<br>
> aparece cuando tienes hardware cuyo software no está incorporado al<br>
> "árbol" del kernel. Es decir, los fabricantes del hardware ofrecen los<br>
> drivers en formato fuente para que los compiles, pero no los han<br>
> sometido a revisión del equipo de desarrolladores del kernel y por lo<br>
> tanto éstos no lo han incorporado a la distribución del kernel.<br>
><br>
> Es el caso de algunas placas de red que vienen con un diskette con el<br>
> driver para compilar, o cuyo driver hay que bajar de un sitio del<br>
> fabricante. En estos casos la compilación del módulo solamente sirve<br>
> para la versión y release del kernel que tienes funcionando cuando<br>
> compilas. Al actualizar el kernel, cambia la versión y el módulo<br>
> compilado ya no sirve... y te quedas sin red, o placa gráfica, o lo<br>
> que sea.<br>
><br>
> Para evitar esto hace falta usar hardware certificado, apto para<br>
> servidor, con drivers reconocidos en el árbol del kernel, o bien<br>
> instalar el autoinstalador DKMS que resuelve el problema pero según<br>
> entiendo no se instala por defecto en CentOS, posiblemente porque el<br>
> ambiente de desarrollo también es opcional. Al arrancar con un kernel<br>
> nuevo, o instalar una nueva versión de un módulo, dkms recompila los<br>
> módulos con sus dependencias.<br>
><br>
> Salvo este detalle no he conocido problemas para actualizar, aunque de<br>
> todas maneras prefiero hacerlo en forma manual y no automática, cuando<br>
> estoy cerca y con tiempo para atender potenciales problemas.<br>
><br>
> Los administradores que manejan servidores realmente críticos deberían<br>
> tener dos sistemas, uno en producción y uno de prueba, probar las<br>
> funciones críticas a cada actualización y leer los release notes de<br>
> *todas* las nuevas versiones de cada paquete involucrado, pero creo<br>
> que esto está fuera del alcance del 99% de nosotros. En todo caso<br>
> conviene siempre saber con certeza el estado del servidor (paquetes<br>
> instalados, versiones, parámetros de comportamiento como carga<br>
> promedio, etc) mientras está funcionando OK, para poder detectar<br>
> problemas tempranamente y poder volver al estado seguro cuando los<br>
> haya.<br></div></div><br>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. <br>
<br>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.<br>
<br>Otra historia muy diferente es bajarse las fuentes de <a href="http://kernel.org">kernel.org</a>, 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.<br>
<br>-- <br>Saludos,<br>Oscar Osta Pueyo<br>