Phenobarbital con Soda

El miércoles y jueves he tenido el grato placer de participar en el I encuentro Nacional de Emprendedores del Software Libre; realizado por el CNTI y RINDE; en colaboración con FUNDACITE Lara, la UNEXPO y que tuvo como sede la Torre David de la ciudad de Barquisimeto.

Contamos con la presencia de Octavio Rossell y Eduardo D’Atellis que en conjunto presentaron una ponencia sobre Glove; Hector Colina presentandonos una amena presentación sobre servidores web en debian y Hector Rivero de CNTI una sobre RINDE (como una costumbre mia; le volví a recordar; ¿Cuando volverán a levantar FINDE? ).

En mi caso, asistí para dar una ponencia sobre Bases de datos Libres (hablé y dí ejercicios sobre postgresql y mysql; pero hablamos de firebird, berkeley db, ingres y otras); la cual estrené en ese evento y tuvo una buena aceptación; espero mejorar el material y los ejemplos con el tiempo.

Me parece un interesante modelo que aplicaré de ahora en adelante en todas mis ponencias:

Historia (como buena doña, no faltan anecdotas) -> teoría básica -> explicación extendida -> ejemplos básicos -> cierre y conclusiones -> ejemplos complejos (si queda tiempo y personas despiertas ).

proximanente me crearé un repositorio para todas mis ponencias; espero tenerlo pronto.

Gracias a CNTI, a Ezequiel (chekex), la gente de FUNDACITE Lara y todos los demás que hicieron posible este gran evento, como siempre la gente de Lara muy organizada y dispuesta!; felicidades a todos ….

PD: y Galeno, por favor!, pareces naufrago!; donde depositamos la colecta para que vayas al barbero??…

Siempre la gente en todos los foros, conferencias, fuentes de soda tomando café y durante los rezos de la iglesia se detienen para preguntarme; ¿Cuales reglas usas tu para compilar tu kernel?; aqui expongo algunas; no están todas; pero están las más útiles para tu desktop (las reglas para servidores vendrán despues).

Principios Iniciales: del GRUB al mkinitramfs

Levantar un kernel no siempre es “de fabrica”; muchas veces tenemos algunos dispositivos (como discos S-ATA) de los cuales no arrancan a la primera; o tarjetas de video que no levantan en framebuffer; aqui expongo las reglas con las cuales levanto mi actual kernel (2.6.23.1):

/vmlinuz-2.6.23.1 root=/dev/sda2 ro idebus=66 pci=routeirq pci=assign-busses irqpoll acpi=force vga=791

expliquemos algunas; idebus=66 sirve para establecer la velocidad del bus IDE; por defecto (y a manera de compatibilidad) en casi toda distribución de linux es de 33mhz (algo no muy rápido si tenemos de esos nuevos discos UDMA5 ó 6); idebus=66 sirve para reescribir ese valor.

irqpoll: Para algún hardware “extraño” (en mi caso, el fingerprint reader y el lector 7-1 de SD/MMC/CFC) el CPU crea algunos “polls” de acceso para detener su ejecución y preguntarle al hardware; “mira, necesitas hacer algo?”; esto para manejar alternativamente la inicialización correcta de algunos dispositivos “buggy” con las convenciones de la BIOS; en este caso, irqpoll puede hacer a tu arranque mas “lento” de lo normal; pero es la única forma de hacer funcionar correctamente este hardware; si no posees tal hardware que no funciona o no deseas hacerlo funcionar, quitar irqpoll puede mejorar en el performance general del arranque.

vga=791: representa correr framebuffer a 1024×768; algo util cuando corres sin el “quiet” y deseas ver lo que pasa en el arranque del kernel.

pci=assign-busses: excesivamente útil; muchas BIOS “buggy” asignan los irq como les viene en gana; causando que algún hardware se bloquee; con pci=assign-busses, logramos que el kernel sobre-escriba cualquier directiva de asignación de la BIOS y sea este (el kernel) quien asigne los buses de comunicación (PCI bus numbers).

pci=routeirq: en algunas ocasiones; cuando un dispositivo no levanta al arranque del kernel o causa que el kernel se “cuelgue” al levantar; muchos optan por no iniciar las ACPI (con las nefastas consecuencias de no tener gestión de energia, CPU frequency, disk y RAM suspend, modos de energía S3 y todas esas cosas que dependen de ACPI); sin saber que podemos hacer un “by-pass” de los dispositivos PCI buggy creando tablas de “routing” y haciendo que muchos dispositivos PCI funcionen con el “old-behavior” del kernel Linux; es a veces inocuo; pero util para algunas cosas (como los Yenta-Sockets PCMCIA).

Se supone que el algún futuro “no lejano” los drivers para linux serán compatibles con la directiva pci_enable_device y que por tanto, no se necesitará routeirq; pero aun hay afuera mucho de ese hardware.

Opciones que no tengo pero tambien son útiles:
pci=usepirqmask: se usa para que el kernel guarde las irq masks en una tabla (conocida como tabla PIR); se supone que en ciertas BIOS “buggy” (como las HP Pavilion) es útil para que el kernel administre dichas IRQ.

libata.atapi_enabled=1: si acaso tenemos un dispositivo S-ATA ATAPI (algunas unidades de DVD) y no son detectadas por el kernel Linux (o instaladores) pasamos esta directiva para que libata sea cargada al arranque del kernel y con esta que intente habilitar cualquier dispositivo SATA ATAPI.

Descargando y compilando el kernel 2.6.23

¿por qué cambiar de kernel?; bueno, ¿Por qué no?, es por lo general inocuo y muchas características de nuevos kernel pueden beneficiarnos a nosotros (como la incorporación del hipervisor de XEN) o a nuestro hardware (como la estabilización del driver bcm43xx de broadcom que ha hecho innecesario que alguna vez vuelva a mirar a ndiswrapper).

Esta guia no pretende ser “orientada a distro”; es decir, la compilación es generica y sin orientarse a distribución alguna (ej. fedora y debian tienen sus formas “oficialmente aceptadas” de compilar kernel, no es menester de esta guia responder dichas preguntas; hay muchos foros sobre compilar kernel “debian-way”, etc).

Principios iniciales:

Debemos tener incialmente instalado todo lo necesario para compilar; esto es por ejemplo:

Fedora: yum install gcc glib-devel bison

Debian: aptitude install fakeroot build-essential gcc glib-dev

Primer paso: descargar a /usr/src

apuntamos nuestro navegador a http://www.kernel.org y descargamos es más novel del kernel (en mi caso fue el 2..6.23.1, aunque ya va por la 2.6.23.8) de hecho, revisando los changelog, no veo ninguna novedad que ayude a mi hardware (excepto unas correcciones en la libata) asi que esperaré a una variante más estable.

luego que está en /usr/src descomprimimos dicho kernel:

tar xvf linux.2.6.23.1.tar.bz2

con lo cual, procederemos al siguiente paso.

Segundo paso: limpiar el kernel para iniciar

Limpiar el kernel significa dejarlo como nuevo como si nunca hubiera sido compilado; sabemos que acaban de descargarlo, pero por cada vez que quieran hacer cambios y compilarlo nuevamente es bueno ejecutar este comando:

make mrproper

ahora bien, si ya lo tienen compilado y solo desean “darle unas afinadas”, no necesitan ejecutar este comando, pues borrará incluso las directivas previamente configuradas y el archivo .config (residente de todo lo configurado en el kernel).

Tercer paso: revisar si el viejo kernel posee directivas de configuración

Para ello, basta con apuntar a /boot y revisar si nuestro kernel actualmente instalado posee un archivo .config (ej. /boot/config-2.6.18-4-686); si es así, podemos ejecutar:

make oldconfig

y todas las directivas pre-seteadas en el anterior kernel serán “copiadas” a este nuevo kernel; tomen cuenta, que si hay marcada diferencia entre los kernels, este puede preguntar sobre que valor ponerle a nuevas directivas; pueden darle ENTER sin problemas, ya que por defecto, vienen con un valor efectivamente “inocuo” para nuestra configuración actual.

Tomen en cuenta además, que si el archivo config no se encuentra en BOOT, van a necesitar instalar los kernel devel de su respectivo kernel:

fedora: yum install kernel-devel-2.6.20-1-fc7 (ejemplo)

debian: aptitude install linux-headers-2.6-686 (ejemplo)

Ya que tenemos un kernel “seteado” con las viejas opciones (es bueno leer estas nuevas opciones, algunas tal vez nos interesen) podemos entonces proceder a modificar y configurar nuestro kernel.

Modos: El bueno, el malo y el feo

Hay 3 modos de configurar el kernel, make config que simplemente nos va mostrando una a una las opciones en nuestra pantalla; lo cual es harto horrible y tedioso (además de malo); el modo “experto” o para hombres (como dice mi amigo hector colina) es hacer un

make menuconfig

Que presenta una pantalla ncurses digna de una instalación de debian; para poder usar esta pantalla de ncurses necesitamos los ncurses-devel instalados:

fedora: yum install ncurses-devel

debian: aptitude install ncurses5-dev libncurses-dev

la tercera forma es usando las respectivas formas X (gtk, X o Qt) dependiendo de nuestra distribución y nuestro entorno favorito; dichas ventanitas gráficas se obtienen con:

make gconfig

make xconfig

make kconfig

pero necesitamos los bindings de ej. si su caso es GTK, de gtk2++, glibc devel y otras cosillas que el mismo comando pedirá si acaso no las tienen instaladas.

Definiendo opciones

Cada día el kernel se hace más y más complejo, llevarle el conocimiento a todas las opciones es dificil; voy a tratar de ser conciso en las realmente “importantes”:
â?? -> Enable the block layer (BLOCK [=y])
â?? -> IO Schedulers
â?? -> Default I/O scheduler (<choice> [=y])

Activemos el I/O Scheduler y definamos como por defecto el kernel distribuye su ancho de banda entre los procesos de sistema; en mi caso, trabajo mucho con bases de datos, por lo que DEADLINE es mi opción, pero para los desktops más comunes; un scheduler CFQ es la mejor opción, que distribuye equitativamente los tiempos de tarea entre todos los procesos de sistema; equilibrando el uso (como debería ocurrir en un desktop normal).

â?? -> Processor type and features

Symmetric multi-processing support: Al activar esta opción, nuestro kernel será capaz de manejar multiples procesadores (o manejar multiples cores como si fueran procesadores individuales); en el caso de usuarios con Intel Core Duo, Core 2 Duo o AMD X2; activar esta opción permitirá tener multiples procesadores independientes a nuestra disposición (pueden notarlo al arranque, verán tantos pingüinos tux como cores o cpu’s tenga el computador).

Paravirtualization support: para aquellos que deseen correr multiples instancias de un kernel bajo las directivas de un hypervisor (ej. virtualizar con Xen) entonces podemos activar esta opción; ojo!, hay que acotar que si NO VAMOS a virtualizar el equipo; un kernel compilado con el soporte a paravirtualización y con el hypervisor de xen activado, es más lento.

Enable support for Xen hypervisor: como complemento a la anterior opción; podemos incluir directamente el hypervisor de XEN en nuestro boot aceptando esta opción; para los Fans de VMWARE; el hypervisor del ESX Server está en el actual kernel (pero claro, una versión GPL-mode reducida).

Processor Family: Lo que todos buscan!; Fedora se instala en modo 686 y el kernel linux de debian por defecto viene en versiones 486 y 686; como aprovechar entonces mi CPU si siempre va a estar a 800Mhz?; que desperdicio!; pues no, podemos modificar las directivas de cual CPU poseemos en esta lista; realmente la lista es autoexplicada (tengo que explicar que es un pentium-3?); sin embargo, en casos como los Xeon, veremos Xeon y newer Xeon, para los Xeon básicos (los viejitos, familias 4 y 5) se usa Xeon, para los familia 6 y 7 se usa Core 2/newer Xeon; en caso de tener un AMD K8, 64 o X2, activarán Opteron/Athlon64/Hammer/K8.

SMT (Hyperthreading) scheduler support: Si acaso poseen un Intel con hiperhilado (ese invento de meter buses de millones de hilos alrededor del CPU); pueden hacer que el kernel maneje eficientemente el hyperthreading activando esta opción (creo que aun ni Windows Vista maneja correctamente el hyperthreading; colapsando igualmente si se acaban los hilos del CPU).

Multi-core scheduler support: Sea que tengan un Intel Core o un AMD X2; activar esta opción permite al kernel linux manejar correctamente los multi-core CPU’s.

Preemption Model: La panacea del mejoramiento del kernel; por lo general (y por aquello de su necesidad de ser “genericos”) los kernels de la gran mayoría de las distribuciones viene con un modelo pre-emptivo (nivel de latencia del kernel) alto o nulo; esto es ideal para servidores, que requieren dedicar toda la potencia bruta del kernel a procesamientos únicos, computo científico o eso; pero como mi portatil no va a guiar cohetes a plutón; entonces en mi caso; cambio el modelo preemptivo del kernel a:

Preemptible Kernel (Low-Latency Desktop)

Con lo cual todo el kernel se vuelve preemptible; mejorando las latencias a factores de milisegundos; haciendo que las aplicaciones funcionen “suavemente” aun en condiciones de alta carga; claro, esto conlleva a un consumo realmente “excesivo” del CPU; pero para equipos con 2.0Ghz de CPU en dos nucleos; es algo que solo les causa cosquillas.

Timer frequency: En algunos casos, un kernel no preemptible (de alta latencia) no necesita tener una alta velocidad de respuesta ante eventos; por lo que la frecuencia de reloj del kernel es baja (por defecto, 300Mhz); en caso que requiramos una alta velocidad de respuesta (requerida para casi todo lo “divertido” hoy en día como juegos, edición de video, reproducción de DVD’s, etc) entonces pueden ubicar como “frecuencia de reloj” correcta a 1000Mhz.

â?? -> Power management options (ACPI, APM)

Cambiamos de opción; en este caso, la que maneja la gestión de energía y ACPI.

Suspend to RAM and standby: Si la BIOS soporta el estado ACPI S3 (lo verán al entrar en su BIOS y verificar si pueden activar el modo S3 en la sección de energía y ACPI); al activar esta opción, su máquina podrá suavemente suspenderse en RAM y colocarse en modo “stand-by”; este modo es utilísimo; ya que copia en RAM el estado de tu sesión y además solo gasta energía para mantener la RAM (volatil por lo general) alimentada para que no pierda los datos (y ej. el bombillo de power parpadeando en mi portatil); en casos muy normales; mi portatil ha mantenido (despues de uso) hasta 2 días de pila en modo suspensión.

Hibernation (aka ’suspend to disk’): Si además de suspensión en RAM (STR); deseamos suspender a disco (STD o Hibernate); debemos activar esta opción; adicionalmente debemos especificar cual es la ruta a nuestra SWAP (si, swap, debemos tener swap activa ya que es AHI donde se suspende a disco el equipo):

y escribir el valor de la swap partition: Default resume partition: /dev/sda7 (mi caso)

Para descubrir cual es su swap (ACTIVA) deben ejecutar (como root):

swapon -s

a lo que obtendrán:

Filename Type Size Used Priority
/dev/sda7 partition 975168 928 -1

Si ACASO no tuvieran SWAP activa; pueden crearla (no es menester de la guia decirles como ) y activarla con:

swapon /dev/sda7

la partición debe SIEMPRE estar activa antes de mandar a hibernar; sino realmente no podrán enviar el equipo a hibernación.

Si acaso el equipo se fuera a hibernación y desean arrancar sin que el sistema cargue la hibernación; pueden arrancar con el parámetro “noresume” en el GRUB; noten sin embargo, que la partición aparecerá “corrupta” para el fsck que se ejecuta al arranque del kernel, por lo que es recomendable ejecutar mkswap a la partición y reactivarla con swapon.

Es evidente; además, que la dimensión de nuestra swap debe ser MAYOR que nuestra RAM (he medido factores de 30%, pero por algo por ahí dicen “swap=2 * RAM”).

Nota crítica (y que conste que se los advertí): Ningún filesystem con journalist debe quedar PRIMERO en el montaje que la swap al momento de “despertar de la hibernación” o este filesystem quedará corrompido extrañanamente (mi /usr/local que era JFS quedó convertido a ext2 con la data corrompida).

â?? -> Power management options (ACPI, APM)
â?? -> CPU Frequency scaling

Siempre me preguntan; como hago para gestionar la velocidad del CPU?; bueno, activan esta opción y definen los “gobernadores” que desean activar; estos son “performance” (por defecto), “ondemand”, “conservative” y “powersave”; creo que los nombres son bastante explicativos; lo interesante aqui es definir cual es el módulo del kernel que gestiona la gestión de velocidad del CPU (a saber, en AMD es la tecnología PowerNow! y en Intel se llama SpeedStep); ej. en caso de tener un CPU AMD optan por:

AMD Opteron/Athlon64 PowerNow!

En caso de ser un Intel Core; pueden usar el genérico ACPI Processor P-States driver o usar:

Intel Enhanced SpeedStep

Si los colocan como m (module); deben tener en cuenta de cargarlos al arranque (agregandolos en /etc/modules en debian o en /etc/modprobe.conf en fedora).

Ej.

modprobe acpi-cpufreq cpufreq-ondemand cpufreq-conservative


activará el CPU frequency de nuestro kernel.

Para cambiarle la frecuencia del CPU pueden ejecutar:

cpufreq-set -c [numero de CPU, empezando en cero] -g [nombre del gobernador]


Si deseamos dejar un gobernador por defecto (ej. ondemand) entonces ejecutamos (claro que como ROOT!):

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Claro, gnome viene con una aplicación (applet) llamado gnome-cpufreq-applet que permite la visualización del estado actual de la frecuencia y el gobernador; puede que no puedan modificar las escalas y los gobernadores; esto es porque la aplicación necesita tener un suid como superusuario (ya que accede a comandos que solo el superusuario podría acceder); en fedora esto no es necesario ya que el applet ya viene con su respectivo bit de suid; pero en el caso de debian toca ejecutar:


dpkg-reconfigure gnome-applets


Y responder “yes” a “Instalar CPUFREQ con SUID root”.
â?? -> Kernel hacking

En kernel hacking; por favor deben desactivar cualquier opción que implique “debug” como:

kernel debug

debug filesystem

Enable unused/obsolete exported symbols

Run “make headers/check”

SLUB debugging on by default

Ya que por defecto, si nuestro kernel falla, no somos kernel developers para descubrir que está pasando y ponernos a hacer debugging (a menos que realmente queramos descubrir que está pasando, en un equipo estable y en producción, estas opciones son innecesarias y ponen además de lento, más pesado el kernel).

Hay muchisimas opciones opciones que activar; en mi caso, deseo evitar usar ndiswrapper para mi tarjeta inalambrica broadcom; para ello activo lo siguiente:

Networking -> Wireless

luego:

â?? -> Device Drivers
â?? -> Network device support (NETDEVICES [=y])
â?? -> Wireless LAN

y escoger luego el driver que más se adecue a nuestras necesidades; en mi caso, broadcom:

Broadcom BCM43xx wireless support (modo modulo “m”)

y seleccionar DMA+PIO en el modo de data transfer.

Para usar el módulo bcm43xx:

instalar el firmware:
fedora: yum install bcm43xx-fwcutter

debian: aptitude install bcm43xx-fwcutter

En ambos casos, debemos tener un .sys (driver windows) para “extraer” el firmware (pero creo que esto lo expliqué en un post anterior y escapa del menester de este post).

modprobe bcm43xx


podremos tener nuestra broadcom funcionando (soporta WEP, WPA, WPA Empresarial, WPA+TKIP y otros modos de infraestructura, aun no soporta ad-hoc correctamente) usando un módulo del kernel y sin tener que usar ndiswrapper.

Virtualización:

Si nuestro CPU soporta virtualización por hardware (tecnologías van-derpool de AMD y Pacifica de Intel), entonces podemos activarla en este kernel en la opción:

â?? -> Device Drivers
â?? -> Virtualization (VIRTUALIZATION [=y])
â?? -> Kernel-based Virtual Machine (KVM) support (KVM [=m])

En este caso; con solo ejecutar:

modprobe kvm_intel (o kvm_amd para usuarios AMD)

tendremos el virtualizador KVM activo, solo nos faltaría instalar el qemu modificado para kvm.

Compilando:

Luego que hemos personalizado nuestro kernel, es hora de compilar!; para ello ejecutamos:

make all (ejecuta todos los make, incluido make docs, make headers y make check)

make modules (inicia la creación de los modulos del kernel)

Instalando:

Para instalar nuestro kernel debemos ejecutar:


make install


y para instalar los modulos:

make modules-install (instala los modulos en /lib/modules/2.6.xx.xx, la ruta a nuestro kernel).

El make install tiene diversas acepciones dependiendo de la distro; en fedora, ejemplo, el make install creará el initrd y modificará el grub de manera acorde; algo que no ocurre en debian; por lo que hay que ejecutar:

make initramfs -o /boot/initrd-2.6.23.1 /lib/modules/2.6.23.1

El comando indica: crear un initrd de tipo ramfs en /boot, con el suffix de nuestro kernel, para el kernel instalado en /lib/modules/2.6.23.1 (o la ruta del kernel que estén instalando).

y luego editar el grub de la siguiente manera:

Editando el grub:

Observemos el siguiente ejemplo:

title Debian GNU/Linux, kernel 2.6.23.1-coreDuo
root (hd0,0)
kernel /vmlinuz-2.6.23.1 root=/dev/sda2 ro idebus=66 pci=routeirq pci=assign-busses irqpoll acpi=force vga=791
initrd /initrd.img-2.6.23.1
savedefault

La opción title indica el nombre que veremos en el grub bootloader; este nombre puede ser como deseemos, pero realmente es bueno que sea descriptivo (como el caso, nombre del kernel y sufijo).

root: indica donde debe quedar el kernel, en este caso, que partición contiene el ramfs y el vmlinux; en mi caso, la primera partición del primer disco (hd: disco[0]: primer disco; [0] primera partición.

Y cual partición sé que está activa?.

ejecuten:

fdisk -l /dev/sda

Este es mi primer disco (noten que grub es inocuo a si es SATA o IDE; siempre será un hd) y verán:

Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/sda1 * 1 65 491368+ 83 Linux
/dev/sda2 66 2003 14651280 83 Linux
/dev/sda3 2004 3295 9767520 83 Linux

La partición con el asterisco es su primera partición activa (y la marcada como arranque) la que posee el el /boot.

kernel es la ruta (relativa a /boot) al vmlinux del kernel actual; la partición donde está root (fijense que /sda1 está activa pero root está en sda2, esto es porque mi mapa de particiones es:

df -hT


S.ficheros Tipo Tamaño Usado Disp Uso% Montado en
/dev/sda2 jfs 14G 7,3G 6,7G 53% /
/dev/sda1 ext2 450M 56M 371M 14% /boot
/dev/sda6 xfs 9,4G 7,4G 2,0G 80% /home
/dev/sda8 ext3 1,4G 35M 1,3G 3% /tmp
/dev/sda9 ext3 1,9G 926M 861M 52% /var
/dev/sda5 jfs 19G 791M 18G 5% /var/lib

Me gusta tener al GRUB en una partición propia; ext2 (no necesita tener journalist el boot), con algunos modos de protección como ro (read-only, se lo quito cuando compilo), nosuid y nodev.

y Listo!, reinicien el equipo y recen un par de plegarias.

Notas adicionales:

En el caso de equipos con solo dispositivos SATA; es completamente SEGURO quitar soporte para IDE/ATAPI en:

-> device drivers
-> ATA/ATAPI/MFM/RLL support

Ya que fuerzan al uso de la libreria libata (en mi caso, intel ata o:

â?? -> Device Drivers
â?? -> Serial ATA (prod) and Parallel ATA (experimental) drivers (ATA [=y])
-> Intel ESB, ICH, PIIX3, PIIX4 PATA/SATA support

Lo cual según pruebas con hdparm es mucho más rápido los accesos que con el básico generic_ide con que monta debian.

No obstante; cuidado!; si hacen esto, deben tomar en cuenta que las unidades se re-nombran de hdx a sdx; con lo cual, si no editan el /etc/fstab para actualizar el cambio de IDE a SATA; obtendran un error al arranque del kernel:

waiting for root filesystem

Lo que indica que el /etc/fstab apunta a un root que NO EXISTE; en mi caso, para evitar problemas, testeo el kernel primero con IDE activo y si funciona, activo el SATA driver y luego cambio el fstab (ya que si edito sin probar el kernel, cometo el craso ERROR de que ni cargará el kernel actual y no podré cargar el viejo kernel (que apuntaba a hda en vez de a sda).

Recuerden que ALSA y tu respectivo AGP GART (en mi caso:

â?? -> Device Drivers
â?? -> Sound
â?? -> Advanced Linux Sound Architecture
â?? -> PCI devices
y seleccionar como modulo a Intel HD Audio

y para AGP:

â?? -> Device Drivers
â?? -> Character devices
â?? -> Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) (DRM [=m])

y seleccionar como modulo a: Intel 830M, 845G, 852GM, 855GM, 865G

Sin estos 2 cambios; ni tendremos Sonido y nuestra tarjeta de video no soportará Direct Rendering (util si deseas instalar compiz-fusion).

Tambien tengo una capturadora de video externa (en mi casa), en este caso, el chipset es BT848 y se ubica en:

â?? -> Device Drivers
â?? -> Multimedia devices
â?? -> Video For Linux (VIDEO_DEV [=m])
â?? -> Video capture adapters (VIDEO_CAPTURE_DRIVERS [=y])

y se selecciona BT848 video for Linux.

Es de acotar que todos los drivers de webcams soportados por Linux, están en esta carpeta (Video For Linux o V4L).

Conclusiones:

En el mundo de hoy, tan lleno de Core2, Core4, core8, multi-cores, Cores/Cores, X2Cores, Cores++ y tantas maquinas potentes, un kernel 2.6.18 compilado para i686 es una pérdida de recursos enorme y es casi que “necesario” compilar nuestro kernel para disfrutar de un montón de nuevas cosas.

Una compilación es algo que lleva tiempo; por lo general entre 20 y 40 minutos dependiendo del tamaño del kernel que se compile (si compilan uno a lo “cleaning mode”, donde quito las cosas que no tengo (como módulos SCSCI o infiniband) pueden reducir ese tiempo en un 30% más o menos) y del equipo dispuesto para la compilación; he visto compilaciones de una hora (en Pentium-3 regularmente); como las he visto de 15 minutos; es cuestión de dedicación, limpieza y recursos.

Pueden experimentar con calma, la compilación de un kernel no desactiva el anterior ni “dañará” tu PC ni nada por el estilo; por lo que pueden comenzar a compilar a sus anchas.

Disfruten de su kernel compilado!…