Tengo un Toshiba T130-15K (650 €) y es lo mejor que ha pasado por mis manos. Hasta 11 horas según el famoso Mobile Mark™ 2007, lo que se traduce en unas 8 ó 9 reales, de uso normal sin wifi (con cable de red), y unas 6 ó 7 con wifi. Eso sí es movilidad. Es una pena que esté descatalogado y que Toshiba ya no haga portátiles con tanta duración (lo más que te aseguran son 9 horas).

También tengo un Sony VPCY22c5E, cuyas especificaciones eran de 7 horas, y dura 3 como máximo. Así no se puede trabajar. A mí me daría vergüenza llamar a ésto “portátil”.

Y las duraciones de los “ultrabooks” son más de lo mismo, por más de 1000 euros:

• El Acer Aspire S3 – hasta 6 horas (¡¡¡tienen el valor de decir que apagado dura hasta 50 días!!!)
• El Asus Zenbook – hasta 7 horas
• La serie Z de Sony (2250 euros), hasta 7 horas
• Lenovo U300S – hasta 8 horas
• Toshiba Portege Z830- hasta 8 horas

No hay palabras. Toshiba, ¿dónde quedaron las 11 horas con las que dotaste al T130-15k?

Todo esto me ha llevado a encontrarme en la situación de que se ha acabado el soporte de Canonical, con lo que han eliminado los paquetes de sus repositorios. Pues, como siempre, googleando un poco, he hallado la solución a mi problema. Resulta que Canonical mantiene en sus servidores una copia de las antiguas distros, pero en una url distinta (http://old-releases.ubuntu.com). Por tanto, basta con cambiar el fichero de fuentes de aptitude para que utilice ésta url. Para ello:

# cp /etc/apt/sources.list /etc/apt/sources.list.bak
# cat /etc/apt/sources.list.bak | sed s/es.archives/old-releases/ | \
 sed s/security./old-releases./ >/etc/apt/sources.list
# apt-get update

También me he fijado que no tienen todas las distribuciones, pues la última que mantienen es la 5.10, siendo la primera la 4.10. Por tanto, dejo en mi lista de @TODOs el descargarme todos los paquetes y ponerlos en el servidor web.

Investigando un poco me he encontrado con varios enlaces que sugerían diversas soluciones, ninguna de las cuales me ha servido. Sin embargo, si me han dado una pista de por donde empezar. El directorio /etc/pm/sleep.d/ contiene scripts que se ejecutan al suspender y restaurar el sistema, llevando a cabo las acciones necesarias, de forma parecida a los de System V. Además, en /usr/lib/pm/sleep.d/ hay otros tantos definidos que se también se ejecutan.

Ya puestos en situación, resulta que he descubierto (mediante el conocidísimo método informático ensayo-error) que es necesario “resetear” las interfaces de red para que funcione de forma adecuada el WOL, además de habilitarlo, pues se deshabilita en cada suspensión / apagado. Esto lo hago con el siguiente script que me he creado, y que he colocado en /etc/pm/sleep.d/10_wol:

#!/bin/bash

IFACE=eth0

resetif() {
 ifconfig $IFACE down
 ifconfig $IFACE up
 ethtool -s eth0 wol g
}

case "${1}" in
 suspend|hibernate)
 resetif
 ;;
 resume|thaw)
 resetif
 dhclient $IFACE
 ;;
esac

El inconveniente es que este script entra en conflicto con /usr/lib/pm/sleep.d/55NetworkManager; el susodicho para y restaura el NetworkManager de Ubuntu. Así que he borrado éste último para evitar que falle.

Por cierto, que también es necesario habilitar WOL tras reiniciar la máquina. Para ello basta con crear un script que lo haga en cada automáticamente, /etc/init.d/wol:

#!/bin/bash
#
# Enables Wake On LAN 

ethtool -s eth0 wol g 

Y habilitarlo para que se ejecute en cada inicio:

# update-rc.d wol defaults

Y con esto ya tenemos nuestro Wake On LAN funcional.


El tema que abordo hoy es de las isos híbridas; un formato de isos que se está popularizando últimamente en muchas de las distribuciones linux: supergrub lo usa, easy peasy también lo hace, igual que openSUSE, y ubuntu lo hará a partir de la versión 10.10.

Hace tiempo que me picaba la curiosidad por saber “cómo” se construyen estas ISOs híbridas para poder ser grabadas directamente en un pendrive. Investigando un poco, he descubierto una explicación bastante buena (aunque breve) en la wiki de easypeasy: el truco consiste en sustituir los primeros 512 bytes de la imagen, que en el formato ISO deben de ser ceros, por el “sector de arranque”  (MBR), lo que permite grabar la iso directamente en el pendrive (mediante dd) y poder arrancar el sistema.

Obviamente esto tiene dos consecuencias lógicas: que el sistema de ficheros que se graba en el pendrive es iso9660, que es de sólo lectura, y que, por tanto, para arrancar necesitamos que el cargador sea capaz de montar este sistema de ficheros (grub2 lo hace).

SSL o TSL nos permite cifrar la conexión con el servidor de forma que todo el intercambio de datos vaya cifrado. Es la opción más segura porque protege todo el flujo de datos. No obstante, el tema que a mí me preocupa es simplemente la transmisión en plano del par usuario / contraseña; suficiente en las aplicaciones en las que la información que se transmite no es altamente confidencial. Por tanto, en estas ocasiones, se puede utilizar ssl únicamente para dicha operación, dejando el resto de la sesión libre de cifrado, y así no cargar al cliente ni al servidor innecesariamente. Es por ejemplo el caso de Facebook, que únicamente cifra dicho envío (aunque también permite el uso completo de la aplicación sobre ssl). Gmail, sin embargo, utiliza por defecto ssl desde que accedes al formulario de login.

Me suena haber visto algún día de pasada un complemento para Firefox que te advertía de los logins que utilizan ssl y los que no, a modo de protección contra este issue. El caso es que con la salida de Firefox 4.0, y aprovechando un rato de tiempo libre que he tenido esta tarde, me he puesto a buscar dicho complemento, pero lo único que he encontrado han sido complementos que fuerzan el uso de ssl cuando está disponible (por ejemplo, forzarían facebook siempre sobre ssl). Lo más parecido a lo que buscaba que he encontrado, ha sido Secure or Not, que te permite identificar con un simple click de ratón los enlaces y formularios seguros (usan ssl) de la página en la que te encuentres. Desde luego, lo recomiendo 100%. Quizás otra tarde que tenga tiempo me dedique a desarrollar un complemento para firefox que haga lo que yo deseo…

Como anécdota, cabe decir que se ha refrescado mi interés por el tema, dado que actualmente me encuentro trabajando en un centro de eduación que utiliza Moodle como plataforma de enseñanza y, como era de esperar, no utilizan ssl en los logins. Pero este problema de seguridad se ve aún más agravado con el hecho de que existe una red wifi abierta, sin ningún tipo de protección, que permite a cualquiera que se siente en un banco en la puerta del centro obtener de manera gratuita cientos de contraseñas. Lo más triste de todo es que advertí a la dirección sobre este problema hace meses, y no lo han solucionado. Y peor aún, mi alumnos ya conocen este fallo, pues hemos visto ssl en clase y han sido lo bastante inteligentes como para atar cabos…

De todas formas, aunque ya sepa la solución a ese problema, no voy a volver a tenerlo, porque el que CentOS detecte los discos sata como /dev/hda tiene efectos colaterales. Yo ya había notado que CentOS iba muy lento, arrancando y funcionando, pero no había relacionado conceptos. El caso es que haciendo benchmarks con de discos para evaluar el rendimiento de Xen, detecté que la lectura / escritura era unas 10 veces más lenta de lo normal. Googleando encontré este HowTo en el que se explicaba que el problema de que el acceso a disco fuese muy lento era debido a que el DMA estaba desactivado. Los discos SATA no utilizan DMA, pero intuí que CentOS estaba detectando erróneamente los discos, probablemente debido a las características de emulación IDE de la placa base. Sólo tuve que buscar un poco más para encontrar la solución.

Para evitar que CentOS detecte erróneamente los discos SATA como PATA, sólo hay que pasarle al kernel el parámetro hda=noprobe para que haga correctamente la detección. También hay que indicarle que la partición raíz ahora es un sda y no un hda y, por último, actualizar el fichero /etc/fstab para cambiar los hda por sda. La línea en grub sería algo así:

module /boot/vmlinuz-2.6.18-8.1.4.el5xen ro root=/dev/sda2 hda=noprobe

Además, así evito el problema que tenía con que el grub 2 no cargaba CentOS, pues ya he detectado que el kernel panic estaba causado por culpa de que la línea de grub de Ubuntu ponía el root=/dev/sda2, mientras que CentOS esperaba root=/dev/hda2.

Fuente: http://www.linuxquestions.org/questions/linux-hardware-18/sda-drive-seen-as-hda-on-centos5-609483/

Por ejemplo, en el caso de estar tratando con el disco /dev/sda, si directamente formateamos el disco como ext3 con

mkfs.ext3 /dev/sda

podríamos montarlo mediante

mount -t ext3 /dev/sda /mnt

Sin embargo, si tiene una tabla de particiones, el sistema de ficheros lo crearíamos, por ejemplo en la partición 1, con

mkfs.ext3 /dev/sda1

y lo montaríamos mediante:

mount -t ext3 /dev/sda1 /mnt

El problema con asociar un fichero a un dispositivo de loop es que cuando creas una tabla de particiones sobre /dev/loop0, no se crea de forma automática el /dev/loop0p1, sino que hay que hacerlo a mano. Para ello, debemos usar la herramienta kpartx:

kpartx -a -v disco_virtual.img

Con esto se nos habrá creado el dispositivo que nos da acceso a la partición en /dev/mapper/loop0p1, con lo cual ya podemos formatearlo y montarlo tranquilamente:

mkfs.ext3 /dev/mapper/loop0p1
mount -t ext3 /dev/mapper/loop0p1 /mnt

Me ha servido un poco de ayuda lo siguiente: Pasar de xen a kvm

Parece ser que firefox 3 usa sqlite y realiza constantemente fsync para mantener actualizada su base de datos en disco. Esto provoca que se congele en el eeepc, debido a que los discos SSD que lleva tienen ciertos problemas con las escrituras constantes de pocos datos.

El autor del post donde se analiza dicho problema, sugiere en este otro post crear una partición para firefox, pero yo he optado por utilizar un disco de ram, y así me ahorro el estar modificando las particiones. La idea es mantener en disco el directorio de firefox, llevarlo a ram para trabajar con él, y volver a volcarlo al disco cuando finalicemos.

Para ello, lo primero es añadir el punto de montaje del disco de ram al fichero /etc/fstab

none /mnt/ramdisk tmpfs defaults,size=200m 0 0

Si quieremos montar ya mismo el disco de ram, basta con ejecutar mount -a

A continuación, cambio el nombre del directorio de firefox por “firefoxram”, que será el que sirva de respaldo en disco.

mv /home/user/.mozilla/firefox /home/user/.mozilla/firefoxram

Ahora enlazo el directorio que realmente utiliza firefox con el disco de ram

ln -s /mnt/ramdisk /home/user/.mozilla/firefox

Tal y como está ahora mismo el sistema, cuando firefox se abra, creará su directorio en ram con los datos de navegación del usuario, pero al apagar el sistema, estos se perderán (porque sólo están en ram). Es por eso que necesitamos el directorio de respaldo en disco. Su finalidad es que se copie a ram antes de abrir firefox, y se vuelque a disco al cerrarlo. Para ello, vamos a cambiar el ejecutable /usr/bin/firefox por un script que realice dichas tareas:

mv /usr/bin/firefox /usr/bin/firefox-bin
touch /usr/bin/firefox
chmod +x /usr/bin/firefox

Ahora, editamos el script /usr/bin/firefox y añadimos las siguientes lineas:

#!/bin/bash

cp -r $HOME/.mozilla/firefoxram/* $HOME/.mozilla/firefox
firefox-bin
cp -r $HOME/.mozilla/firefox/* $HOME/.mozilla/firefoxram/

E voilá. Adiós a los cuelgues de firefox.

Mi primera idea fue no instalar gestor de arranque para CentOS, y utilizar el grub de Ubuntu en su lugar; así que hice un update-grub, y me detectó automáticamente la partición con CentOS. El problema fue que al arrancar, me daba el siguiente error

Error: Invalid magic number

Bastó un poco de investigación para comprobar que el error venía de que el núcleo que estoy instalando es para paravirtualización con Xen, y grub no sabe cómo arrancar este tipo de núcleos. Así que modifico la entrada del grub y pongo lo siguiente

multiboot /boot/xen.gz-2.6.18-194.el5
module 	  /boot/vmlinuz-2.6.18-194.el5xen root=/dev/hda6 ro quiet
moduel 	  /boot/initrd-2.6.18-194.el5xen.img

Pues sigue sin funcionar. Ahora me da el siguiente error:

PANIC on CPU0:
Could not setup DOM0 guest OS
Reboot in five seconds...

Parece ser que a CentOS no le caigo bien. Pero por mis c*j**es que lo hago funcionar. La siguiente opción que me queda es instalar el grub que trae CentOS en su partición de arranque y pasarle el control desde el grub de Ubuntu.

insmod ext2
chainload (hd0,6)+1

¡Bingo! Problema resuelto. Sólo me queda la espinita clavada de no saber por qué el grub 2 de Ubuntu no es capaz de arrancar CentOS.

¡¡¡ACTUALIZACIÓN!!!

¡Ya he descubierto el problema del Kernel Panic! Menos mal, porque odio no poder encontrar explicación de algún problema, cuando todos tienen la suya. El kernel panic estaba causado por culpa de que la línea de grub de Ubuntu ponía el root=/dev/sda2, mientras que CentOS esperaba root=/dev/hda2. Lo explico todo en este post.

Xsession: unable to launch "Lubuntu Netbook"

Parece ser que  para lanzar la versión netbook de lubuntu, el servidor gráfico busca el ejecutable llamado “Lubuntu-Netbook”, que no existe. Así que la solución ha sido crear un enlace simbólico al verdadero lanzador:

ln -s /usr/bin/startlubuntu-netbook /usr/bin/Lubuntu-Netbook

Respecto al sistema, estoy mucho más contento que con la rama principal de Ubuntu para netbooks. Es bastante más ligero y rápido. Lo único es que todavía no he conseguido configurar lxlauncher (el escritorio tipo netbook) para mostrar los iconos que yo quiero. He encontrado googleando que se configura en /usr/share/lxlauncher/, pero ese directorio no existe en mi sistema.