make clean 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)/include
Ahora, 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 caché 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'.
LILO, y el sistema ya no arrancaˇ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/boot
Ponga 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.
warning: bdflush not running' 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 caché 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 el 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 IRQ 15 (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.
1.2.0Actualícese al menos a la 1.2.1.
Not a compressed kernel Image file''No utilice el fichero vmlinux creado en /usr/src/linux para
arrancar, sino el mencionado zImage.
1.3.xPonga `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.