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:
- The Debian GNU/Linux FAQ Chapter 9 – Debian and the kernel
- Debian Reference Chapter 2 2.7 Debian and the kernel
- Debian Reference Chapter 7 – The Linux kernel under Debian
- Ubuntu Documentation Kernel/Compile
- How To Compile A Kernel – Debian Etch
- How To Compile A Kernel – The Ubuntu Way
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):
Pero si tenemos las librerías QT también podemos hacer un “make xconfig
“:
o un “make gconfig
” si tenemos las GTK 2.0:
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 setup → Kernel .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 setup → Local version – append to kernel release:
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?
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?
Muchas gracias por tus artículos, la comunidad te lo agradece. Eres la estrella de mi lector de feed!! Saludos.
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!
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
.
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.
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.
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 librilloBueno jeje, al final hicistes el artículo para compilar un kernel
. Y te ha quedado muy claro y muy bien redactado
Como referencia me viene ni que pintado.
Gracias
@Sagman ¡Gracias!
te falto la opcion del make para sistemas multi cpu como los dual core.
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 demake
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.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.
Bueno, parece que ya lo he conseguido
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.
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
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 elMakefile
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…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.
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
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 delmenu.lst
apuntan a los ficheros correctos?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
Amigos tengo un trabajo para adionar de una llamada al sistema al kernel de linux y no se
vomo empezar.
Favor de ayudar.
Gracias.
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!
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.
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
.