Las actualizaciones incrementales del núcleo se distribuyen como
parches. 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
errores. Para ver qué partes no se han cambiado correctamente,
busque los ficheros .rej en el directorio de las fuentes. 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 3 y 4.
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 los manuales en línea.
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 que tiene el parche originao. 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.rejy 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 instalado un patch
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' en el
parche original.
Lo mejor ante un problema es reinstalar un árbol de fuentes limpio y empezar de nuevo.
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 args de GNU:
find . -name '*.orig' | xargs rmo 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.
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.