Luego de vagar de distro en distro, me quedé con Slackware. No llevo mucho tiempo con ella pero he logrado aprender bastante en este corto período
Slack tiene fama de ser muy estable pero no amigable con el usuario, así que la idea es intentar las cosas de una manera comprensible para todos y tratar de derribar un poco ese mito.
No daré por sentado que la persona que lea esto se maneje al revés y al derecho en el tema de Linux y específicamente de Slackware ya que existe un amplio espectro de usuarios por lo que me explayaré más allá de lo necesario. Así que si piensa que lo que digo es obvio, recuerde que no nació sabiendo :) .
Slackware en su última versión se puede obtener desde un torrent o algún mirror. La lista de sitios de descarga por región se encuentra aquí
Una forma de hacerlo es copiando unos archivos que permitirán iniciar una utilidad de instalación. El problema es que esto requiere contar con los archivos de instalación en una partición y durante el setup apuntar a ella. Las instrucciones detalladas de que archivos copiar y como se encuentra en
la wiki de Eric Hamerless (en ingles)
Unetbootin es una utilidad multiplataforma que permite crear unidades autoarrancables de manera automática. Para iniciar el proceso, podemos elegir una distribución del menú o elegir una imagen de disco. Luego elegimos la unidad que deseamos y ponemos iniciar. Esto descargará (si se eligió del menú) y copiará los archivos, además instalará un cargador de arranque.

Si uno se fija, Slackware no aparece en la lista, por lo que deberemos descargar la imagen y cargarla en el programa, insertamos un pendrive con suficiente capacidad (alrededor de 4GB para el dvd o 700 MB para el CD) e iniciamos el proceso. Al momento de escribir esto, este procedimiento funcionó con slackware 13.1, pero no tengo certeza si funcionará con versiones previas.
Una vez concluido, podremos iniciar Slackware de manera completa desde nuestro pendrive.
Dentro del setup, cuando nos pida elegir la fuente de la instalación, debemos escoger la opción de que los archivos se encuentran en una partición (se sugiere hacer fdisk -l para identificarlas bien)
Entonces al elegir la unidad ponemos algo como
/dev/sdbx
/slackware
Y el proceso de instalación continuará normalmente.
La presente guía no fue escrita por mi, sólo una traducción de la guía de Alien publicada en su wiki.
La guía original puede ser encontrada (en inglés) en http://alien.slackbook.org/dokuwiki/doku.php?id=linux:kernelbuilding
Así que como es obvio todo el crédito va para él.
¿Por qué construir un kernel nuevo si mi sistema anda bien con el actual?
Pues el kernel es el núcleo del sistema, se encarga de varias funciones como por ejemplo gestionar los recursos de hardware, manejo de aplicaciones relación entre hardware y software, etc.
Nuevas versiones del kernel, pueden incorporar entre otras cosas: Parches para fallas de seguridad,correcciones de errores, soporte de hardware, y otras diversas funciones nuevas. Entonces es lógico que si necesita algo de lo mencionado anteriormente, esta guía le será útil.
Las últimas versiones con su respectiva información sobre los cambios puede ser encontrada en www.kernel.org
Ejecuto los comandos desde una terminal X y, en algún punto, inicio el configurador del kernel (basado en X).
El escritorio corre como “yo” (mi usuario) pero construyo mis kernels como root. Para lograr lo anterior y hacer que root tenga acceso a mi servidor X, hago lo siguiente desde mi terminal: Obtener privilegios de superusuario, unir mi propio archivo Xauthority con el de root, y asignar la variable DISPLAY. Después de hacer eso, puedo ejecutar aplicaciones X desde la terminal "su".
echo $DISPLAY #necesitará este valor 3 líneas más abajo sudo -i #o “su -” en versiones más viejas de Slackware xauth merge ~alien/.Xauthority # use su propio nombre de usuario en vez de “alien” export DISPLAY=:0.0 # use el valor de DISPLAY obtenido 3 líneas antes
Alternativamente puede usar el siguiente comando que dará el mismo resultado
sudo -s # Un efecto secundario de '-s' es que permite a root ejecutar programas basados en X . /etc/profile #Proveer el perfil global, asegura que root tiene los directorios ''sbin'' en el $PATH
wget <a href="http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2<br /> tar" title="http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2<br /> tar">http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2<br /> tar</a> -C /usr/src -jxvf linux-2.6.27.7.tar.bz2 cd /usr/src rm linux # remueve el vínculo simbólico existente ln -s linux-2.6.27.7 linux # crea un vínculo simbólico apuntando a su nueva fuente linux
Hay un debate acerca de si deberían compilar los kernels en el árbol /usr/src o en alguna parte completamente diferente.
La causa del debate es un viejo post escrito por Linus Torvalds (julio de 2000) donde aconseja a la gente el construir el kernel desde dentro del directorio del usuario (home). Yo creo que el consejo es irrelevante para Slackware por la forma en que tiene sus “kernel headers” y la configuración del paquete glibc. Así, mi consejo es ignorar este viejo post de Linus Torvalds e instalar las fuentes del kernel en /usr/src si así lo desea. La localización del entorno de construcción del kernel es sólamente un asunto de preferencia personal.
Ahora, obtenga un archivo de configuración del kernel de Slackware para tener ventaja inicial durante su propia configuración. Los archivos de configuración de Pat son bastante genéricos.
Para cuando lea esto, pueden haber archivos disponibles para una nueva versión 2.6.x
wget <a href="http://slackware/mirrors.tds.net/pub/slackware/slackware-12.2/source/k/config-generic-smp-2.6.27.7-smp<br /> cp" title="http://slackware/mirrors.tds.net/pub/slackware/slackware-12.2/source/k/config-generic-smp-2.6.27.7-smp<br /> cp">http://slackware/mirrors.tds.net/pub/slackware/slackware-12.2/source/k/c...</a> config-generic-smp-2.6.27.7-smp /usr/src/linux/.config
zcat /proc/config.gz > /usr/src/linux/.config
Ejecute make oldconfig en el directorio donde estén las fuentes del kernel nuevo, así las opciones predeterminadas son usadas desde el archivo .config que recién instaló. Dado que las fuentes de su kernel son más nuevas que su archivo .config, habrán nuevas opciones de configuración. Usted sólo deberá responder a éstas( presione enter para aceptar los valores por defecto, o M para contruir el controlador como un módulo)
cd /usr/src/linux make oldconfig
Ahora ha configurado un kernel bastante genérico (esa es probablemente la razón por la que Pat lo llama “kernel-generic”) pero seguramente querrá cambiar algunas cosas para que se ajuste a sus necesidades. Para ello ejecute el configurador basado en X (si no tiene un servidor X corriendo y está en una consola, sólo ejecute “make menuconfig” para obtener el programa basado en curses)
make xconfig
De un paseo por el bosque de opciones. Lo que usualmente cambio son cosas como:
Finalmente guarde su configuración si está satisfecho con ella.
make bzImage modules # compila el kernel y los módulos make modules_install # instala los módulos en /lib/modules/<kernelversion> cp arch/x86/boot/bzImage /boot/vmlinuz-custom-2.6.27.7 # copia el nuevo kernel cp System.map /boot/System.map-custom-2.6.27.7 # copia System.map (opcional) cp .config /boot/config-custom-2.6.27.7 # copia de respaldo de su coniguración del kernel cd /boot rm System.map # borra el vínculo antiguo ln -s System.map-custom-2.6.27.7 System.map # crea un nuevo vínculo
image = /boot/vmlinuz root = /dev/hda1 label = linux read-only # Non-UMSDOS filesystems should be mounted read-only for checking
image = /boot/vmlinuz-custom-2.6.27.7 root = /dev/hda1 label = newkernel read-only # Non-UMSDOS filesystems should be mounted read-only for checking
lilo
default = newkernel
Hay dos lugares donde encontrará kernel headers: uno es dentro del directorio del código fuente del kernel (en nuestro caso /usr/src/linux-2.6.27.7) y el otro lugar es /usr/include/linux. El paquete kernel-headers usualmente contiene las cabeceras tomadas del código fuente del kernel que Slackware tiene por defecto. Estas cabeceras particulares, son usadas cuando el paquete glibc es construido. El hecho que el paquete kernel-headers instala estos archivos a /usr/include/linux los hace independientes de los archivos de cabecera que encontrará en el directorio del código fuente.
Mientras no remueva glibc, no debería actualizar o remover el paquete kernel-headers
cd /var/log/packages grep -l "lib/modules/$(uname -r)" *
Para ALSA, tiene opciones: habilitar el controlador ALSA que es parte del kernel que ha descargado o bien dejar la configuración del kernel como Slackware, esto es: deshabilitar todo el soporte ALSA del kernel y en vez de eso reconstruir el paquete alsa-driver. El kernel 2.6 de Slackware 12.2 tiene los controladores ALSA integrados, porque los que pueden ser instalados separadamente no funcionarán
VFS: Cannot open root device "802" or unknown-block (8,2) Please append a correct "root=" boot option Kernel Panic-not syncing: VFS: unable to mount root fs on unknown block(8,2)
Ingrese al directorio /boot
cd /boot
mkinitrd -c -k 2.6.27.7 -m reiserfs
mkinitrd -c -k 2.6.27.7 -m ext3
Agregue la línea “initrd = /boot/initrd.gz” a la sección “newkernel” en el archivo /etc/lilo.conf. Guarde los cambios y luego re-ejecute lilo; Usaré el ejemplo de lilo.conf que ya había usado en las secciones anteriores
image = /boot/vmlinuz-custom-2.6.27.7 root = /dev/hda1 initrd = /boot/initrd.gz label = newkernel read-only # Non-UMSDOS filesystems should be mounted read-only for checking
lilo
Si ya está usando una imagen initrd con su kernel actual, puede elegir entre dos opciones:
Crear una seguna imagen initrd usando el comando que se muestra a continuación, pero con un nombre explícito para el archivo resultante (el cual debe ser diferente del nombre por defecto para no sobreescribir el antiguo)
mkinitrd -c -k 2.6.27.7 -m ext3 -o /boot/initrd-custom-2.6.27.7.gz
image = /boot/vmlinuz-custom-2.6.27.7 root = /dev/hda1 initrd = /boot/initrd-custom-2.6.27.7.gz label = newkernel read-only # Non-UMSDOS filesystems should be mounted read-only for checking
mkinitrd -k 2.6.27.7 -m ext3
./mkinitrd_command_generator.sh /boot/vmlinuz-generic-smp-2.6.27.7-smp # # $Id: mkinitrd_command_generator.sh,v 1.11 2008/04/10 23:56:18 root Exp root $ # # This script will now make a recommendation about the command to use # in case you require an initrd image to boot a kernel that does not # have support for your storage or root filesystem built in # (such as the Slackware 'generic' kernels'). # A suitable 'mkinitrd' command will be: mkinitrd -c -k 2.6.27.7-smp -m ata_generic:pata_amd:mbcache:jbd:ext3 -f ext3 -r /dev/hda7 # An entry in 'etc/lilo.conf' for # kernel '/boot/vmlinuz-generic-smp-2.6.27.7-smp' would look like this: # Linux bootable partition config begins image = /boot/vmlinuz-generic-smp-2.6.27.7-smp initrd = /boot/initrd.gz root = /dev/hda7 label = 2.6.27.7-smp read-only # Linux bootable partition config ends
En Slackware 12.0 y versiones posteriores, el kernel 2.6.x es el único kernel que está disponible. La carga de los módulos está manejada por udev y explícitamente por los comandos modprobe: los módulos que no son cargados por udev pueden ser puestos todavía en un archivo rc.d.
Slackware revisará por la existencia de los siguientes archivos (ejecutables) en éste orden:
$(uname -r) es la actual versión del kernel. Entonces, por ejemplo, si su versión del kernel es 2.6.27.7-smp, entonces Slackware buscará un archivo /etc/rc.modules-2.6.27.7-smp para ejecutar. De esta manera, archivos rc específicos para diferentes kernels pueden estar presentes, permitiendo un “afinamiento” óptimo de su sistema
EL paquete de Slackware 12.2 /slackware/a/kernel-modules-smp-2.6.27.7_smp-i686-1.tgz instalará el archivo /etc/rc.d/rc.modules-2.6.27.7-smp. Puede usar éste como un ejemplo si quiere construir si propio kernel y necesita comandos modprobe explícitos para módulos específicos del kernel
Si decide construir su propio kernel 2.6 desde las fuentes, podría intrigarse por el hecho que no habrá un archivo llamado /etc/rc.d/rc.modules-$(uname -r)- deberá crearlo. rc.modules es usualmente un vínculo simbólico a rc.modules-2.6.27.7-smp. Un resultado típico de la ausencia de un archivo rc.modules para su kernel específico es que su mouse no responderá. Tome ese comportamiento como una pista para crear el archivo rc.modules. Puede basarse en una copia completa de cualquier archivo rc.modules-2.6.xx. Si su sistema no tiene ningún archivo, puede tomar uno del CD de Slackware como un ejemplo:
/source/k/kernel-modules-smp/rc.modules.new.
Aquí hay un ejemplo en caso que hubiera construido un kernel versión 2.6.28.8.alien teniendo ya instalado un kernel versión 2.6.27.7-smp
cp -a /etc/rc.d/rc.modules-2.6.27.7-smp /etc/rc.d/rc.modules-2.6.28.8.alien
El archivo /etc/rc.d/rc.modules-2.6.28.8.alien será usado cuando su kernel 2.6.28.8.alien arranque
Primero, importe la llave OpenPGP en su llavero GnuPG; ya sea copiándola desde la página de firmas o importándola desde un servidor. La clave ID del kernel es 0x517D0F0E. Un ejemplo sería algo como:
gpg --keyserver wwwkeys.pgp.net --recv-keys 0x517D0F0E
La salida resultante será
gpg: key 517D0F0E: public key "Linux Kernel Archives Verification Key
gpg: Total number processed: 1
gpg: imported: 1
A continuación obtenga el archivo de firmas para el kernel que acaba de descargar
wget http://www.us.kernel.org/pub/linux/kernel/v2.6/linux-2.6.27.7.tar.bz2.sign
El paso final es ejecutar gpg en este archivo de firma
gpg --verify linux-2.6.27.7.tar.bz2.sign linux-2.6.27.7.tar.bz2
Y chequear lo que tiene que reportar
gpg: Signature made Fri 21 Nov 2008 12:10:49 AM CET using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key <ftpadmin@kernel.org>"
gpg: checking the trustdb
gpg: checking at depth 0 signed=1 ot(-/q/n/m/f/u)=0/0/0/0/0/4
gpg: checking at depth 1 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/1/0
gpg: next trustdb check due at 2012-12-21
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Sin embargo el resultado es que el archivo del código fuente fue realmente firmado con la llave que importó. Así que son buenas noticias
Puede que por alguna razón el cargador de arranque muera. Ya sea por reinstalar o instalar otro sistema como windows, porque no se instaló lilo durante la instalación de Slackware, etc. En ese caso y para contar de nuevo con lilo, se debe realizar lo siguiente (asumiendo que el sistema está; instalado):
boot: hugesmp.s root=/dev/sdaX rdinit= ro
Luego el sistema arrancará como normalmente lo hace y se podrá editar lilo.conf si es requerido o bien reinstalarlo usando (como súper usuario)
lilo