Si su nuevo núcleo hace cosas raras, puede ser que se le olvidara
hacer `make clean' antes de compilar. Los síntomas suelen ser extraños
cuelgues, problemas de E/S... asegúrese también de hacer `make dep'.
Si su núcleo consume mucha memoria, o la compilación se hace eterna incluso con su nuevo 786DX6/440, probablemente se deberá a haber elegido demasiados manejadores, sistemas de ficheros, etc. a soportar en el sistema. Si no los va a usar, no los incluya, puesto que consumen memoria. Lo típico en estos casos es que se recurre demasiado al intercambio con el disco, lo que se aprecia en un ruido `excesivo' del disco duro.
Puede ver cuánta memoria ocupa su núcleo comparando los valores obtenidos al ver el fichero /proc/meminfo, o con el comando dmesg o el log de los mensajes del núcleo, donde verá algo parecido a esto:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
En mi 386 (con pocos drivers configurados) sale:
Memory: 7000k/8192k available (496k kernel code, 384k reserved, 312k data)
Si no compila, puede ser por un fallo de parcheo, u otro tipo de
corrupción en los ficheros fuente. Además, la versión de gcc puede no
ser correcta o los propios ficheros de
#include. Asegúrese que los
enlaces simbólicos necesarios (descritos en el fichero README de
Linus) existen. En general, cuando un núcleo estándar no se puede
compilar, es porque hay algún problema serio en el sistema, y será
necesario reinstalar algunos programas.
También puede suceder que le den errores compilando el núcleo 1.2.x
con un gcc ELF (2.6.3 o superior). Se puede intentan arreglar
añadiendo las siguientes líneas al fichero arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/includeAhora, haga `make dep' y `make zimage' de nuevo.
En algunos casos muy raros el gcc romperá con un mensaje similar a ``xxx exited with signal 15''. En este caso la solución puede estar en desactivar la cache de segundo nivel, pensar en un fallo hardware de la memoria... o reinstalar de nuevo el gcc.
No se ejecutó LILO, o no está bien configurado. A veces, se ponen
errores como `boot = /dev/hda1' en lugar de `boot =
/dev/hda'.
íVaya problema! Lo mejor que puede hacerse ahora es arrancar con un
disquete y preparar otro disquete para arrancar Linux (con `make
zdisk' se hizo uno). Necesita saber qué sistema de ficheros raíz (/)
tiene, dónde está y su tipo (por ejemplo, ext2 o minix). En este
ejemplo, también hay que saber dónde están los ficheros de /usr, en
otra partición.
En el siguiente ejemplo, / es /dev/hda1, y el sistema con las
fuentes del núcleo es /dev/hda3, montado como /usr
normalmente. Ambos
son sistemas ext2. La imagen compilada estará en el sistema de las
fuentes.
La idea es que si hay un fichero zImage correcto, puede salvarse en
un disquete. Otra posibilidad (que funcionará mejor o peor, según el
caso) se verá en otro ejemplo.
En primer lugar, arranque con un disquete de instalación o de rescate, y monte el sistema de ficheros que contenga el núcleo a usar:
mkdir /mnt
mount -t ext2 /dev/hda3 /mnt
Si mkdir le dice que el directorio ya existe, no hay
problema. Ahora, pase al directorio donde está el núcleo
compilado. Vea que
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/bootPonga un disco con formato en la unidad ``A:'' (que no sea el disquete con el que ha arrancado) y copie el núcleo a él:
cd /mnt/src/linux/arch/i386/boot
dd if=zImage of=/dev/fd0
rdev /dev/fd0 /dev/hda1
vaya a / y desmonte el sistema de ficheros:
cd /
umount /mnt
Ahora puede rearrancar el sistema desde el disquete. íNo olvide
ejecutar LILO!
Como se ha dicho, hay otra alternativa. Si el núcleo está en el
directorio raíz (por ejemplo /vmlinuz), puede usarlo para
un disquete
de arranque. Suponiendo las condiciones anteriores, haríamos los
cambios siguientes en el ejemplo anterior: /dev/hda3 por
/dev/hda1 (el
sistema raíz), /mnt/src/linux por /mnt, y
`if=zImage' por
`if=vmlinuz'. El resto puede ignorarse.
Usar LILO con discos grandes (de más de 1024 cilindros) puede dar problemas. Le recomendamos que lea el mini-HOWTO sobre LILO para más información.
Es un problema muy importante. Desde la versión 1.0 del núcleo (20
de Abril de 1994), hay un programa, `update' que, periódicamente,
vuelca al disco la cache de buffers del sistema. Obtenga las fuentes
de `bdflush' (está donde se distribuyen las fuentes del núcleo) e
instálelas (quizás deba usar mientras lo hace un núcleo
antiguo). Después del rearranque, se instalará en memoria como
`update' y ya no habrá más avisos.
Esto será probablemente porque tenga un compilador ELF (gcc 2.6.3 y
posteriores) y las fuentes 1.2.x o anteriores. Habitualmente esto se
corrige añadiendo las siguientes líneas al archivo
arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Esto permitirá compilar el núcleo 1.2.x con librerías a.out.
Mucha gente tiene este problema, siendo las causas muy diversas.
El error más común es tener el dispositivo en una interfaz IDE sin compañía de otro disco, para lo que debe ser configurado como ``maestro'' (master) o ``único'' (single), nunca como ``esclavo'' (slave).
Creative Labs está poniendo interfaces IDE en sus tarjetas de sonido. Sin embargo, esto es un problema cuando se tienen ya dos interfaces IDE en la placa, en la IRQ 15. Entonces se suele configurar el IDE de la tarjeta de sonido en la IRQ 11 y los núcleos 1.2.x no saben manejar esto (tener, en la práctica, tres IDE).
En las versiones 1.3.x se empieza a intentar soportar esto, pero está en desarrollo y en todo caso no incluye autodetección. Para utilizarlo, pues, deberá hacer algunas cosas.
Si no tiene segunda IDE en placa, cambie los ``jumpers'' de la tarjeta de sonido referentes a la interfaz IDE para que ocupen la IRQ15 (segunda interfaz). Esto debería funcionar.
Si por el contrario hay en total tres interfaces, obtenga un núcleo
1.3.x (por ejemplo, el 1.3.57 lo incluye) y lea el documento
drivers/block/README.ide, donde encontrará más información.
Consiga nuevas versiones de los programas `route' y otros que
manipulan tablas de encaminamiento. El fichero
/usr/include/linux/route.h tiene cambios al respecto.
Actualícese al menos a la 1.2.1.
No utilice el fichero vmlinux creado en /usr/src/linux para arrancar, sino el mencionado zImage.
Ponga `linux' en la entrada `console' del fichero
/etc/termcap. Además, deberá hacer una entrada en terminfo.
El núcleo incluye ciertos ficheros #include (acaban en .h) que se
referencian desde /usr/include. Típicamente se referencian con la
línea:
#include <linux/xyzzy.h>
Normalmente, hay un enlace simbólico `linux' de
/usr/include al
directorio /usr/src/linux/include/linux. Si no existe tal enlace, o
apunta a un lugar incorrecto, muchas cosas compilarán mal. Por
ejemplo, el problema es obvio si borró las fuentes del núcleo porque
le ocupaban mucho. Otro problema puede tener relación con los permisos
de los ficheros, tal vez debido a un umask de la cuenta root que
obligue a crear los ficheros ocultos a otros usuarios por
defecto. Puede solucionar esto con el comando chmod, pero será más
cómodo descomprimir las fuentes del núcleo
añadiendo la opción p (preservar modo) al
comando tar:
blah# tar zxvpf linux.x.y.z.tar.gz linux/include
Nota: Con ``make config'' se crea el enlace
/usr/src/linux si no existe.