Logo de AulaDigital

Kernel Como 5

Kernel-Como: Parchear el núcleo Anterior Siguiente Indice

5. Parchear el núcleo

5.1 Aplicación de un parche

Las actualizaciones incrementales del núcleo se distribuyen como parches No tomar con sentido peyorativo el término ``parche'', no se trata de un ``remiendo'', o ``chapuza'', lo que hacemos al ``parchear'' es modificar directamente los fuentes del núcleo, incluyendo las variaciones que se hayan introducido.ver el comando diff y patch para más referencias. Por ejemplo, si tiene la versión 1.1.45 y ve que existe un parche `patch46.gz', con ese fichero podrá actualizarse a la 1.1.46. Debería antes de nada guardar una copia del árbol de directorios de las fuentes del núcleo actual (haciendo `make clean', luego `tar cvfz antiguas-fuentes.tar.gz linux' desde el directorio /usr/src).

Ahora, supongamos que tiene `patch46.gz' en /usr/src. Vaya a ese directorio y escriba

zcat patch46.gz | patch -p0 

(o bien

patch -p0 < patch46 

si ya estaba descomprimido). Verá rápida (o lentamente, depende del ordenador) una serie de mensajes que le dicen que se intentan aplicar los cambios, cuáles tienen éxito y cuáles no. Normalmente, esto irá bien y no habrá que preocuparse de tanto mensaje, aunque con la opción -s solo saldrán los mensajes de error.

Inciso de la revisión 2.1:

No es infrecuente que haya que borrar el árbol de los fuentes entero y reinstalarlos de nuevo; muchas veces, se tiene un .tar.gz con los fuentes más un montón de parches; para evitarse el tener que parchear uno a uno, puede invocar lo siguiente desde la línea de comandos: (asumo que tratamos de parchear p. ej. con parches a partir del 2.0.20 hasta el 2.0.27, usamos bash y estamos en /usr/src, teclee pwd para cerciorarse).

# for i in patch-2.0.2[1234567].gz; do
>zcat $i | patch -p0
>done

Investigue por su cuenta, verá qué potencia hay en la línea de comandos *nix...

fin del inciso

Para ver qué partes no se han modificado correctamente, busque los ficheros .rej en el directorio de las fuentes. Si se usan algunas versiones de patch (antiguas, sobre todo) esos ficheros tendrán extensión `#'. Con el comando find encontrará fácilmente los ficheros:

find . -name '*.rej' -print

imprime todos los ficheros .rej que están en el directorio actual o subdirectorios.

Si todo ha ido bien, haga `make clean', `config' y `dep' como se describió en las secciones compilacion y momento.

Hay algunas opciones más en el comando patch. Con -s, como hemos dicho, se suprimen todos los mensajes salvo los errores. Si guarda las fuentes del núcleo en otro lugar que no sea /usr/src/linux, con patch -p1 se parchearán las cosas limpiamente. Otras opciones de interés se encuentran bien documentadas en las páginas man.

5.2 Si algo va mal

El problema más común es que una ejecución de patch intente modificar el fichero `config.in' y no parezca quedar bien, porque haya hecho cambios en él de acuerdo con su máquina. Este problema sucede con versiones antiguas. Para corregirlo, busque el fichero config.in.rej, y vea qué tiene el parche originado. Los cambios suelen ir marcados con `+' o `-' al principio de las líneas. Edítelo, recordando si las opciones estaban puestas a Y o a N, y ejecute

patch -p0 < config.in.rej 

y si no tiene fallos, puede continuar con el resto del proceso. El fichero config.in.rej permanecerá, aunque puede borrarlo.

Si encuentra otros problemas, puede que haya aplicado un parche fuera de orden. Si el programa patch responde con

previously applied patch detected: Assume -R? 

probablemente estará intentando aplicar un parche anterior a su versión actual. Si responde `y', intentará degradar sus fuentes, y normalmente fallará, obligándole a preparar un nuevo árbol de fuentes.

Para anular el efecto de un parche, use `patch -R' con el parche original.

Lo mejor ante un problema es reinstalar un árbol de fuentes limpio y empezar de nuevo.

5.3 Limpieza de ficheros .orig

Después de algunos parches, los ficheros .orig empezarán a abultar mucho. Por ejemplo, si estamos ya con el núcleo 1.1.51 y empezamos con el 1.1.48, borrar los .orig nos ahorrara medio megabyte. Con

find .-name '*.orig' -exec rm -f {} ';'

se automatizará esa limpieza. En versiones que usen el # en lugar de .rej, sustituya el .orig por un `~'.

Una forma mejor de hacer esto es usar xargs de GNU:

find .-name '*.orig' | xargs rm

o el método ``más seguro pero más pesado'':

find . -name '*.orig' -print0 | xargs --null rm --

5.4 Otros parches

Hay otros parches (los llamaremos ``no estándares'') que si se aplican, probablemente provocarán que los parches de Linus no funcionen correctamente, teniendo que retroceder, corregir las fuentes o el parche, instalar de nuevo las fuentes, o una combinación de lo anterior.

inciso de la R. 2.1: Existe una página con información centralizada sobre este tipo de parches en:

http://www.ecsnet.com/html/linux_21_upatch.html

Este es un buen sitio para buscar si necesita soporte para algún dispositivo esotérico o implementación reciente. Tenga en cuenta, no obstante, que la mayoría serán para el kernel actual de desarrollo, aunque puedan aplicarse algunos ( eiste otra página en la misma localización citada anteriormente) en el kernel de producción.

fin del inciso

Por ejemplo, el autor utilizaba el parche `noblink' que anula el parpadeo del cursor en las consolas virtuales. Este parche se actualiza (o actualizaba) frecuentemente para los nuevos núcleos. Como ahora muchos manejadores se pueden cargar como módulos, los parches ya son menos necesarios.


Anterior Siguiente Indice