Lo hice y lo entendí

El blog de Vicente Navarro
09 dic

Compilar el kernel de Linux

La compilación del kernel es un tema sobre el que ya hay muchos tutoriales, pero puesto que alguna vez se ha pedido en los comentarios[1], voy a intentar hacer un resumen sobre cómo lo suelo hacer yo en mis Debian.

¿Por qué podemos querer compilar el kernel? Pues normalmente porque tengamos algún hardware que no esté soportado por el kernel estándar de la distribución (por ejemplo, en este blog, lo hemos usado mucho cuando hablábamos de compilar los drivers gráficos para los chipsets de las VIA EPIA) o porque haya alguna aplicación que necesite crear módulos del kernel para poder trabajar, como por ejemplo el VMWare o el kqemu. En Cómo mantener los acentos y las eñes al montar NTFS, FAT o smbfs y al compartir directorios con Samba también lo usamos para modificar el juego de caracteres a usar por defecto. Hace poco, en Probando la netconsole de Linux, también nos hizo falta recompilarlo, así como en Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel y en Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.

La mayoría de las distribuciones esperan que se compile e instale el kernel con sus herramientas específicas. En el caso de Debian y Ubuntu, normalmente con la herramienta make-kpkg del paquete kernel-package, como podemos leer en:

Y de hecho, las distribuciones ya suelen llevar sus fuentes del kernel preparadas a su medida:

# apt-cache search linux-source
linux-patch-debian-2.6.22 - Debian patches to version 2.6.22 of the Linux kernel
linux-source-2.6.22 - Linux kernel source for version 2.6.22 with Debian patches
linux-tree-2.6.22 - Linux kernel source tree for building Debian kernel images

Sin embargo yo, como buen abuelo cebolleta de Linux, sigo haciéndolo como lo he hecho toda la vida, de una forma totalmente independientemente de la distribución usada.

Lo primero es descargar el kernel deseado de www.kernel.org. Los kernels disponibles en este sitio son denominados vanilla kernels, indicando con este nombre que son puros en el sentido de que son tal cual los desarrolladores del kernel los han liberado. Posteriormente las distribuciones suelen distribuir kernels parcheados para añadir funcionalidades que no existen en el kernel vanilla (por ejemplo, el bootsplash o la hibernación con TuxOnIce) o para añadir soporte a hardware que no está aún soportado. No es raro ver en las listas de distribución de proyectos que incluyen parches del kernel que antes de permitirte abrir un bug te pidan que pruebes con un parche vanilla para descartar que los parches de tu distribución estén causando el comportamiento indeseado.

En el momento de escribir estas líneas, la última versión estable del kernel es la 2.6.23.9 (unos 43MB comprimida en bz2), así que vamos a por ella:

# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.9.tar.bz2
[...]

Vamos a /usr/src/, la descomprimimos allí, hacemos un enlace simbólico para que /usr/src/linux nos lleve a las fuentes de nuestro nuevo kernel y entramos:

# cd /usr/src/
# tar xvfj /root/SW/linux-2.6.23.9.tar.bz2
[...]
# ln -s -n -f linux-2.6.23.9 linux
# cd linux

Estamos ahora ante las fuentes de un kernel totalmente limpito. Ni siquiera tiene una configuración en el fichero .config, que es donde se guardará nuestra configuración. Si en algún momento tras nuestras pruebas queremos volver a exactamente este punto, sólo tenemos que ejecutar un “make mrproper” y las fuentes volverán a estar exactamente igual que ahora a menos que se haya aplicado algún parche.

No debemos dejar de leer el fichero README que nos cuénta cómo compilar el kernel. Además, en el subdirectorio Documentation hay infinidad de ficheros de ayuda que nos pueden aclarar las ideas en multitud de cuestiones relativas a distintos apartados del kernel.

Pues bien, aquí podemos hacer un “make config“, que nos preguntará elemento por elemento si lo queremos incluir o no (o si lo queremos integrado en el kernel o como módulo):

# make config
scripts/kconfig/conf arch/x86_64/Kconfig
*
* Linux Kernel Configuration
*
*
* General setup
*
Prompt for development and/or incomplete code/drivers (EXPERIMENTAL) [Y/n/?]

Pero esto es muy pesado, así que indudablemente, es mucho mejor si lo hacemos con alguno de los interfaces de usuario que tenemos a nuestra disposición. Yo personalmente no me aclaro bien con otro que no sea el del “make menuconfig“, basado en ncurses (necesitamos el paquete libncurses5-dev para que funcione):

make menuconfig

Pero si tenemos las librerías QT también podemos hacer un “make xconfig“:

make xconfig

o un “make gconfig” si tenemos las GTK 2.0:

make gconfig

La primera vez que vayamos a configurar el kernel, se usará como configuración inicial la de nuestro kernel actual, que si es el de la distribución suele ser un buen punto de partida. La configuración de cada kernel se suele guardar junto al fichero principal del kernel en /boot/config-2.6.XX-YYYY si la instalación anterior lo ha copiado ahí, pero los “make (menu|x|g)?config” lo que hacen es leer la configuración guardada en el interior del kernel en funcionamiento a la que nosotros podemos acceder mediante /proc/config.gz. En la ayuda de General setupKernel .config support leemos:

This option enables the complete Linux kernel ".config" file
contents to be saved in the kernel. It provides documentation
of which kernel options are used in a running kernel or in an
on-disk kernel.  This information can be extracted from the kernel
image file with the script scripts/extract-ikconfig and used as
input to rebuild the current kernel or to build another kernel.
It can also be extracted from a running kernel by reading
/proc/config.gz if enabled (below).

Si los scripts de configuración no detectan la configuración del kernel en ejecución, usarán una por defecto, pero siempre podemos copiar la que queramos al fichero /usr/src/linux/.config.

Bueno, en este punto, ya es cosa de cada uno lo que le quiera quitar y poner al kernel. Yo desde luego, tengo la mano muy larga y me lío a quitar absolutamente todo, todo lo que crea que no me va a hacer falta. Prefiero encontrarme con que no puedo hacer algo por falta de una funcionalidad del kernel en concreto y habilitarla y recompilar para así ser consciente de qué estoy habilitando, para qué hace falta, y quién lo usa. La posición cómoda y sencilla es, desde luego, tener tantas cosas habilitadas como sea posible para tener que recompilar las mínimas veces posibles, aunque la primera vez que lo hagamos tardará muchísimo más tiempo. ¿Te interesa más aprender? ¿Te interesa más compilar una vez y olvidarte? ¿Te interesa que tarde poco en compilar? Cada uno que se compile el kernel según sus gustos/necesidades/objetivos.

Lo único que sí que recomendaría es que se le dé un nombre de subversión al kernel para no confundirlo con el estándar de la distribución. Lo podemos hacer en General setupLocal version – append to kernel release:

make menuconfig - local version

Todos mis kernels suelen tener la coletilla -VIC.

Tras configurar el kernel, salimos, guardamos y hacemos un make. En versiones anteriores, hacía falta además hacer un “make modules” para que se compilaran los módulos, pero en versiones recientes del kernel ya se compilan solos al hacer el make.

# make
scripts/kconfig/conf -s arch/x86_64/Kconfig
  CHK     include/linux/version.h
  UPD     include/linux/version.h
  CHK     include/linux/utsrelease.h
  UPD     include/linux/utsrelease.h
  SYMLINK include/asm -> include/asm-x86_64
  CC      arch/x86_64/kernel/asm-offsets.s
  GEN     include/asm-x86_64/asm-offsets.h
[...]
  CC      sound/usb/snd-usb-audio.mod.o
  LD [M]  sound/usb/snd-usb-audio.ko
  CC      sound/usb/snd-usb-lib.mod.o
  LD [M]  sound/usb/snd-usb-lib.ko

Vemos la compilación de los módulos en las líneas señaladas con [M]. Si el kernel no compila bien, es buena idea probar a hacer un “make clean“, que limpia los ficheros objeto existentes y no es tan agresivo como el “make mrproper” que llega a borrar hasta el fichero .config.

Ahora ya tenemos el kernel compilado, así que pasamos a instalarlo con “make install” y “make modules_install“:

# make install
sh /usr/src/linux-2.6.23.9/arch/i386/boot/install.sh 2.6.23.9-VIC arch/x86_64/boot/bzImage System.map "/boot"
In order to use the new kernel image you have just installed, you
will need to reboot the machine.  First, however, you will need to
either make a bootable floppy diskette, re-run LILO, or have GRUB
installed.

Checking for ELILO...No

GRUB is installed. To automatically switch to new kernels, point your
default entry in menu.lst to /boot/vmlinuz-2.6.23.9-VIC
# make modules_install
  INSTALL arch/x86_64/crypto/aes-x86_64.ko
  INSTALL arch/x86_64/crypto/twofish-x86_64.ko
  INSTALL arch/x86_64/kernel/cpufreq/powernow-k8.ko
  INSTALL arch/x86_64/kernel/cpuid.ko
  INSTALL arch/x86_64/kernel/microcode.ko
[...]
  INSTALL sound/usb/snd-usb-audio.ko
  INSTALL sound/usb/snd-usb-lib.ko
if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  2.6.23.9-VIC; fi

El “make modules_install” instalará los módulos en /lib/modules/2.6.23.9-VIC/ borrando cualquier fichero anterior que hubiera en dicho directorio. Es por eso que si teníamos otros módulos además de los estándar del kernel instalados en este directorio (p.e. los del VMWare, kqemu, driver binario de NVidia), tendremos que volver a instalarlos tras el modules_install.

En /boot ahora podemos encontrar el nuevo kernel perfectamente instalado junto con el estándar de la distribución (2.6.22-3-amd64) y cualquier otro que ya tuviéramos (2.6.22.10-VIC):

# ll /boot | egrep -i 'system|config|vmlin|init'
lrwxrwxrwx  1 root root      23 2007-12-09 18:49 System.map -> System.map-2.6.23.9-VIC
-rw-r--r--  1 root root 1070937 2007-11-04 19:57 System.map-2.6.22-3-amd64
-rw-r--r--  1 root root 1131081 2007-11-18 21:00 System.map-2.6.22.10-VIC
-rw-r--r--  1 root root 1121932 2007-12-09 18:49 System.map-2.6.23.9-VIC
lrwxrwxrwx  1 root root      19 2007-12-09 18:49 config -> config-2.6.23.9-VIC
-rw-r--r--  1 root root   73197 2007-11-04 19:57 config-2.6.22-3-amd64
-rw-r--r--  1 root root   44991 2007-11-18 21:00 config-2.6.22.10-VIC
-rw-r--r--  1 root root   44797 2007-12-09 18:49 config-2.6.23.9-VIC
lrwxrwxrwx  1 root root      25 2007-11-30 21:21 initrd.img -> initrd.img-2.6.22-3-amd64
-rw-r--r--  1 root root 5845083 2007-11-30 21:21 initrd.img-2.6.22-3-amd64
-rw-r--r--  1 root root 2723176 2007-11-18 21:48 initrd.img-2.6.22.10-VIC
lrwxrwxrwx  1 root root      24 2007-11-01 08:58 initrd.img.vic -> initrd.img-2.6.22.10-VIC
lrwxrwxrwx  1 root root      20 2007-12-09 18:49 vmlinuz -> vmlinuz-2.6.23.9-VIC
-rw-r--r--  1 root root 1555880 2007-11-04 19:56 vmlinuz-2.6.22-3-amd64
-rw-r--r--  1 root root 2056648 2007-11-18 21:00 vmlinuz-2.6.22.10-VIC
-rw-r--r--  1 root root 2017464 2007-12-09 18:49 vmlinuz-2.6.23.9-VIC
lrwxrwxrwx  1 root root      21 2007-11-01 08:57 vmlinuz.vic -> vmlinuz-2.6.22.10-VIC

Por supuesto, a menos que el kernel ya tenga integrados todos los drivers necesarios para arrancar, necesitaremos crear un initrd, tal y como ya vimos en: Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio:

# mkinitramfs -o /boot/initrd.img-2.6.23.9-VIC 2.6.23.9-VIC

Si ejecutamos ahora un update-grub:

# update-grub
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz
Found kernel: /boot/vmlinuz-2.6.23.9-VIC
Found kernel: /boot/vmlinuz-2.6.22.10-VIC
Found kernel: /boot/vmlinuz-2.6.22-3-amd64
Updating /boot/grub/menu.lst ... done

nuestro nuevo kernel será añadido entre los AUTOMAGIC KERNELS LIST del /boot/grub/menu.lst:

### BEGIN AUTOMAGIC KERNELS LIST
[...]
title           Debian GNU/Linux, kernel 2.6.23.9-VIC
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.23.9-VIC root=/dev/mapper/nvidia_bdehcbaa3 ro
initrd          /boot/initrd.img-2.6.23.9-VIC
savedefault

title           Debian GNU/Linux, kernel 2.6.23.9-VIC (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.23.9-VIC root=/dev/mapper/nvidia_bdehcbaa3 ro single
initrd          /boot/initrd.img-2.6.23.9-VIC
savedefault
[...]
### END DEBIAN AUTOMAGIC KERNELS LIST

Si queremos arrancarlo con unas opciones determinadas, mejor nos hacemos una configuración específica fuera de esta sección para que no sea machacada con los update-grub que se ejecutan cuando el “apt-get dist-upgrade” nos actualiza el kernel estándar. Por supuesto, no hay ningún problema de convivencia de nuestro kernel con el estándar, viniéndonos el estándar de la distribución tremendamente bien para arrancar el sistema cuando el nuestro no nos arranca bien por algún fallo que hayamos cometido al configurarlo.

Yo tengo la costumbre de crear dos enlaces simbólicos con extensión .vic para señalar mi kernel por defecto:

# cd /boot
# ln -s -f initrd.img-2.6.23.9-VIC initrd.img.vic
# ln -s -f vmlinuz-2.6.23.9-VIC vmlinuz.vic
# ll vmlinuz.vic initrd.img.vic
lrwxrwxrwx 1 root root 23 2007-12-09 19:05 /boot/initrd.img.vic -> initrd.img-2.6.23.9-VIC
lrwxrwxrwx 1 root root 20 2007-12-09 19:06 /boot/vmlinuz.vic -> vmlinuz-2.6.23.9-VIC

y así usarlos en el /boot/grub/menu.lst:

title  linux
root   (hd0,2)
kernel /boot/vmlinuz.vic root=/dev/mapper/nvidia_bdehcbaa3 resume=swap:/dev/mapper/nvidia_bdehcbaa5 vga=840
initrd /boot/initrd.img.vic

Tras reiniciar con nuestro nuevo kernel, podemos ver la nueva versión en la primera línea del dmesg:

# dmesg
Linux version 2.6.23.9-VIC (root@ordenador) (gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)) #1 SMP Sun Dec 9 18:45:11 CET 2007

y en la salida del uname:

# uname -a
Linux ordenador 2.6.23.9-VIC #1 SMP Sun Dec 9 18:45:11 CET 2007 x86_64 GNU/Linux

Si necesitamos aplicarle algún parche al kernel, podemos ver cómo lo hicimos en: Solucionando el error “attempt to access beyond end of device” con reglas de udev, hal y/o un parche del kernel o en: Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.

Anexo sobre el VMWare Server 1.0.4 con el kernel 2.6.23

Y finalmente, acabo de comprobar que mientras que los módulos del VMWare Server 1.0.4 compilaban sin problemas con el kernel 2.6.22, con el kernel 2.6.23 no lo hacen dando el siguiente error:

make: Entering directory `/tmp/vmware-config1/vmmon-only'
make -C /lib/modules/2.6.23.9-VIC/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. modules
make[1]: Entering directory `/usr/src/linux-2.6.23.9'
  CC [M]  /tmp/vmware-config1/vmmon-only/linux/driver.o
/tmp/vmware-config1/vmmon-only/linux/driver.c: In function 'LinuxDriver_Ioctl':
/tmp/vmware-config1/vmmon-only/linux/driver.c:1659: error: 'struct mm_struct' has no member named 'dumpable'
make[2]: *** [/tmp/vmware-config1/vmmon-only/linux/driver.o] Error 1
make[1]: *** [_module_/tmp/vmware-config1/vmmon-only] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.23.9'
make: *** [vmmon.ko] Error 2
make: Leaving directory `/tmp/vmware-config1/vmmon-only'
Unable to build the vmmon module.

La solución ya la vimos en Cómo solucionar incompatibilidades entre una versión de VMWare y un kernel más reciente, y pasa por usar el vmware-any-any-releaseXXX de http://platan.vc.cvut.cz/ftp/pub/vmware.

:wq

[1] Mi regalo de cumpleaños, Iván. Este también es bastante friki, ¿no? ;-)

Entradas relacionadas

30 Comentarios a “Compilar el kernel de Linux”

  • raul dice:

    pregunta de novato, hola buenas,
    tengo el kernel 2.6.18-5-486, me bajo un kernel mas reciente entro a la configuracion y cargo el config del kernel antiguo y no cambio nada. lo compilo y lo instalo. con esto que hago ganaria algo o si no marco ninguna de las opciones ni merece la pena instalar un nuevo kernel?

  • Lucas Perez dice:

    Muchas gracias por tus artículos, la comunidad te lo agradece. Eres la estrella de mi lector de feed!! Saludos.

  • RuBiCK dice:

    Vaya ritmo que llevas con los posts!

    La verdad es que no concía el “append to the kernel release” ni el “kernel .config support”

    Gracias dejarnos aprender de contigo ;)

  • @raul En cada nueva versión del kernel hay importantes mejoras. Algunas necesitan ser habilitadas específicamente y otras no. Por ejemplo, el kernel 2.6.24 traerá, entre otras mejoras, un nuevo algoritmo para evitar la fragmentación de la memoria, y eso se habilitaría automáticamente. Otras veces se han corregido problemas de ext3 o has remodelado partes del planificador, por ejemplo, y eso también se corrige sin seleccionar nada nuevo. Por tanto, sí, sólo con recompilar sin seleccionar nuevas funcionalidades se pueden obtener importantes beneficios. No está de más, por otra parte, leerte las nuevas características del kernel para ver si alguna te interesa y en tal caso, habilitarla específicamente si es necesario.

    @Lucas Perez Me alegro de que te gusten. Y decir tanto como la estrella del lector de feeds, me parece un poco exagerado ;-) .

    RuBiCK Se ha notado el puente encerrado en casa, ¿verdad? ;-) ¡Gracias a ti por la visita!

  • Iván dice:

    Muchas gracias Vicente!. La verdad es que sí es un buen regalo de cumpleaños, jeje. Después de habertelo pedido alguna vez en los comentarios ya lo tengo :-P .
    Me guardo tu post como oro en paño para el futuro. A ver si saco un ratito una tarde y actualizo la versión del kernel en mi ubuntu.

    Saludos y gracias, Iván.

  • RuBiCK dice:

    A propósito del comentario de Iván, ya hace tiempo recuerdo haber actualizado la version de kernel de ubuntu (con debian no me pasó :) y me dejaron de funcionar un monton de cosas, incluso habiendo usado el .config de la version que estaba ejecutando.

    ¿Sabeis si hay alguna manera de meterle al kernel vanilla los parches propios de cada distro?

    Iván, pruebalo y nos comentas, eres nuestro conejillo de indias jejeje

  • @Iván ¡De nada! Si es que el que no llora no mama ;-) .

    @RuBiCK No debería de haber tantas cosas que dejen de funcionar… Lo que más se puede notar, quizás, es que el bootsplash no aparezca y que el driver propietario de NVidia o ATI no funcionen porque hay partes de ellos que se tienen que recompilan para el kernel actual. Esto es normal, por otra parte, tras recompilar un kernel deberías de volver a instalar el driver cerrado de tu tarjeta de vídeo, si lo necesitas.

    Repecto a qué parches aplican Debian y Ubuntu, Debian tiene un paquete específico llamado linux-patch-debian-2.6.22 con los parches del kernel, y podemos ver incluso un listado de los parches que contiene.

    Ubuntu, aunque lo solía hacer así, ahora parece que mete los parches ya integrados en el código del kernel, ya que vemos que el paquete linux-source-2.6.22 es:

    Linux kernel source for version 2.6.22 with Ubuntu patches

    Por tanto, si te compilas ese no deberías tener mayores problemas.

  • Bytecoders dice:

    Gracias SuperCoco,
    el otro día hablaba con un amigo del tema, le acabo de pasar tu enlace y me ha dicho que ya tienes otro lector del blog, parece que le ha gustado :)

    Yo esta ya la tengo en los bookmarks, porque me da a mí que le voy a echar mano a menudo. Siempre lo he compilado a la Debian Way con el make-kpkg.

  • @Bytecoders ¡Pues muchas gracias! Y oye, si tú te aclaras bien con el make-kpkg, pues mucho mejor, que en esto como en casi todo, cada maestrillo tiene su librillo ;-)

  • Sagman dice:

    Bueno jeje, al final hicistes el artículo para compilar un kernel :D . Y te ha quedado muy claro y muy bien redactado :D

    Como referencia me viene ni que pintado.

    Gracias :P

  • makakoloko dice:

    te falto la opcion del make para sistemas multi cpu como los dual core.

  • Iván dice:

    Bueno, pues este fin de semana he tenido un rato (tampoco mucho) y lo he intentando en Ubuntu.
    La compilación fue sin problemas, pero ahora no consigo instalar los drivers de nvidia y el sonido no me funciona. Tengo que ver con más detalle de qué puede ser.

    Otra cosa, al hacer:

    mkinitramfs -o /boot/initrd.img-2.6.2……

    Me da un error diciendo que no encuentra /lib/firmware aunque crea el archivo. Según he leído en esa ruta se ponen drivers tipo tarjeta wifi y demás, por lo que creo que en mi caso de igual.

    A ver si saco otro ratito para seguir investigando.

    Saludos, Iván.

  • @makakoloko La opción para SMP se elige en el “make menuconfig“. Nunca he tenido que usar ninguna opción especial de make para compilar para multiprocesador. ¿Serías tan amable de indicarme a qué opción te refieres?

    @Iván Me alegro de que te haya medio funcionado. Respecto a los drivers de NVidia, tienes que bajártelos de la web de NVidia: UNIX drivers portal page. Lo que encontrarás allí es un fichero con extensión .run que al ejecutarlo compila un módulo que contiene el driver binario con una capa para que funcione bien con tu kernel recién compilado. El script lo hace todo, todo él solo.

    Sobre el mkinitramfs, puedes investigar qué pretenden hacer los scripts de /usr/share/initramfs-tools/ y /etc/initramfs-tools/ cuando buscan ficheros en el directorio /lib/firmware.

    Sobre el audio, te sugiero que mires qué módulos de audio se cargan cuando usas el kernel de la distribución con lsmod y luego mira en /lib/modules/tukernel si dichos módulos se han compilado y existen.

  • Iván dice:

    Gracias por la respuesta!.

    Los drivers de nvidia ya los he instalado así alguna vez, lo que pasa es que creía que tenía que instalar el paquete nvidia-glx-new de ubuntu, por eso no me funcionó. Miraré los scripts de mkinitramfs con calma a ver si saco algo en claro. Y finalmente, sobre el sonido, la verdad es que no se me había ocurrido lo del lsmod. En cuanto reinicie lo pruebo

    Muchas gracias, Iván.

  • Iván dice:

    Bueno, parece que ya lo he conseguido :-D

    La instalación de los drivers de nvidia no me ha costado demasidado, simplemente he tenido que desinstalar el paquete nvidia-glx-new y también ejecutar el instalador con la opción –uninstall para que eliminara todo. Luego sh NVIDIA…. y listo.
    El sonido era porque me faltaba el módulo snd_hda_intel. Lo he encontrado en “Device Drivers -> Sound -> Advanced Linux Sound Architecture -> PCI devices -> Intel HD Audio”. Lo he marcado, luego make, make modules_install y con el reinicio todo listo.

    Ahora ya estoy con:
    Linux doraemon.casa 2.6.23.11-ILM #1 SMP Sat Dec 15 10:04:16 CET 2007 i686 GNU/Linux

    El próximo paso será actualizar el kernel de la Debian que es una 2.6.18-4

    Muchas gracias por todo.

    Saludos, Iván.

  • makakoloko dice:

    Si soy muy amable, en un sistema smp se puede agregar el argumento -j a make para que realize mas de un trabajo a la vez, usando asi la capacidad smp del sistema.

  • @Iván Me alegro mucho de que te haya funcionado todo :D

    El driver de NVidia que lleva el paquete de Ubuntu que comentas sólo sirve para el kernel estándar de la distribución, así que por eso ese no vale y hay que “compilar” (aunque lleva mucho código ya precompilado) uno nuevo.

    @makakoloko Muchas gracias por el apunte. Creía que te referías a una opción especial para que el kernel fuera multiprocesador y ya veo que te refieres a que el kernel se compile en varios procesadores a la vez con “make -j“. No conocía dicha opción, así que te agradezco el apunte. He encontrado este hilo: [Bulma] falla el make -j en el que hablan de que si el desarrollador no hace cuidadosamente el Makefile puede dar problemas. De todas formas, si no recuerdo mal, normalmente cuando compilo el kernel veo tareas en los dos procesadores, tendré que fijarme mejor la próxima vez…

  • makakoloko dice:

    pues yo lo he probado y funciona en un c2d me reduce 15 min la compilacion, con el tema del makefile si es verdad pero dudo que los desarrolladores del nucleo esten en sus sistemas smps compilando con un solo procesador funcionando, o la gente de gentoo.

  • Carlos dice:

    Hola, sabes… he seguido tu tutorial, pero despues del

    # make
    # make install
    # make modules_install
    Todos bien y sin problemas

    es cuando hago
    # ll /boot | egrep -i ‘system|config|vmlin|init’

    No me aparece el initrd de mi nuevo kernel compilado, sí el kernel por supuesto pero no el initrd, previamente y antes de hacer el “make menuconfig” he copiado el /boot/config-xxxx como .config a /usr/src/linux (symlink) pero no aparece el initrd.

    Qué estoy haciendo mal….?

    Saludos

  • Carlos dice:

    AH, ya entiendo…
    el initrd se crea con el comando
    # mkinitramfs -o /boot/initrd.img-2.6.23.9-VIC 2.6.23.9-VIC

    Lo hecho según mi kernel, reinicio y no arranca, queda en “preloadking kernel” seguramente algo me debe estar faltando seleccionar en el “make menuconfig”
    pero no deberia salir adelante…? ya que toma la configuracion del .config que he copiado de /boot ….?

  • @Carlos Pues no sabría qué decirte… Si has compilado el kernel con las mismas opciones (.config) que las de tu kernel anterior te debería de funcionar igual. ¿Has verificado que todos los parámetros del menu.lst apuntan a los ficheros correctos?

  • Carlos dice:

    Si si, he verificado por supuesto eso, fíjate que he compilado el kernel 2.6.23 (Sid sources) ya que en Lenny tenemos el 2.6.22 todavia y se compila sin problemas y arranca y todo.
    Lo unico que si me he dado cuenta es que (Xen ya viene integrado en el 2.6.23) desde el “make menuconfig” —>Processor type and features—> si selecciono “386 family” desaparece la opción de Xen en cambio de partir del “Pentium-III/Celeron(Coppermine)/PentiumIII-Xeon” recien aparece nuevamente, y por supuesto selecciono esa opción (Xen es lo que me interesa) pero no compila da un error haciendo referencia a “algo en i386″ por mas que haya seleccionado otra familia de procesador y mi micro sea un Athlon 2000+.
    Igual ese source es de Sid (brrrr escalofríos) y no debe de ser muy estable propiamente dicho.
    Me queda esperar nomas a que entre en lenny esa rama del kernel.
    Pero me quedo tranquilo que con los sources de mi propia version de Debian me funciona compilar (a la debian), pero no se porque no me ha funcionado de el “vanilla” 2.6.23-12, los errores estan pero interpretarlos por el momento supera mis conocimientos.

    Saludos :)

  • alro dice:

    Amigos tengo un trabajo para adionar de una llamada al sistema al kernel de linux y no se
    vomo empezar.
    Favor de ayudar.

    Gracias.

  • Carlos Sencion dice:

    Bueno pasando por ahi en Google como un usuario mas en internet, logre ver tu articulo, y no me puedo ir sin decirle lo bien que esta, existen muchos tutoriales, todos con el mismo fin, pero este esta bien explicado diria lo suficiente para que una persona con poca defensa en Linux haga su compilacion.

  • @Carlos Sencion ¡Gracias! ¡Me alegro de que te haya gustado!

  • MiguelGeo dice:

    Hola Super Coco

    Primeramente saludarte por tus temas muy interesantes. Soy novel en linux asi que hay varias cosas que me son extrañas.

    Tengo una Laptop Dell , inspiron 9400. Dentro de sus controladores esta un puerto firework ieee1394 que en la distribucion de linux, ubuntu 8.10 no lo soporta. Deseo hacer capturas de vídeo pero no puedo hacerlo. No lo reconoce.

    Buscando en internet encontré un comentario que en las los nuevos kernel no se encuentra ese soporte “http://jaimealbertosilva.blogspot.com/2008/02/firewire-debian-linux-2622.html”

    Mi pregunta es como puedo agregar soporte a mi kerner actual sin tener que reemplazarlo por el antiguo que si soporta mi hadware. No se que hacer. Ya que quitar funcionalidades lo expones fácil en el modo gráfico.

    Espero puedas ayudarme. Gracias de antemano.

  • @MiguelGeo Para cambiar opciones del kernel como las que especificas, tienes que seguir el procedimiento detallado en la entrada o cualquier otro que encuentras por Internet. En concreto, las opciones de IEEE1394 las tienes en Device Drivers → IEEE 1394 (FireWire) support.

  • Pedro O. dice:

    Saludos:
    Excelente tu tutorial, ya lo he probado y do funciona impeque.
    Quiero hacerte otra pregunta: He descargado varios kernel desde http://www.kernel.org y los he compilado, instalado y agregado al grub, Si quiero borrar las fuentes y todo lo demas instalado para un kernel determinado, ¿debo borrar, como muestro a continuacion, o debo utilizar otra herramienta para no dejar enlaces rotos?.

    rm -rf /usr/src/linux-2.x.x.x.
    rm -rf /lib/modules/linux-2.x.x.x

    ¿hay necesidad de hacer algo mas, algun archivo de configuracion que modifcar?

    Saludos

  • @Pedro O. Gracias. Para eliminar todos los restos de un kernel que hayamos compilado nosotros, tendrás que borrar esos dos directorios así como los ficheros asociados al kernel que estén en /boot. Los identificarás porque también tendrán la extensión -2.x.x.x.

Tema LHYLE09, creado por Vicente Navarro