Las actualizaciones incrementales del núcleo se distribuyen como
parches
diff
y patch
para más
referencias.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
.
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.
.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 --
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.