Para probar esta idea de los parches, descargue la penúltima versión disponible de las fuentes del núcleo en el formato que desee (las versiones con extensión .tar.gz y .tar.bz2 son idénticas, pero por usar algoritmos de compresión diferentes ocupan distinto tamaño). Descargue también la versión del parche para subir a la versión inmediatamente posterior, así como las firmas de ambos archivos:
usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2
...
Longitud: 26,042,494 (probablemente)
...
usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.20.bz2
...
Longitud: 4,165,346 (probablemente)
...
usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.19.tar.bz2.sign
...
Longitud: 248 (probablemente)
...
usuario@cliente:/tmp$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/patch-2.4.20.bz2.sign
...
Longitud: 248 (probablemente)
...
Antes de hacer nada debería comprobar la autenticidad de los archivos que acaba de descargar, y para ello vamos a usar el comando gpg (incluido en el paquete GnuPG), del que ya hablamos un poco en este artículo sobre slrn.
usuario@cliente:/tmp$ gpg --verify linux-2.4.19.tar.bz2.sign linux-2.4.19.tar.bz2
gpg: Firma creada el sb 03 ago 2002 02:43:13 CEST usando clave DSA ID 517D0F0E
gpg: Firma correcta de "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>"
gpg: ATENCIN: Esta clave no est certificada por una firma de confianza!
gpg: No hay indicios de que la firma pertenezca al propietario.
Huellas dactilares de la clave primaria: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
usuario@cliente:/tmp$
Si obtiene un resultado como el anterior puede tener la certeza casi absoluta de que el archivo que ha descargado es realmente el archivo original de las fuentes del núcleo para esa versión. Repita la operación para el archivo de parche. Asegúrese de no olvidar esta verificación cada vez que descargue archivos de Internet, al menos cuando disponga de la posibilidad de hacerlo, que desgraciadamente no siempre sucede así.
Lo siguiente será descomprimir las fuentes del núcleo en un directorio sobre el que tenga permiso de escritura. La localización predeterminada, y que recomendamos, es /usr/src, donde crear un directorio para la versión concreta de Linux que vayamos a compilar. En realidad este directorio se creará automáticamente, por cómo están empaquetadas las fuentes del núcleo en el archivo descargado.
cliente:/tmp# cd /usr/src/
dardhal:/usr/src# tar jxvf /tmp/linux-2.4.19.tar.bz2
...
cliente:/usr/src# ls -l
total 8
drwxr-xr-x 14 573 573 4096 2002-08-03 02:39 linux-2.4.19
drwxr-xr-x 7 root root 4096 2002-12-14 22:49 rpm
cliente:/usr/src# chown -Rv usuario.usuario linux-2.4.19/
...
cliente:/usr/src# ln -s linux-2.4.19/ linux
cliente:/usr/src# ls -l
total 8
lrwxrwxrwx 1 root src 21 2003-01-25 20:18 linux -> linux-2.4.19/
drwxr-xr-x 14 usuario usuario 4096 2002-08-03 02:39 linux-2.4.19
Como puede ver es necesario ser root o pertenecera al grupo src para poder descomprimir las fuentes en este directorio. Las alternativas son muchas: instalar las fuentes como root, y luego cambiar los permisos a los de su usuario, meter a su usuario en el grupo src, o incluso usar un directorio sobre donde tenga permiso de escritura. En cualquier caso puede ser necesario ejecutar un comando chown como el mostrado para dejar el propietario y grupo de los archivos con valores consistentes. En enlace simbólico suele ser buena idea, puesto que algunos programas buscan archivos de cabeceras en /usr/src/linux, sobre todo en tiempo de compilación.
Pruebe a entrar en el directorio recién creado, y mire lo que contiene. Como puede verficiar en las primeras líneas del archivo Makefile la versión de las fuentes es la 2.4.19. Si queremos aplicar el parche descargado y actualizar las fuentes a la versión 2.4.20 deberímos ejecutar el siguiente comando:
usuario@cliente:/tmp$ cd /usr/src/linux-2.4.19/
usuario@cliente:/usr/src/linux-2.4.19$ bzcat /tmp/patch-2.4.20.bz2 | patch -s -p1 --dry-run
usuario@cliente:/usr/src/linux-2.4.19$ bzcat /tmp/patch-2.4.20.bz2 | patch -p1
...
usuario@cliente:/usr/src/linux-2.4.19$
Si vuelve a consultar el archivo Makefile verá que ahora la versión es 2.4.20, como era de esperar tras aplicar el parche anterior. El primer comando patch nos sirve para ver si el parche aplicará limpiamente y en su totalidad, y con el segundo lo aplicamos de manera real, no simulada. Un parche que no aplique correctamente al 100% dejará un núcleo que no compilará, o peor aún, que sí lo hará pero que eventualmente fallará. Si alguna vez quiere "desaplicar" un parche, debería ejecutar el mismo comando patch usado para aplicarlo, pero con la opción adicional -R (reverse).
Si quiere añadir soporte de hardware o funcionalidad adicional, actualizar el soporte de alguna característica ya presente en el núcleo, o solucionar algún fallo conocido, ahora es el momento de parchear las fuentes. Por ejemplo, supongamos que desea actualizar la versión de LVM (Logical Volume Manager) presente en el núcleo a la más reciente disponible (1.0.6 a día de hoy). Debemos acudir a la página oficial y descargarnos el archivo con la versión 1.0.6 del programa (lvm_1.0.6.tar.gz).
Usuarios que han visto este tema también han visto...
- C´9mo saber lo que Google realmente piensa de tu web
- Aplicación de e-Commerce en las PYMES
- 10 cosas que (probablemente) no conozcas de PHP
- ¿Es Ajax mejor que Flash?
- Google es Internet
- Versión imprimible de este documento
- Enviar por e-mail este documento
