Cómo arrancar Ubuntu en un iBook G4 (PowerPC) desde un USB (2ª parte)

Tras la decepción inicial, y a pesar de que no todo se puede considerar tiempo perdido ya que algo he aprendido sobre el OpenFirmware y como arranca el Mac, he creido que era necesario no desistir y tratar de conseguir el objetivo: tener una distribución de Ubuntu instalada en un USB para reutilizar mi portátil y darle una segunda vida (pero sin eliminar de momento la instalación de OSX)

Buscando, buscando, encuentro un foro donde indican que, en lugar de volcar la imagen en la primera partición se haga directamente en el dispositivo, es decir:

sudo dd if=fichero-imagen.iso of=/dev/disk2      
     # en lugar de /dev/disk2s1

Una vez termina, vuelvo a probar y LA COSA CAMBIA!!! Empieza a cargar algo, la pantalla se vacia y un par de segundos después vuelvo a la consola de OpenFirmware pero con el siguiente mensaje:

Can’t OPEN: cd:\install\yaboot

Algo es algo, parece que he dado un paso adelante… sólo falta llegar al yaboot

 

Cómo arrancar Ubuntu en un iBook G4 (PowerPC) desde un USB

He tratado de instalarme nuevos navegadores en mi iBook G4 (si, ya sé que es toda una reliquia, pero me funciona perfectamente para lo que lo necesito, o al menos hasta hace poco así era) para probar algunas de las novedades de HTML5 y CSS3, pero todo ha sido en valde… No puedo actualizar Opera (necesito OSX 10.5), no puedo actualizar Firefox (ahora tengo la 3.6.15, me pide también OSX 10.5 para pasar a la siguiente), no puedo actualizar Safari (sigo con la 4.1 y el impedimento es el mismo), no puedo por supuesto instalarme un InternetExplorer (por razones evidentes) y no puedo instalarme ninguna versión de Chrome (también necesita la 10.5)

Tampoco he podido en algunas ocasiones instalar otra aplicaciones de escritorio por el mismo motivo, aunque en realidad es porque en la versión 10.5 se incluye el JavaVM 1.6 (que no está disponible oficialmente para Tiger)

Sin embargo, y viendo que el problema era la versión de Java pensé que tal vez había una esperanza… y buscando, buscando encontré un port de Java para Tiger (soylatte), que incluso se puede compilar (porque la que ofrece el desarrollador es para intel). Y si! Se puede instalar y tengo el ejecutable de java, pero no el Framework (al menos no organizado al “estilo MacOS”) y por tanto las aplicaciones se siguen quejando de lo mismo (aunque en la consola me diga: java version “1.6.0_03-p3″)

Ya casi me había rendido cuando se me ocurrió…. ¿¿¿ Y si me descargo un ubuntu en un pendrive y arranco desde el usb??? debería ser posible… pues manos a la obra!!

 

Ubuntu también puede fallar!!

La verdad es que últimamente no había posteado nada aquí porque desde que uso Ubuntu me va todo bastante bien. Pocos problemas de configuración, y pocas cosas reseñables fuera del entorno gráfico (últimamente uso la consola bastante poco, para acceder a servidores remotos y poco más).

Aún así, nada en esta vida es perfecto, e incluso Ubuntu puede fallar si lo apagas de cualquier manera.

La semana pasada, durante una presentación, y con el navegador a pantalla completa, se me quedó bloqueado el “maravilloso” firefox. Imposible recuperar su tamaño normal ni interactuar de ningún modo para cerrar la dichosa ventanita (también el hecho de tener en ese momento de un teclado reducido me impedía acceder a combinaciones de teclas que hubieran podido salvarme en ese momento). Pero de cualquier modo, y puesto que la situación necesitaba de una solución urgente, reinicié y arranqué un portátil que siempre está disponible para estos casos como solución auxiliar (y que por cierto, salvó el honor).

En cualquier caso, al reiniciar, aparecía el “fantástico” menú del grub. Al seleccionar la primera opción y arrancar… nada! o peor: la consola de shell con un sistema initramfs montado!! Aparecía en el log de arranque (bastante atrás, me costó encontrarlo), una linea en la que decía que el disco principal no podía ser montado porque necesitaba un check del disco y no podía usarse. Muy bien, entonces escribo: fsck /dev/sda ……     ¡¡PERO EN ESTA SHELL NO HAY COMANDOS DE CHECK DE DISCO!!! ¡¡¡PARA QUE NARICES ME SIRVE LA SHELL!!! La lista de comandos que muestra la ayuda es tan ridícula que con ella no se puede hacer nada. Se me ocurren dos cosas:

1. Indicar con un mensaje CLARO al final del log, justo antes de saltar a esa dichosa consola, PORQUÉ no arrancas. (esto es más que fácil, de hecho es la causa por la que para)
2. Incluir en esta imagen de memoria herramientas mínimas para poder corregir el problema (hay cantidad de distribuciones de Linux muy pequeñas, así que no será por espacio)

Pero en fin, visto que no podía arreglar el problema, me fui a internet (en otro pc, obviamente) y buscando y rebuscando (que tampoco entiendo que me costase tanto, porque este problema debe ser común) entre páginas de tíos que daban soluciones del estilo:

“edita el menú de grub para cambiar el UUID del disco por algo del estilo /dev/sdXX, hazlo con el comando sudo gedit /boot/grub/menu.lst“ (… sudo gedit??? en ese punto, cerraba esa página y a seguir buscando),

al final encontré un blog (del que ahora no recuerdo la dirección, así q no puedo enlazarlo, lo siento!) donde tras un discurso de desesperación parecido a este, hablaba de que había usado una distribución Live llamada RESCATUX que esperaba que le arreglase el problema. Decidí probar, no tenía nada que perder antes de tener que reinstalar.

Bajé la iso, la quemé en un CD, y arranqué con la esperanza de poder recuperar el pc “atascado”. Al iniciar, arrancó el escritorio (una Debian con Gnome… bien!  ) con una aplicación abierta con 3 opciones:

1. recuperar el menú grub en el mbr
2. actualizar el grub
3. chequear el disco
4. salir a la shell

La última, evidentemente, no me servía. Probé a chequear el disco, me daba a elegir el disco /dev/sda y luego nada. Así que opté por la primera, que me pidió donde restaurarlo y una vez seleccionada detectó que esa partición estaba pendiente de chequeo. Inició el chequeo, instaló el grub en su sitio y volvió a esa pantalla. Pues… listo, no? Reinicio, saco el CD y… al arrancar de nuevo, TODO PERFECTO!!!

Fantástico!!! Tengo ese CD guardado como oro en paño Ubuntu es genial… para cuando falla, hay otras distribuciones que te pueden salvar la vida

 

¿¿¿ Qué narices es eso de la consola ???

Este post está dirigido a todos aquellos que, viniendo de mundos Windows o Mac, se sienten un poco perdidos a la hora de saber como usar los comandos que encuentran cuando buscan ayuda googleando y encuentran páginas o foros donde explican cómo hacerlo pero para ello indican extrañas líneas de instrucciones llenas de acrónimos y símbolos que no se entienden si no sabes qué narices es eso.

Generalmente, cuando alguien busca ayuda de como hacer esto o aquello en un entorno windows o mac, las instrucciones incluyen algún pantallazo (para ver la ventana que te sale) en la que se indica resaltado de algún modo el botón o check de opción que se debe marcar o pulsar. Y las instrucciones son del estilo de: pincha en “esto” y te saldrá esta ventana, pulsa en la pestaña “tal-y-cual”, y similares…

En cualquier distribución Linux (y a partir de ahora, me voy a enfocar en Ubuntu que será la que más probablemente tenga un recién llegado), lo que se puede hacer gráficamente viene “limitado” por las herramientas gráficas de que disponga la distribución (vamos, los programas instalados más los disponibles en los servidores de Ubuntu y que podemos instalar desde el “Gestor de paquetes Synaptic”). Cada uno de los programas que vemos como ventanitas gráficas, en realidad se traducen en uno o más procesos sobre el sistema operativo, y corresponde a la ejecución de un fichero (la aplicación) cuya interacción con nosotros es gráfica para permitir un control más sencillo de utilizar. Pero no necesariamente todo fichero ejecutable tiene porque tener una respuesta gráfica o visual, puede ser que simplemente permita ser “llamado”, ejecute su proceso y muestre un resultado final.

Pues bien, las aplicaciones ejecutables normalmente se abren con un doble-click sobre su icono desde el entorno gráfico. Esto en realidad no es más que una simplificación de lo que en realidad significa, que es llamar a ese fichero y ponerlo en ejecución. Y para eso no es imprescindible un entorno gráfico. Aquí es donde entra en juego la consola (o terminal) de comandos.

La consola de comandos (o terminal) no es más que otra aplicación (en Ubuntu: Aplicaciones > Accesorios > Terminal) que abre una nueva sesión de nuestro mismo usuario (es decir, que estamos conectados 2 veces a nuestro ordenador) en la que, en lugar del navegador de ficheros, tenemos un intérprete de comandos que espera ordenes textuales. Aquí es donde podremos ejecutar nuestros comandos (o los que indiquen como instrucciones en la página de ayuda que hayamos encontrado).

Existen infinidad de comandos disponibles comunes a todas las distribuciones (comandos GNU) y algunos específicos de la distribución que usemos (hay un pequeño tutorial en esta página del blog) que permiten un control mucho más directo y amplio sobre la máquina de lo que permiten los programas gráficos. Todos tienen la misma estructura:

<comando> <opciones>

El “comando” puede ser un comando interno del intérprete de comandos (hay una lista si escribís el comando “help”) o un fichero ejecutable (en este caso, puede ser sólo el nombre del fichero o la ubicación completa indicando los directorios donde está, algo así como: /usr/bin/lo_que_sea ).

Las “opciones” dependen totalmente del comando, cada uno tiene las suyas. Pero hay una serie de convenciones en todos los comandos GNU. De modo sencillo, las opciones se dividen en “modificadores” o “acciones” y “ficheros a los que aplica”. Los modificadores tienen la forma de un guión seguido de una letra (cuando hay varios, típicamente se agrupan en un sólo guión) o un doble guión seguido de un texto descriptivo de la acción. Generalmente suele existir la opción “-h” o “–help” para ver la sintaxis disponible del comando. Los ficheros pueden ser opcionales, dependerá de si la opción es aplicable a ficheros o no, pero de estar se debe indicar el nombre (o ubicación) del / los ficheros.

Si te fijas, verás que esto permite hacer muchísimo más que el entorno gráfico. Por ejemplo:

• rm  -Rf  /users  /home  /var =>    esto “borra” (rm) “recursivamente” (-R) y “forzadamente” (-f) las carpetas indicadas y su contenido (por lo de recursivo), las dos primeras suelen contener la carpeta del usuario (junto con el escritorio y la configuración gráfica) y la última contiene datos de trabajo de las aplicaciones (logs del sistema, cola de impresión, bases de datos, información de los paquetes instalados,  …). Vamos, que te cargas el sistema enterito.
• ren  jpeg  jpg  – /users/* => esto “renombra” (ren) cambiando el texto “jpeg” por el texto “jpg” en el nombre de todos los ficheros que hay en “/users” (hacer esto desde el entorno gráfico nos obligaria a cambiar una por una todas las imágenes)
• ls  -l  /users  /home  /var => esto “lista” (ls) en formato “largo” (-l) el contenido de las carpetas indicadas (sí, las 3 a la vez, una después de otra)
• man  ls => muestra el “manual” (man) del comando “ls” (sí, afortunadamente hay un manual para prácticamente todos los comandos disponibles)
• ….etc…

Sólo hay un par de cosas que se deben entender de este nuevo entorno:

• siempre estamos ubicados en un directorio (=carpeta) concreto, y los comandos que ejecutemos lo harán sobre ese directorio a menos que se indique lo contrario. (podemos saber donde estamos con el comando “pwd”)
• los comandos “sudo” y “su” permiten ejecutar lo que sea como si fueramos el superusuario (evidentemenete, nos pedirá la contraseña para verificar nuestra identidad), así que ojo con copiar y pegar aquí cualquier comando sacado de por ahí que empiece por ese prefijo

Espero que esto le sirva de algo a alguien.

 

Anatomia de… el sistema de ficheros de Linux

[Traducido del artículo original de M.Tim Jones del 30 de octubre de 2007 para IBM]

Una revisión por capas basada en la estructura

Cuando se trata de sistemas de ficheros, Linux® es la navaja suiza de los sistemas operativos. Linux soporta un gran número de sistemas de ficheros, desde sistemas con diario (journaling) a clustering o criptográficos. Linux es una maravillosa plataforma para usar sistemas de ficheros estándar o los más exóticos, e incluso para el desarrollo de sistemas de ficheros. Este artículo explora el sistema de ficheros virtual (VFS por sus siglas en inglés) —algunas veces llamado el sistema de ficheros conmutador (switch) — en el kernel de Linux y después revisa algunas de las principales  estructuras que mantienen los sistemas de ficheros unidos.

 

Ubuntu y las impresoras

Haca tiempo que no escribía nada, ya que últimamente estoy trabajando bastante con equipos que usan Ubuntu y la verdad es que los problemas son mínimos y la gente que los usa estan encantados de la vida. Sin embargo, todavía hay algunas cosas que no funcionan tan simple como deberian, me estoy refiriendo por supuesto a ese gran “enemigo” de las distribuciones linux de escritorio: las impresoras.

Le pese a quien le pese, y lo diga quien lo diga, linux todavia no es un gran sistema de escritorio como lo pueden ser windows o mac, en ese sentido siguen ganando estos dos, ya que la sensación que tiene el usuario de poder controlar completamente su equipo y los recursos auxiliares de una manera relativamente sencilla es muy grande…

 

Que bonito es compartir, DAVid !! (1ª parte)

   Bueno, con este título seguramente no queda muy claro de que va esto, pero seguro que estás de acuerdo conmigo en lo bonito que es compartir, es algo que de pequeñitos nos enseñan que es mucho mejor que ser egoista y querer las cosas sólo para uno mismo. Y esa idea la hemos llevado al mundo interconectado de hoy en dia donde un ordenador no tiene sentido por si solo, si no tienes acceso al mundo exterior o a recursos compartidos con los demás, de que sirve. Pues de eso va todo esto, de como compartir teniendo en cuenta que todos somos diferentes pero no por ello deben tener unos preferencia sobre los otros.

   No estoy filosofando sobre la naturaleza humana aunque lo pueda parecer, sino sobre los diferentes sistemas operativos y protocolos de compartición de ficheros que existen hoy en dia y de como cada uno tiene sus propias preferencias por uno u otro protocolo a la hora de definir lo que es un recurso compartido (curiosamente cada uno considera que la forma “natural” de compartir es el protocolo propio de su plataforma). Lo ideal sería que, independientemente del sistema operativo que usemos, podamos tener acceso a los recursos de forma totalmente transparente y que luego se presenten en cada sitio adaptados a las condiciones especiales de cada uno. Ésta es la idea detrás del protocolo HTTP, pensado e ideado para compartir información en forma de documentos de texto facilmente accesibles desde cualquier navegador sobre cualquier plataforma: un documento en particular debería poder accederse y obtener el mismo resultado independientemente de la presentación final, pero en esencia el contenido será siempre el mismo.

   Si esto es algo natural para los documentos, ¿porqué no lo es para los ficheros?

 

Anatomía de… el asignador de losas de Linux

Empiezo con éste una serie de artículos, traducidos de los originales de M.Tim Jones (mtj@mtjones.com) y que se pueden encontrar en el servicio de documentación técnica de IBM. Algunos de ellos ya tienen algunos meses de antigüedad, lamentablemente los he descubierto recientemente a partir del último publicado, pero los voy a ir traduciendo en el orden cronológico de publicación intentando traducir uno cada semana.

Puesto que muchas veces la designación técnica de algunos elementos y algoritmos descritos en estos artículos suele ser la inglesa, sin que exista una traducción válida, adjuntaré a cada traducción literal que haga de estos conceptos el nombre original en inglés.

Y una vez expuestos estos dos puntos, empiezo con el cuerpo del artículo original.

 

Anatomía del asignador de losas (slab allocator) de Linux

[artículo original]

Un buen rendimiento del sistema operativo depende en parte de la habilidad del propio sistema para gestionar eficientemente los recursos. En los viejos tiempos, los gestores de pila (heap memory managers) eran la norma, pero el rendimiento se veia afectado por la fragmentación y la necesidad de reasignar memoria. Hoy, el núcleo de Linux® usa un método que fue originado en Solaris pero que ha sido usado en sistemas empotrados durante algún tiempo ya, asignando memoria como objetos basándose en su tamaño. Éste artículo explora las ideas tras el asignador de losas (slab allocator) y examina sus interfaces y sus usos.

 

Actualización automática de repositorios RPM

Probablemente una de las causas por las que el usuario medio ha encontrado Ubuntu como una distribución atractiva frente a otras más clásicas es, además de por una buena selección de aplicaciones sencillas, el sistema Debian de actualización de software: apt-get.

Para los que, como yo, venimos del mundo RedHat y funcionamos con sistemas que han heredado su gestión de paquetes RPM, quizá nos parece algo incontrolable el hecho como apt-get gestiona las descargas, ya que simplemente te instala todas las dependencias que te hagan falta y la última versión de todo. Esto en una instalación de usuario típica es fantástico, porque de una manera sencilla configuras las actualizaciones automáticas y siempre estás al día sin preocuparte de que necesitas y si tienes que quitar este o aquel paquete para poder poner el nuevo. Pero en un sistema de servidor no es tan trivial: cambiar la versión de una determinada libreria o aplicación puede hacer que otra, que depende exactamente de aquella, deje de funcionar sin razón aparente.

En ese sentido, el sistema RPM es mucho más selectivo y te permite un mayor control de lo que tienes instalado, y te permite incluso definir desde donde lo quieres instalar (del DVD original, de internet, de un disco en otro ordenador…). Esta es la gran ventaja, a mi modo de ver, del sistema RPM: no necesitas una conexión a internet en cada PC, y esto en una red local de una empresa puede ser el escenario.

De cualquier modo, y teniendo en cuenta la posibilidad que tiene RPM de usar repositorios definidos en algún sitio, podemos emular el funcionamiento de actualización automática de apt-get.

 

Breve manual de comandos básicos de consola

Existen una enorme cantidad de comandos de consola en el mundo *NIX, esto proporciona a éste entorno una potencia y flexibilidad increíbles pudiendo hacer absolutamente de todo y teniendo control absoluto sobre los procesos que lanzamos en nuestro sistema y sobre los ficheros que manejamos, así como sobre su contenido. Pero esta flexibilidad no es fácil de asimilar ni de controlar, y de hecho uno de los primeros problemas que se encuentra con el novato en el mundo Llinux suele ser un entorno hostil y extraño en el que debe dejar a un lado el ratón y tener en la memoria los comandos, ya que no hay iconos ni ayudas visuales, sólo una línea de comandos que espera pacientemente que se le diga qué debe hacer.

Se echa en falta en esos momentos un manual sencillo, no-completo (ya que una lista completa de todos los comandos GNU y de la shell que usemos es tan extensa que no sabríamos por donde empezar), y sobre todo centrada en lo esencial para poder empezar a movernos.

En ésta página voy a intentar formar una lista de comandos que puedan servir a cualquiera para empezar a moverse por la consola, evidentemente hay muchísimos más y seguramente me dejo alguno que alguien pueda pensar que es esencial. Pero creo que con éste listado se pueden realizar todas las funciones básicas del sistema, y aprender el resto sobre la marcha usando los manuales y la ayuda del sistema será sólo cuestión de tiempo y práctica, cosa que por otra parte resulta vital para moverse en éste entorno en el que debemos tener siempre buena memoria para recordar comandos, ubicaciones de ficheros, …

Se admiten todo tipo de correcciones y/o añadidos, que en todo caso podrían ir a parar a un listado de comandos avanzados. Espero que ésto pueda ser de utilidad a alguien.