sk@sethwklein.net
Traducido por el proyecto LFS-ES
11 de Junio de 2003
Las FAQ tratan de responder preguntas antes de que sean hechas. Esto ahorra la molestia de preguntarlas y, algunas veces, la molestia de encontrar un problema.
Así se reduce el tráfico y se mejora la relación señal-ruido, pero esto es sólo un efecto secundario.
Ya que las FAQ no son el sitio natural para buscar información, las preguntas deberían añadirse sólo si no pueden incluirse en la documentación apropiada, aunque algunas veces será necesario poner un enlace a la información de la documentación.
LFS significa Linux From Scratch (Linux desde cero) y es un proyecto que documenta cómo instalar un sistema Linux bajando, construyendo e instalando los paquetes por ti mismo.
Para ver por qué querrías hacer esto, cómo hacerlo, y otra información útil, consulta la página web del proyecto en http://www.linuxfromscratch.org/.
Bueno, esta no es realmente una FAQ, pero tenía que ponerlo en algún lugar. ;-)
Esta FAQ está dedicada, no a una hermosa mujer, sino a mi tío John, quien fue el primero en sugerirme (lo más amablemente posible) que me buscara "un sistema operativo de verdad."
Gracias a...
Todos los muchachos (y todas las muchachas también, ojalá hubiera más) que participan en las listas de correo, cuyas respuestas dieron lugar a muchas de las respuestas que encontramos aquí.
Especialmente a aquellos que clasificaron una pregunta, sus síntomas y su respuesta y me las enviaron. Sus nombres están inmortalizados en el historial del CVS (aunque es sólo un suspiro en un tiempo digital, pero bueno, lo intento :-)
Tushar Teredesai y Jeroen Coumans quienes han sugerido enlaces a las FAQ en la lista lfs-support hasta el cansancio.
Los editores del BLFS, cuyo libro produce unas bonitas FAQs.
He aquí algunos puntos completamente prácticos de netiquette. Estos incluyen solamente aquellos puntos que alguien podría comentar que has obviado. Los que participan en las listas de distribución del proyecto encontrarán obvios los primeros. Hacia el final hay más que no son tan obvios.
Las razones para esto van a ser omitidas para ser breves, pero ténganlo por seguro, las hay, y esas razones son más que sólo una preferencia de alguna persona en particular.
Teniendo esto en cuenta, he aquí varios consejos sobre comportamiento seguidos de cuestiones mas "técnicas":
A pesar que este texto se refiere exclusivamente a "las listas" no pretende ignorar los grupos de noticias a los cuales se envían los mensajes.
Por favor, recuerda que es grosero enviar preguntas que ya están respondidas en la documentación obviamente disponible tales como los libros LFS y BLFS, este PMF (FAQ), las recetas de LFS, las páginas del manual apropiadas, el archivo de la lista, y las búsquedas simples en Google. Mientras puedas demostrar que has hecho un esfuerzo para encontrar la respuesta y no te ofenda que te indiquen alguna documentación, no deberíais preocuparos. Aquél que lo haga puede ser ignorado; lo tiene merecido.
La mayoría de los intercambios de insultos (flamewars) comienzan cuando algún novato con un ego extragrande envía una pregunta obvia, entonces algunos le critican (incluso de manera educada), y éste llega a ser públicamente ofendido. Por favor, intenta evitar esta situación. Con pocas palabras intenta remitirles a la documentación exacta que debieron leer. Si crees que debes criticarle, por favor hazlo a través de su correo personal, no en la lista. Aplicad lo mismo a cualquier situación que pueda caldearse.
La lista tiene miembros de muchas nacionalidades por lo que el lenguaje coloquial de todo tipo y idioma será normalmente mal entendido. (Atestiguado por la reciente discusión sobre "bootstrapping".) Cualquier mención a la blasfemia, política, guerra o religión (incluso en la firma) puede molestar a alguien en algún lugar, así que por favor evítalas. Finalmente, se considera correcto el escribir en ingles aunque la gente de la lista sepa más idiomas.
Ahora vamos a por las cosas "más mecánicas".
No envíes mensajes en HTML. Si usas Yahoo, Hotmail, o Outlook y no has desactivado el HTML, entonces está activado. Si estás usando algún otro cliente de correo, por favor verifica esto antes de enviar algún mensaje. Echa un vistazo a http://www.expita.com/nomime.html.
Escribe tus mensajes a 72 caracteres por línea. Si no deseas hacer esto a mano, configura tu cliente de correo para hacerlo automáticamente al enviar.
Responde debajo del texto del mensaje original. En Outlook es difícil hacer esto Hay un añadido (plugin) para arreglar el Outlook en http://home.in.tum.de/~jain/software/outlook-quotefix/, y uno para Outlook Express en http://home.in.tum.de/~jain/software/oe-quotefix/.
Limitar la firma a 4 líneas.
Recorta el texto del mensaje original, y especialmente las firmas. Pero no cortar tanto como para hacer confusa tu respuesta sin consultar el original.
No hagas click en "responder" a menos que de hecho estés respondiendo a un mensaje. Utiliza "nuevo" o "redactar" o como sea que lo llame tu cliente de correo. Responder hace mucho más que establecer la linea del asunto y hará que tu mensaje aparezca en donde no debe, a menos que de hecho estés respondiendo.
Esto que sigue no es lo más importante, pero es útil conocerlo. En las listas de LFS, la gente suele borrar el contenido del campo CC y sólo envía sus respuestas a la lista. Esto probablemente no es una buena idea, pero existe en la práctica debido a una situación política la cual es improbable que cambie.
La respuesta completa está en http://www.linuxfromscratch.org/mailinglists/, pero aquí tienes un resumen:
Envía preguntas de soporte sólo a las listas lfs-support y blfs-support. Preguntas del tipo "¿Cómo hago...?" y "Estoy obteniendo este error..." o cualquier otra petición de ayuda deben dirigirse a las listas de soporte, y a ningún sitio más.
Si no estás teniendo ningún problema siguiendo el libro LFS, no preguntes en lfs-support.
Si no estás enviando ninguna sugerencia para mejorar el propio libro LFS, no envíes a lfs-dev.
Sólo se aceptan sugerencias sobre el libro BLFS en la lista blfs-dev.
Las cosas son un poco diferentes para blfs-support. Cualquier cosa que no quepa en una de las listas anteriores tiene cabida aquí, excepto para el precio de la cerveza y las peleas de GNU contra BSD.
El precio de la cerveza, las peleas de GNU contra BSD y las peleas de Microsoft contra Linux deben restringirse a lfs-chat. Hoy en día, la discusión sobre hardware también debería ir aquí.
Cuando estas FAQ no te ayuden, hay varios sitios a los que puedes acudir.
Si tienes problemas con algo del libro, nunca está de más volver al libro. Es sorprendente con qué facilidad se pueden pasar por alto pequeños detalles.
Si lo anterior no funciona, leer las páginas de manual y los documentos info apropiados te proporcionará información útil sobre el tema, aunque no encuentres lo que estás buscando, y tendrás los conocimientos necesarios para no avergonzarte si tienes que preguntar a alguien.
http://lucas.hispalinux.es/ tiene traducidos al castellano los COMOs y una gran cantidad de documentación. Puedes encontrar algo allí. En http://www.tldp.org/ se encuentran los originales en inglés.
El sitio de búsqueda de linuxfromscratch.org incluye las listas de correo. Muchas preguntas se han discutido allí al menos una vez. Puedes encontrarlo en http://search.linuxfromscratch.org/.
Si deseas soporte, el IRC normalmente es mejor. Es más rápido y no atasca las listas de correo. Se puede encontrar información sobre los canales IRC de LFS en http://www.linuxfromscratch.org/misc/irc.shtml.
Hay dos canales interesantes en el IRC. #LFS, que es el canal de la comunidad, y #lfs-support, que es para soporte. Si vas a pedir soporte es más fácil encontrar ayuda competente y amistosa en #lfs-support.
Como último recurso, están las listas de correo. La gente se enfadará contigo si no usas la adecuada o si envías mensajes a más de una lista (cross post). Puedes encontrar información sobre las listas de correo en http://www.linuxfromscratch.org/mailinglists/, y además te indica que lista usar.
Las sugerencias son muy bien recibidas. Puedes contactar con el desarrollador de estas FAQ tanto directamente en su dirección de correo electrónico, como en la lista de correo apropiada.
Entre las sugerencias útiles se incluye añadir preguntas que son formuladas frecuentemente - con respuestas bien elaboradas - y la eliminación de preguntas que estén obsoletas.
Contribuciones regulares y serias también son bienvenidas. Si estás interesado en esto, necesitas crearte una copia local de la FAQ a partir del módulo CVS de LFS, igual que harías con el libro, y modificar las fuentes DocBook XML. Estas modificaciones deben suministrarse, normalmente, como parches generados con "diff -Naur", pero para adiciones simples que implican añadir un solo fichero, puede ser más sencillo enviar sólo ese nuevo fichero.
Todo lo que se prevea incluir en la FAQ, sin implicar correcciones sustanciales, debe estar bien pensado, comprobado e investigado, y escrito en un estilo consistente con el contenido actual.
No, los comandos "ln -s" del libro estan bien. Un enlace simbólico no es más que un fichero especial que contiene el nombre del fichero. Así que el nombre del fichero es relativo al enlace, y no al directorio desde el que se crea el enlace. Pruebalo y lo veras.
Prueba "ls -i /bin/foo /bin/bar". ¿Tienen el mismo número de inodo? Si es así entonces no son copias, son enlaces duros.
Si esta es la primera vez que construyes el LFS, usar una versión que no está en el libro o desviarse del libro de alguna forma, no es una buena idea. En el canal de IRC, los que concurren regularmente tienen un dicho, "FBBG". Como rms, el bot residente rápidamente aclara, esto significa "Follow Book, Book Good" (Sigue el Libro, el Libro es Bueno). Ellos y los participantes de las listas de correo han ayudado muchas veces a algún novato descontento que se desvió del libro en su primera instalación.
Una vez que construyas un sistema "como manda el libro", tendrás una base estable de conocimientos a partir de la que experimentar lo que a tu corazón alegre (o entristezca, como suele suceder).
Para ayudarte durante tu recorrido, aquí tienes algunas notas para versiones específicas:
flex-2.5.31: Esta versión es mala. En #lfs-support se dice que funcionará con XFree86 4.0.3.1, las últimas binutils de HJL y usando "flex -l" con modutils, lo que puede hacerse con http://evanidus.ath.cx:8080/l14h/patches/personal/modutils-2.4.25-flex-2.5.31-tmp-fix.patch.bz2 También tendrás problemas con libidl y quizás otros más. Si lo intentas será por tu cuenta. No esperes ningún tipo de soporte. Probablemente, la versión 2.5.27 funcionará sin tantos ajustes extraños.
gcc-3.3: No uses esta versión aún, a menos que seas un desarrollador y puedas corregir los errores que se te presenten, porque compila mal muchos paquetes. Si eres un desarrollador, puedes encontrar útiles los parche de Jim Gifford. Se encuentran en http://www.jg555.com/projects/patches/ftpdownload/
glibc-2.3.2: A las instrucciones de instalación añade esto:
touch /etc/ld.so.conf && ln -s /static/bin/pwd /bin/pwd && touch /usr/include/assert.h && |
bash-2.05b: Aplica los parches de ftp://ftp.gnu.org/gnu/bash/bash-2.05b-patches/ y configura la versión estática (Capítulo 5) con la opción --without-bash-malloc.
Si la nueva versión tiene más de un día, es muy probable que haya alguien probándola e informando de ello en las listas de distribución. Busca en los archivos antes de enviar preguntas sobre sí funciona.
Si quieres informar sobre una nueva versión de un paquete, sigue los siguientes pasos y evita duplicar el aviso:
Comprueba la página de freshmeat del proyecto para ver si ha sido actualizada. Si no lo ha sido, informa de la nueva versión allí.
Si freshmeat ha sido actualizado, comprueba el bugzilla de LFS (o el bugzilla de BLFS) para ver si se ha enviado un mensaje sobre esa versión.
Si la versión no está en bugzilla, avisa en la lista de correo lfs-book (o blfs-book para paquetes de BLFS). Y si lo deseas, prueba e informa de cualquier problema o cambio en las instrucciones de compilación.
Normalmente, los sistemas Unix ejecutan sulogin si, en el arranque normal, el programa fsck encuentra errores. Así el administrador puede entrar en el sistema y arreglarlo. Como sulogin aceptará cualquier contraseña si el fichero /etc/passwd se ha corrompido, los desarrolladores de LFS decidieron que esto era un riesgo para la seguridad. Por lo tanto, los guiones de arranque de LFS apagan la máquina si fsck encuentra errores; entonces debe ser arrancada con "init=/bin/bash" como parámetro del núcleo para conseguir un intérprete de comandos para el administrador. Decidir si esto es deseable sobrepasa el alcance de estas FAQ, pero si esto no te funciona, puedes querer cambiar ese guión de arranque antes de que sea demasiado tarde.
LFS es un sistema muy básico, a diferencia de las distribuciones tradicionales. La razón es la siguiente: LFS no está pensado para crear tu sistema como tu quieras. Está pensado para contener la suficiente información para permitirte construir tu sistema como tu quieras. No es un fin, es un principio. Cuando hayas acabado con LFS es cuando empiezas a construir tu sistema.
Esto puede ser un problema si no tienes experiencia con sistemas Unix y quieres una típica instalación de escritorio con las X y un navegador, pero no tienes ni idea de qué paquetes necesitas. Por esta razón existe BLFS (Más allá de LFS). Puedes encontrarlo en http://beyond.linuxfromscratch.org/.
GRUB, probablemente, reemplazará a LILO en el libro cuando los desarrolladores de GRUB hagan una versión a la que llamen estable. Si te gustaría que eso ocurriese, avisa a los desarrolladores de GRUB, ya que las versiones actuales parecen perfectamente estables.
Si en tu configuración actual usas GRUB o te gustaría usarlo, no deberías tener ningún problema si sigues su documentación y el "GRUB-Cómo" de LFS, que puedes encontrar en http://hints.linuxfromscratch.org/hints/grub-howto.txt. Si haces esto, puedes omitir bin86, debido a que sólo es usado por LILO.
De momento, el libro se ha detenido en LILO 22.2 porque las versiones de LILO posteriores a la 22.2 requieren nasm. Aunque instalar nasm no es un problema, el libro y muchos usuarios son reacios a instalar un paquete extra sólo para LILO. Muchos usuarios se están cambiando a GRUB. (El libro posiblemente cambiará a GRUB si los desarrolladores de GRUB hacen una versión a la que llamen estable. Puedes contactar con los desarrolladores de GRUB si deseas que esto suceda.)
Los usuarios que cambien a GRUB pueden omitir bin86, pues sólo es usado por LILO.
Marc Heerdink puede que sea quien mejor lo haya dicho en un correo a la lista lfs-dev:
El problema es que las FAQ son un documento dinámico. Las FAQ para una versión del libro sólo se publican después de la propia versión del libro, porque las FAQ se actualizan para reflejar las preguntas hechas sobre la versión actual del libro. Es mejor incluir un enlace; de esta forma, siempre tendrás a mano las respuestas actualizadas.
Este es un tema ampliamente discutido en el hilo que se puede leer en http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/02/0012.html.
El libro incluye ed porque patch lo usa para procesar guiones ed. De todas formas, estos son raros hoy en día; todo el mundo utiliza parches con formato diff.
Pero ed tiene otros usos:
Para todos aquellos que han aprendido a utilizarlo, ed es un editor de emergencia muy útil. El cliente de telnet estándar de MS Windows puede funcionar con ed, pero tiene problemas con editores de pantalla completa (como vim). Y un vim con todas sus funciones no sólo necesita ncurses, sino también X11. Cualquier problema con esas librerías dejaría al sistema sin un editor si ed no estuviera presente.
Aunque no es una razón para incluir ed en el libro, a algunas personas les gusta ed.
Conocer ed ayuda a entender vi(m) y la historia de Unix en general.
La gestión de paquetes -más allá de la proporcionada por los archivos de código fuente - está fuera del alcance del libro. Si ninguna otra parece válida, el número de diferentes "soluciones" debería apuntar a algunas de las razones.
Estas son algunas de las opciones:
No es necesario ningún tipo de gestión de paquetes en realidad. A menos que sea deseable supervisar minuciosamente la colocación de los ficheros de los paquetes, cualquier paquete lo suficientemente grande como para justificar su borrado por razones de espacio de disco puede instalarse en /opt como se detalla en la norma FHS (tal vez en /opt/foo-x.x con un enlace desde /opt/foo), y las nuevas versiones pueden instalarse sobre las anteriores, aunque los cambios de versión mayor y las librerías se actualizan mejor, generalmente, reconstruyendo el sistema desde ese punto en adelante.
Un buen número de distribuciones utilizan RPM, el Gestor de Paquetes de Redhat (Redhat Package Manager), Está disponible en http://www.rpm.org/, y hay una receta sobre RPM para ayudar con su instalación en http://hints.linuxfromscratch.org/hints/rpm.txt.
Hay un sistema LFS basado en RPM en http://www.puxedo.org/lvr/
Existen varias implementaciones de administradores de paquetes del estilo "enlaces simbólicos":
Epkg está disponible en http://encap.cso.uiuc.edu/epkg/.
Graft está disponible en http://www.gormand.com.au/peters/tools/.
GNU Stow está disponible en http://www.gnu.org/software/stow/.
Depot está disponible en http://asg.web.cmu.edu/depot/.
La documentación de Graft menciona muchos otros en http://www.gormand.com.au/peters/tools/graft/graft.html#research.
El gestor de paquetes de NetBSD, pkgsrc, también está disponible para otros sistemas, incluyendo Linux. Encuéntralo en http://www.netbsd.org/zoularis/.
Originalmente basado en un guión escrito por el propio Gerard Beekmans (cabeza de LFS), install-log guarda una lista de los ficheros instalados por un paquete mientras éste se instala. Está disponible en http://install-log.sourceforge.net/.
Desde entonces, Gerard ha añadido algunas cosas a este guión. Están disponibles en http://linuxfromscratch.org/~gerard/log-install and http://linuxfromscratch.org/~gerard/pkgdel.
CheckInstall intenta registrar las llamadas al sistema que hace "make install". Está disponible en http://asic-linux.com.mx/~izto/checkinstall/.
pkgutils, usado en la distribución CRUX, está disponible en http://www.fukt.bth.se/~per/pkgutils/.
Más información sobre estos y otros sistemas interesantes la tienes en http://hints.linuxfromscratch.org/hints.shtml#package.
Kelledin mantiene una lista de soluciones para compilar en la plataforma Alpha en http://skarpsey.dyndns.org/alpha-lfs/alpha.html.
Por razones de ancho de banda, el paquete lfs-packages ya no está disponible. Esto está sujeto a cambio, pero por ahora los paquetes pueden descargarse en bloque mediante un guión para wget. Para LFS-4.1 tienes este: http://linuxfromscratch.org/~highos/packages-ordered.wget y para la versión CVS del LFS tienes otro: http://archive.linuxfromscratch.org/mail-archives/lfs-support/2003/05/att-0492/01-lfs-cvs-20030516.wget. La página de manual de wget(1) indica cómo usar estos guiones.
Usualmente, no es difícil, pero algunos pueden requerir una buena búsqueda.
Para encontrar un comando, debes saber a que paquete pertenece. A veces es obvio, pero cuando no lo es, una búsqueda en http://www.debian.org/distrib/packages#search_contents o en http://www.rpmfind.net te dará la respuesta.
Una vez que sepas que paquete es, al buscar en http://freshmeat.net/ por
foo |
En http://www.google.com/, utilizando una búsqueda como
+foo +index +lsm |
Si el resultado de la búsqueda está saturado de paquetes RPM y ficheros Debian, prueba
+foo +index +lsm -RPM -debian |
Los resultados en http://www.ibiblio.org/ con frecuencia son buenos. Para encontrarlos específicamente usa
foo site:ibiblio.org |
Si la última versión es demasiado antigua, Debian o un SRPM pueden tener parches que te ayuden, y puede que haya un sustituto moderno para el paquete que una búsqueda en freshmeat seguramente encontrará.
Además de la documentación del núcleo en /usr/src/linux/Documentation o dondequiera que hayas desempaquetado las fuentes del núcleo, y de la ayuda en la herramienta de configuración del núcleo (make menuconfig), lee el Module-HOWTO en http://www.tldp.org/HOWTO/Module-HOWTO/ y el Kernel-COMO en http://lucas.hispalinux.es/COMO-INSFLUG/COMOs/Kernel-Como/.
Cualquier distribución reciente servirá. Si tienes problemas, intenta instalar y/o actualizar los paquetes de desarrollo (busca aquellos que comiencen por "gcc", "glibc" o "libstdc++" o que terminen en "-dev").
Hay instrucciones en el consejo sobre NFS, que puedes encontrar en http://hints.linuxfromscratch.org/hints/nfs.txt.
Además, Marc Heerdink escribe:
Tengo una versión de tcp_wrappers y de portmap que han sido parcheadas con los parches de Debian, se han adaptado los Makefiles para LFS y se han arreglado todos los problemas y avisos de compilación. Además, se ha incluido un guión llamado lfs-install.sh que proporciona una manera realmente rápida y fácil de instalarlos. Ambos pueden encontrarse en http://www.linuxfromscratch.org/~gimli/. Puedes añadir una nota sobre estos paquetes para la gente que quiere hacerlo de la manera sencilla :)
En Mandrake/RPMS2/libncurses5-devel-5.2-16mdk.1586.rpm, en el Disco 2. El número de versión puede ser diferente (si no tienes libcurses.a (sin "n"), lee de nuevo las instrucciones del libro para bash más cuidadosamente).
Hay varias Recetas en la sección "Booting" en http://hints.linuxfromscratch.org/hints.shtml#booting.
También hay imágenes ISO en http://www.stockwith.co.uk/iso/ y http://pogostick.net/~peram/lfs/.
Gerard describe el proceso de crear una instalación de LFS de 5MB en un correo que se puede encontrar en http://archive.linuxfromscratch.org/mail-archives/lfs-support/2001/10/0072.html, y hay enlaces a muchos recursos en un mensaje enviado por Cor Lem, que se puede encontrar en http://archive.linuxfromscratch.org/mail-archives/lfs-support/2002/06/0225.html y en una respuesta al mismo.
A menudo, es útil compilar un sistema LFS para una máquina en otra. Supongamos que utilizamos un rápido procesador Athlon de 1GHz para construir e instalar un sistema para un antiguo 486. A pesar de que, técnicamente, eso no es compilación cruzada, los programas compilados para un Athlon no pueden ejecutarse en un 486. Esto es debido a que los programas compilados para el procesador más moderno usan características que el más antiguo no tiene. Para conseguir que el sistema más moderno compile para el más antiguo, sigue las instrucciones del consejo http://hints.linuxfromscratch.org/hints/crosscompiling-x86.txt.
Hay unas cuantas cosas que no requieren mucho conocimiento de C y que tu puedes hacer para conseguir que compile un código fuente antiguo en un sistema reciente.
Si estás usando GCC 3, intenta añadir la opción -std=gnu89 (por ejemplo, en CFLAGS o CC. La forma exacta de hacerlo está fuera del alcance de estas FAQ).
Me alegra que lo preguntes ;) En el Reino Unido, Ian Molton ejecuta un servidor de Quake para usuarios de LFS. Aquí están los detalles:
Los jugadores necesitan la última versión liberada de Quake 3. A Febrero de 2003 es la versión 1.32b que puedes encontrar en ftp://ftp.idsoftware.com/idstuff/quake3/linux/linuxq3apoint-1.32b.x86.run
Los jugadores necesitan el fichero pak0.pk3 de la versión completa de Quake 3. Este está disponible en el CD de Quake 3 (incluso en la versión de MS Windows). Debes colocarlo en /usr/local/games/quake3/baseq3/ a menos que instales el Quake 3 en cualquier otro sitio.
También necesitan el programa utilizado en el servidor para añadir mapas, que pueden descargar de http://games.mnementh.co.uk/ y lo deben instalar en ~/.q3a/baseq3/ o donde han colocado el fichero pak0.pk3. Es totalmente necesario descargarse los mapas manualmente porque el servidor tiene deshabilitada la descarga automática.
Por la misma razón por la que está deshabilitada la descarga automática de mapas, por favor, no descargues nada de la web mientras se está jugando.
Aunque sólo se garantiza que el servidor se esté ejecutando cuando está prevista una partida, los jugadores pueden intentar conectarse cuando quieran.
Los juegos están planificados todas las semanas, los martes a las 20:00 UTC y los sábados a las 22:00 UTC. Ten en cuenta que las horas están en UTC.
Como el servidor es sólo para usuarios de LFS, e Ian quiere evitar el uso de claves, el nombre del servidor sólo lo encontrarás en los archivos del lfs-chat.
Si has creado una entrada al servidor en tus "favoritos" pero no lo ves, puede ser porque tienes desactivado "Show empty servers".
Tiene que ver con los caracteres usados para indicar el fin de línea.
Se pueden usar dos caracteres:
Line Feed (Avance de línea): (LF) Octal:012 Decimal:10 Hex:0A Carácter de escape estilo C:'\n' Avanza una línea hacia abajo.
Carriage Return (Retorno de carro): (CR) Octal:015 Decimal:13 Hex:0D Carácter de escape estilo C :'\r' Avanza al margen izquierdo.
Unix, DOS y MacOS utilizan diferentes combinaciones para indicar el fin de línea en ficheros de texto:
Unix: sólo LF. Esto es por lo que cuando un fichero de texto con formato Unix se envía a una impresora en modo directo, imprime
como
peldaños
de una escalera.
|
DOS: CR y LF. Que es por lo que si haces "cat -v" en un fichero DOS verás un "^M" (control m es el retorno de carro) al final de cada línea. Y es por lo que los guiones no funcionan cuando se escriben con el bloc de notas de Microsoft. El núcleo busca "/bin/sh^M", el cual no existe. Hay un "/bin/sh", pero ninguno con un "^M" al final.
MacOs: sólo CR. Las impresoras probablemente impriman cada línea encima de la primera, y las herramientas Unix pensarán que el fichero entero consta de una única linea que tiene intercalados carateres "^M".
Para cambiar de formato DOS a Unix, utiliza
cp <filename> <filename>.dos && cat <filename>.dos | tr -d '\r' > <filename> |
Aquí hay un ejemplo de cuando todo funciona:
tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr make make install cd .. rm -rf foo-0.0 |
Es importante borrar el código fuente al terminar. Los fuentes solo son útiles para reinstalar sin recompilar porque "make clean" y sus amigos no son confiables. Fíjate en el próximo ejemplo que hacer si fallan "./configure" o "make".
La única excepción al borrar los fuentes es el núcleo Linux. Casi todos conservan el árbol de los fuentes del núcleo para no tener que reconfigurarlo todo desde cero si sólo quieren hacer un pequeño cambio. Si se necesita una gran modificación, como cambiar el tipo de procesador, quizá sea necesario borrar y volver a desempaquetar los fuentes del núcleo.
Y aquí va un ejemplo por si algo falla (en este caso configure):
tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr . . . *** configure: error: foo requires libess 4.2 or greater please install libess and rerun configure. (*** configure: error: foo requiere libess 4.2 o superior) (por favor, instala libess y vuelve a ejecutar configure.) cd .. rm -rf foo-0.0 tar xvjf libess-4.2.tar.bz2 cd libess-4.2 ./configure --prefix=/usr make make install cd .. rm -rf libess-4.2 tar xvjf foo-0.0.tar.bz2 cd foo-0.0 ./configure --prefix=/usr make make install cd .. rm -rf foo-0.0 |
Nota del editor: El nombre de la librería ficticia libess viene siguiendo a libiberty (de glibc, hasta donde yo sé) y libofat. La razón de esto es la opción -l de gcc, para enlazar con una librería al momento de compilar. Por ejemplo,
gcc -o foo foo.c -lm |
gcc -o foo foo.c -liberty -lofat -less (gcc -o foo foo.c -libertad -bajoengrasa -menos) |
Puntos extra si captaste en el ejemplo la referencia a la "Guía del Autoestopista Galáctico" (The Hitchhiker's Guide to the Galaxy), de Douglas Adams.
No, pero mira en "¿Cómo compilo un paquete?" para más detalles, incluido una excepción a esta regla.
No es un fichero real. Existe en algunos espacios de nombres del kernel. (Y si, no eres el primera persona en pensar que los dispositivos de red deberían ser ficheros reales como todo el resto.)
El manejo de la energía es una función del núcleo (kernel), así que necesitas activarla en el núcleo. Al hacer "make menuconfig", en la sección "configuración general (General Setup)", busca "Soporte para el manejo de energía (Power Management Support)" y lee la ayuda.
Utiliza el programa useradd. Se instaló con el paquete shadow y tiene muchas opciones interesantes. Para más información, consulta la página de manual de useradd.
En pocas palabras, copiamos las cabeceras del núcleo en lugar de hacer enlaces a ellas porque esas cabeceras deberían corresponder con las de la librería libc que se esté ejecutando, no con las del núcleo que se utiliza.
Para econtrar la respuesta larga, mira aquí:
Un correo del mismo Linus: http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html.
Tráfico del Núcleo #80, 4. Enlaces simbólicos en el núcleo; Discusión sobre la interfaz Núcleo/Librería/etc: http://kt.zork.net/kernel-traffic/kt20000814_80.txt (Esto cubre el hilo en el que ocurrió el correo anterior.)
Respuesta corta: no.
Respuesta larga: probablemente, pero sólo para aquellas personas que han desarrollado el paquete que intentas compilar. Para la mayoría todo irá bien a menos que make finalice con un error.
Veamos un ejemplo:
sk ~/tmp $ cat > Makefile
main:
gcc main.c
sk ~/tmp $ cat > main.c
void main() { exit(0); }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: warning: return type of `main' is not `int'
sk ~/tmp $ ######## that worked ########
sk ~/tmp $
sk ~/tmp $ cat > main.c
int main() { exxit(0) }
sk ~/tmp $ make
gcc main.c
main.c: In function `main':
main.c:1: parse error before `}'
make: *** [main] Error 1
sk ~/tmp $ ######## that failed ########
sk ~/tmp $
|
Ejemplos de este error son:
/usr/bin/env: /static/bin/bash: No such file or directory gcc: No such file or directory |
Normalmente ocurre cuando intentas entrar (o justo después de entrar) en el entorno chroot en el Capítulo 6, y está causado por el intento de ejecutar en este punto un binario enlazado dinámicamente. Puedes comprobar como esta enlazado ejecutando file sobre el binario. Por ejemplo:
file $LFS/static/bin/bash |
La solución es volver al Capítulo 5, borrar y volver a extraer el código fuente si no lo has hecho todavía, y recompilar el paquete afectado. Y, esta vez, tener especial cuidado con las instrucciones para compilarlo estáticamente.
Si, cuando compilas XFree86, ghostscript, o cualquier otro paquete que utilice libpng, obtienes un error que incluya la siguiente línea:
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `deflate' |
tar --no-same-owner -xvjf libpng-1.2.5.tar.bz2 cd libpng-1.2.5 cat ../libpng-1.2.5-lz.patch | patch -p0 ln -s scripts/makefile.linux Makefile make ZLIBLIB=/lib ZLIBINC=/usr/include make ZLIBLIB=/lib ZLIBINC=/usr/include install cd .. rm -r libpng-1.2.5 |
7.2.1.2. bash: ./configure: No such file or directory
(bash: ./configure: No existe el fichero o el directorio)
Lee la siguiente entrada de la FAQ: "¿Cómo compilo un paquete?"
7.2.1.3. ./configure: bad interpreter: Permission denied (./configure: intérprete incorrecto: Permiso denegado)
Lo más probable es que aparezca este error mientras estás construyendo bash en el capítulo 5 del libro LFS. Y, posiblemente, el problema esté en las opciones de mount. Puede que tengas en el fichero /etc/fstab una línea como esta:
/dev/hda10 /mnt/lfs ext2 user 1 2 |
Por ello, cambia la línea del fichero /etc/fstab a algo como esto:
user Permite a un usuario ordinario montar el sistema de ficheros. Esta opción implica las opciones noexec, nosuid y nodev (a menos que se sustituyan por otras subsiguientes, como en la línea de opciones user,exec,dev,suid).
/dev/hda10 /mnt/lfs ext2 defaults 1 2 |
Los síntomas típicos se parecen a esto:
sk ~/tmp-0.0 $ ./configure creating cache ./config.cache checking host system type... configure: error: can not guess host type; you must specify one sk ~/tmp-0.0 $ |
Normalmente, el problema es que el guión no puede ejecutar el compilador. Posiblemente se deba a que falta el enlace simbólico /usr/bin/cc. Lo puedes arreglar de la siguiente manera:
cd /usr/bin ln -s gcc cc |
Si eso no lo arregla, comprueba el fichero config.log que crea configure. Los errores se listan allí y pueden indicar el problema.
Si obtienes del guión configure un error como:
checking whether we are using GNU C... no configure: error: GNU libc must be compiled using GNU CC |
comprobando si estamos utilizando GNU C... no configure: error: se debe compilar GNU libc utilizando GNU CC |
Para comprobar si egrep está funcionando antes de reinstalar el paquete grep del capítulo 6, ejecuta el siguiente comando desde fuera del entorno chroot:
file $LFS/bin/egrep |
Para comprobar si egrep está funcionando después de reinstalar el paquete grep del capítulo 6, ejecuta el siguiente comando dentro del entorno chroot:
egrep root /etc/passwd |
7.2.1.6. ¿Por qué el guión configure se cuelga en "checking for signed size_t type..." ("comprobando el signo del tipo size_t...")?
Has optimizado demasiado a gcc.
¿Se parece /dev/null a esto:
$ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Aug 3 2000 /dev/null |
Si parece correcto, el problema será seguramente con las opciones de mount. Mira la respuesta a "./configure: bad interpreter: Permission denied (./configure: intérprete incorrecto: Permiso denegado)", más arriba.
La respuesta larga está en http://www.bitwizard.nl/sig11/.
La respuesta corta es que si reiniciando las cosas van a peor, tienes un problema de hardware. (Si el comando make, o lo que estés ejecutando, falla siempre en el mismo sitio, entonces no se trata de un problema de hardware.)
Asumiendo que no has trucado el procesador, el problema de hardware más probable es una mala memoria, la cual puedes comprobar con Memtest86: http://www.memtest86.com/. Si no es esto, mira la respuesta larga.
7.2.1.9. Están apareciendo errores cuando intento construir un paquete que requiere GTK+, pero yo he instalado GTK+ 2.x.
GTK+ 2.x y 1.2.x no son compatibles. El paquete que intentas instalar puede que necesite GTK+ (y GLIB) 1.2.x. Puedes tener instalada la versión 1.2.x de GTK+ (y de GLIB) además de la version 2.x.
Los sintomas típicos son los siguientes:
$ echo -en 'x11:\n\tgcc x11.c\n' > Makefile
$ echo -en '#include <X11/Xlib.h>\nmain() { }\n' > x11.c
$ make
gcc x11.c
x11.c:1: X11/Xlib.h: No such file or directory
make: *** [x11] Error 1
$ rm Makefile x11.c
$
|
Crear un par de enlaces simbólicos solucionará el problema. Aquí están los comandos:
cd /usr ln -s X11R6 X11 cd include ln -s ../X11/include/X11 X11 |
Usar la última versión de cada paquete de Gnome no funciona. Debes usar las versiones que se conoce que funcionan entre sí.
Puedes encontrar un listadode las versiones en cuestión en http://ftp.gnome.org/pub/GNOME/desktop/, llega hasta la última versión (http://ftp.gnome.org/pub/GNOME/desktop/2.1/2.1.90/sources/ al momento de escribir esto), y usa las versiones que aparecen ahí.
Si obtienes un error sobre "conflicto de tipos para `gethostname'" (o "conflicting types for `gethostname'", en inglés) cuando compilas bash en el Capítulo 5, necesitas instalar el RPM glibc-static-devel. (Está en el tercer CD.)
7.2.2.2. "lex.l:429: `yytext_ptr' undeclared" ("lex.l:429: `yytext_ptr' no declarado") al compilar modutils
Si, al compilar modutils, obtienes esto:
/usr/bin/gcc -O2 -Wall -Wno-uninitialized -I. -I. -I./../include -D_GNU_SOURCE -DCONFIG_ROOT_CHECK_OFF=0 -c -o lex.o lex.c lex.l: In function `yylex': lex.l:429: `yytext_ptr' undeclared (first use in this function) lex.l:429: (Each undeclared identifier is reported only once lex.l:429: for each function it appears in.) make[1]: *** [lex.o] Error 1 lex.l: En la función `yylex': lex.l:429: `yytext_ptr' no declarado (primer uso en esta función) lex.l:429: (Cada identificador no declarado se reporta sólo lex.l:429: una vez por cada función en la que aparece.) make[1]: *** [lex.o] Error 1 |
Si, cuando compilas XFree86, obtienes:
make[3]: Entering directory `/usr/src/xc/programs/xcursorgen' rm -f xcursorgen gcc -m32 -o xcursorgen -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -L../../exports/lib xcursorgen.o -lXcursor -lXext -lX11 -lpng -lm -Wl,-rpath-link,../../exports/lib /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `deflate' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `inflate' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `inflateInit_' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `crc32' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `deflateInit2_' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `inflateReset' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `deflateReset' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `inflateEnd' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/../../../libpng.so: undefined reference to `deflateEnd' collect2: ld returned 1 exit status make[3]: *** [xcursorgen] Error 1 make[3]: Leaving directory `/usr/src/xc/programs/xcursorgen' make[2]: *** [install] Error 2 make[2]: Leaving directory `/usr/src/xc/programs' make[1]: *** [install] Error 2 make[1]: Leaving directory `/usr/src/xc' make: *** [install] Error 2 |
7.2.2.4. Glibc falla con ". . . . it is normal to compile GNU libc with the `linuxthreads' add-on. . . ." (.... es normal compilar libc GNU con el añadido de 'linuxthreads'...)
El error exacto es como este:
*** On GNU/Linux systems it is normal to compile GNU libc with the *** `linuxthreads' add-on. Without that, the library will be *** incompatible with normal GNU/Linux systems. *** If you really mean to not use this add-on, run configure again *** using the extra parameter `--disable-sanity-checks'. |
Se debe a que no has desempaquetado glibc-linuxthreads-X.X.X.tar.bz2 en el directorio glibc-X.X.X. Desempaquetalo ahí y estará solucionado.
Falta un fichero de dispositivo (hasta donde sabemos, /dev/null, pero podría ser /dev/zero). De todas formas, puede ser que se te olvidó ejecutar MAKEDEV, que MAKEDEV falló o que estás utilizando devfs y te olvidaste de hacer mount --bind a $LFS.
Normalmente cuando falla MAKEDEV todos los nombres de los ficheros de los dispositivos terminan con un "-". Hasta donde sabemos, esto ocurre cuando se ejecuta MAKEDEV sin haber montado $LFS/proc.
Los ficheros de dispositivos deben estar exactamente de esta manera:
sk@bubook:~ $ ls -l /dev/{null,zero}
crw-rw-rw- 1 root root 1, 3 Dec 31 1969 /dev/null
crw-rw-rw- 1 root root 1, 5 Dec 31 1969 /dev/zero
sk@bubook:~ $ |
Si compilando GCC en el Capitulo 5 aparece el error
Error: Unknown pseudo-op: `.hidden' |
Se debería mencionar que glibc (y gcc y binutils) son buenos sitios para NO optimizar. La relación rendimiento contra estabilidad es inusualmente pobre para estos paquetes. Pero...
Si has especificado un valor para la variable CFLAGS como "-march=i686 -mcpu=686" y estás obteniendo un error como éste:
spinlock.c: In function `__pthread_lock': spinlock.c:107: inconsistent operand constraints in an `asm' make[2]: *** [/usr/src/glibc-build/linuxthreads/spinlock.o] Error 1 make[2]: Leaving directory `/usr/src/glibc-2.2.4/linuxthreads' make[1]: *** [linuxthreads/others] Error 2 make[1]: Leaving directory `/usr/src/glibc-2.2.4' make: *** [all] Error 2 |
# Default flags to pass the C compiler. ifndef default_cflags ifeq ($(release),stable) default_cflags := -g -O2 else default_cflags := -g -O endif endif |
# Default flags to pass the C compiler. ifndef default_cflags ifeq ($(release),stable) default_cflags := -g0 -Os -march=i386 -mcpu=i386 -pipe else default_cflags := -g -O endif endif |
7.2.2.8. Glibc falla con "cannot determine asm global directive" ("no puedo determinar la directiva blobal asm").
El error, "configure: error: cannot determine asm global directive", mientras se configura glibc indica un problema con la instalación de binutils. Posiblemente no esté enlazado estáticamente. (Puedes comprobarlo con "file $LFS/static/bin/as".) En cualquier caso, prueba a reinstalar binutils.
Si la compilación e instalación de la glibc falla con un error como este:
'BEGIN { subdirs = ""; inhibit = "" }; \
^# { next }; \
^[^-] { subdirs = subdirs " " $0 }; \
^- { inhibit = inhibit " " substr($0, 2) }; \
END { printf "sysdep-subdirs =%s\n", subdirs; \
printf "sysdep-inhibit-subdirs =%s\n", inhibit; \
print "sysd-dirs-done = t" }' \
/dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs >
/usr/src/glibc-build/sysd-dirs-tmp
/bin/sh: line 1: BEGIN { subdirs = ""; inhibit = "" };
^# { next };
^[^-] { subdirs = subdirs " " $0 }; ^- { inhibit =
inhibit " " substr($0, 2) }; END
|
7.2.2.10. Glibc falla con "ld.map: No such file or directory" (ld.map: no existe el fichero o directorio).
No tienes /dev/null. O bien olvidaste crearlo cuando se menciona en las instrucciones de constrcción de glibc, o usas devfs y olvidaste ejecutar "mount --bind /dev $LFS/dev" antes de entrar en el entorno chroot. Tambien debes borrar o regenerar los directorios glibc-N.N.N y glibc-build despues de solucionar esto.
7.2.2.11. La construcción estática de sh-utils falla con el mensaje "undefined reference to `getloadavg'" ("referencia no definida a 'getloadavg'").
Estás intentando construir la versión estática de sh-utils y obtienes un error como este:
gcc -g -O2 -static -o uptime uptime.o ../lib/libsu.a -lutil uptime.o: In function `print_uptime': /lfs/tmp/sh-utils-2.0/src/uptime.c:125: undefined reference to `getloadavg' collect2: ld returned 1 exit status make[2]: *** [uptime] Error 1 make[2]: Leaving directory `/lfs/tmp/sh-utils-2.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/lfs/tmp/sh-utils-2.0' make: *** [all-recursive-am] Error 2 uptime.o: En la función `print_uptime': /lfs/tmp/sh-utils-2.0/src/uptime.c:125: referencia no definida a `getloadavg' collect2: ld devolvió un estado de salida 1 make[2]: *** [uptime] Error 1 make[2]: Abandonando el directorio `/lfs/tmp/sh-utils-2.0/src' make[1]: *** [all-recursive] Error 1 make[1]: Abandonando el directorio `/lfs/tmp/sh-utils-2.0' make: *** [all-recursive-am] Error 2 |
http://archive.linuxfromscratch.org/mail-archives/blfs-support/2001/06/0507.html: Esto intenta corregir el fichero config.h generado incorrectamente y debería ser la solución correcta, si puedes conseguir que funcione siguiendo la descripción dada en el mensaje.
Si eso no funciona, borra las fuentes, extráelas de nuevo e intenta esto: http://archive.linuxfromscratch.org/mail-archives/blfs-support/2001/06/0495.html. Esto evita compilar uptime ya que no será necesario en el entorno chroot, y compilar uptime dinámicamente dentro del entorno chroot no es problema.
Por alguna razón, los parches de GNU no suelen funcionar. Mejor descarga el archivo completo e inténtalo de nuevo, o prueba la solución que se explica en el mensaje archivado en http://archive.linuxfromscratch.org/mail-archives/lfs-dev/2002/06/0386.html.
Si aparecen errores y tienes establecido CFLAGS y otra forma de pasarle las opciones de optimización al compilador, este puede ser el problema.
Si preguntas en la lista y no saben cual puede ser la solución, inmediatamente te sugerirán que lo intentes sin optimizaciones, de modo que es mejor que intentes eso primero antes de preguntar. Estarás un paso por delante de ellos :)
Una advertencia en particular es que la optimización de binutils, gcc o glibc puede causar que otros paquetes fallen al compilar, al ejecutarse, o que se comporten de forma estraña y misteriosa. Igualmente, las optimizaciones que funcionan para alguien puede que no funcionen para tí. Los opciones que se usan en el libro pueden dejar de funcionar misteriosamente. Incluso un inofensivo ligero cambio del hardware puede crear la diferencia
(Si no sabes qué son las opciones de optimización, no te preocupes, en realidad no las necesitas).
Si aparecen errores y estás usando una versión de un paquete diferente a la del libro (más nueva o más vieja), inténtalo con la versión del libro. Algunas veces hay razones por las cuales el libro utiliza una versión determinada. Busca en los archivos de la lista si tienes curiosidad.
Sí, pero mira en "¿Cómo compilo un paquete?" para más detalles, incluyendo una excepción a esta regla.
Cuando compilaste net-tools añadiste soporte para una familia de protocolos y no añadiste soporte en el núcleo (probablemente aceptaste las respuestas por defecto).
La lista completa de protocolos está en /usr/include/linux/socket.h, pero aqui están los posibles culpables:
net-pf-3: Radio Amater AX.25 (AF_AX25)
net-pf-4: Novell IPX (AF_IPX)
net-pf-5: AppleTalk DDP (AF_APPLETALK)
net-pf-6: Radio Amater NET/ROM (AF_NETROM)
net-pf-9: Reservado para el proyecto X.25 (AF_X25)
Naturalmente la solución es recompilar net-tools sin soporte para las cosas que no necesitas (o recompila tu núcleo con soporte si encuentras que las necesitas). La solución rápida es añadir una línea como la siguiente al fichero /etc/modules.conf
alias net-pf-? off |
Sustituye el símbolo de interrogación por el número correcto, por supuesto. Y ejecuta de nuevo depmod.
Si aparece un error en net-pf-7 probablemente necesites añadir soporte para el dispositivo de red loopback (no el dispositivo de bloques) en el núcleo. O puedes añadir la siguiente línea en /etc/modules.conf y ejecutar de nuevo depmod.
alias net-pf-7 loop |
7.3.2. modprobe: Can't locate module char-major-10-135 (modprobe: No puedo localizar el módulo char-major-10-135)
"char-major-10-135" se refiere a un dispositivo de caracteres, número mayor 10, número menor 135, que corresponde al dispositivo /dev/rtc. Este dispositivo permite el acceso al reloj de la BIOS, o RTC (Real Time Clock), el Reloj de Tiempo Real. Lee /usr/src/linux/Documentation/rtc.txt para más información.
El error se debe a que algo, lo más probable es que sea hwclock, está intentando utilizar /dev/rtc pero no tienes configurado su soporte en tu núcleo. Puedes, o borrar /dev/rtc para que hwclock no intente utilizarlo, o activar el soporte de RTC en tu núcleo. Puedes encontrar esta opción en make menuconfig bajo el título "Dispositivos de Caracteres" -> "Soporte de Reloj en Tiempo Real Avanzado". ("Character devices" -> "Enhanced Real Time Clock Support").
7.3.4. Kernel panic: VFS: unable to mount root fs (Pánico en el núcleo: VFS: incapaz de montar el sistema de archivos raíz)
Puede haber varias razones por las que el núcleo no puede montar el sistema de archivos raíz.
¿Especificaste la partición correcta en /etc/lilo.conf?
¿Te acordaste de ejecutar lilo después de cambiar /etc/lilo.conf?
¿Está el soporte para el disco duro activado en el núcleo? Para dispositivos SCSI significa tener activado el soporte para el adaptador SCSI específico.
¿Está el soporte para el disco duro compilado dentro del núcleo, no cómo un módulo? (Los módulos se guardan en el sistema de ficheros. Si se necesita un driver para acceder al sistema de ficheros y ese driver está guardado como un módulo en ese mismo sistema de ficheros, bueno... ya sabes... ;)
¿Está el soporte para el sistema de ficheros compilado dentro del núcleo? De nuevo, no como un módulo. El soporte para ext2 está activado por defecto, pero otros como ext3, reiser, jfs y xfs no lo están.
Cuando veas, en tus syslogs, esta línea:
init: Id "1" respawning too fast: disabled for 5 minutes |
La documentación de LILO muestra todos los posibles errores (como cuando muestra "LI" y se para), pero puedes ver una introduccion rápida en: http://sdb.suse.de/sdb/en/html/kgw_lilo_errmsg.html.
Necesitas instalar el paquete net-tools. (Mira las instrucciones en el libro LFS.)
El comando hostname que tu sistema está usando pertenece a sh-utils y no soporta la opción -f. Cuando se le invoca con la opción -f asume que el nombre del sistema debe establecerse como "-f". El comando hostname de net-tools no tiene este problema.
Porque las variables de entorno LANG y LC_ALL no tienen ningún valor asignado. Para solucionar esto, asígnales un valor en los ficheros ~/.bash_profile y ~/.bashrc de cada usuario o en el fichero /etc/profile, añadiendo las siguientes lineas:
export LANG=en_US export LC_ALL=POSIX |
Se pueden añadir esas lineas al fichero /etc/profile con los siguientes comandos:
echo -e 'export LANG=en_US\nexport LC_ALL=POSIX' >> /etc/profile |
Si no utilizas el ingles estadounidense tendrás que cambiar la parte que pone "en_US" y posiblemente los valores de varias variables LC_* también. La ejecución del comando locale lista alguna (¿todas?) las variables LC_*.