Warning: Fake initctl called, doing nothing

Este mensaje aparece al intentar instalar un paquete, en mi caso, openssh-server aunque también ocurre al intentar instalar otros servicios como myslqd. No crean los scripts de inicio y es, por tanto, imposible iniciarlos durante el arranque o posteriormente porque dichos scripts no han sido creados durante la instalación.

El mensaje se muestra al intentar instalar cualquier paquete que deba arrancar con upstart o initctl:

Warning: Fake initctl called, doing nothing

Se puede comprobar que ninguno de los servicios instalados tras este error está funcionando si hacemos:

$ service --status-all

y también:

$ initctl list

Por si aún no está claro que openssh-server no está funcionando, podemos comprobar que puertos están escuchando con:

$ netstat -nltp

Al parecer, el error se produce por una actualización que quedó incompleta. Después de revisar /var/log/apt/term.log , /var/log/dpkg.log no pude encontrar nada anómalo, apliqué la solución propuesta en este foro y se solucionó ejecutando estos dos comandos:

$ sudo mv /sbin/initctl /sbin/initctl.FAKE

$ sudo ln -s /sbin/initctl.REAL /sbin/initctl

y después limpiando la instalación del servicio que falla y reinstalando de nuevo, por ejemplo:

$ sudo apt-get purge openssh-server

$ sudo apt-get install --reinstall openssh-server

Ahora los scripts de inicio estarán disponibles y podrán ser ejecutados al iniciar el sistema.

Error 'Failed to fetch...' actualizando Ubuntu 11.04

Al intentar actualizar Ubuntu 11.04 con el gestor de actualizaciones, no se pueden descargar los paquetes a pesar de que hay conexión a Internet.

Aparece un recuadro con cada uno de los paquetes que no pueden ser descargados y la actualización se cancela. El error dice: "Failed to fetch http://...." y a continuación el sitio y nombre del paquete a descargar.

Para solucionarlo, simplemente pulsamos en el botón Configuración del Gestor de actualizaciones para elegir otro servidor desde el que descargar las actualizaciones.

Aquí se describe más detalladamente el procedimiento.

Velocidad de transferencia del disco duro

Para conocer la velocidad de transferencia del disco duro en Linux se puede utilizar el comando hdparm aunque también existen herramientas gráficas para comprobarlo.

Lo primero es conocer las características del disco instalado. Si nuestro disco está instalado como sda usamos el comando:

sudo lshw -C disk

Si el disco soporta SMART, la herramienta gráfica gsmartcontrol, instalable desde el Centro de software de Ubuntu proporciona información de los discos conectados y ofrece la posibilidad de ejecutar el algunos tests en busca de errores.

Los valores de los atributos que se muestran brindan una información muy interesante:

Finalmente, otra herramienta gráfica que ofrece información de los dispositivos de almacenamiento conectados es gnome-disk-utility. Se instalada desde el Centro de Software de Ubuntu y se ejecuta escribiendo palimpsest en una ventana del terminal.

Desde esta herramienta también podremos formatear un disco, comprobar el sistema de archivos, montar un volumen y realizar pruebas de rendimiento.

Se pueden realizar pruebas de rendimiento de lectura y de lectura/escritura. Al finalizar la prueba de lectura se muestra el resultado en una gráfica como esta:

Para ejecutar la prueba de lectura/escritura es necesario que la tabla de particiones esté completamente vacía.

Desde la consola también es posible realizar pruebas de rendimiento del disco. Utilizamos el comando hdparm pero para que los valores obtenidos sean fiables, debemos ejecutar el comando al menos tres veces.

El comando sería:

sudo hdparm -tT /dev/sda

El resultado también tiene en cuenta el rendimiento del procesador y la memoria pues las lecturas utilizan la caché y buffer del disco:

Para ejecutar la prueba tres veces, empleamos un bucle desde la consola:

Un factor a tener es cuenta es el tamaño del disco y el porcentaje de utilización. Para verlo, la mejor herramienta es el analizador de uso de disco o desde el terminal con el comando:

du -sx

Personalizar el escritorio de Ubuntu 11.10

La mayoría de las características para personalizar el escritorio en Ubuntu 11.10 funcionando en modo 2D no están disponibles desde el menú de configuración del sistema. El fondo de escritorio, el papel tapiz y la posibilidad de elegir entre unos pocos temas son las únicas opciones disponibles desde el menú Configuración del sistema->Apariencia.

De los temas que están instalados:

ls /usr/share/themes

solo están disponibles algunos de ellos: Radiance, Ambiance y HighContrast.

MyUnity ofrece muchas posibilidades de personalización aunque están limitadas si Ubuntu está funcionando en modo 2D. Aún así, permite elegir alguno de los otros temas instalados.

Para instalar esta herramienta, añadir el repositorio:

sudo add-apt-repository ppa:myunity/ppa

sudo apt-get update

sudo apt-get install myunity

Esto añade la herramienta MyUnity al menú de Configuración del sistema.

Al configurar algunos de los temas puede desaparecer el icono de control de sesión (logout, configuración del sistema, aplicaciones al inicio, ...)

Para volver a restaurar este icono, basta con lanzar desde una ventana del terminal la aplicación de configuración por defecto: gnome-control-center y reestablecer alguno de los temas que vienen por defecto en esta aplicación. El icono reaparecerá.

Otra herramienta muy útil que añade un panel inferior con muchos gadgets opcionales e instalables es AWN (Avant Window Navigator). Junto con Docky, ambas están disponibles para descargar desde el Centro de software de Ubuntu.

OpenXenManager /usr/bin/env python2 no existe el archivo o directorio

Después de descargar e instalar OpenXenManager, cuando lanzamos el ejecutable con ./openxenmanager se produce un error:

/usr/bin/env: python2: No existe el archivo o el directorio

Este error está provocado porque el ejecutable python2 que es llamado desde el script openxenmanager no existe en nuestra versión de Ubuntu pues ha podido ser reemplazado por una versión más reciente.

Para solucionarlo, basta con editar el script openxenmanager y sustituir la línea:

#!/bin/bash
/usr/bin/env python2 window.py

Por esta otra:

#!/bin/bash
/usr/bin/env python window.py

Recuerda que debes tener instaladas python-glade2 y python-gtk-vnc. En esta guía se explica como realizar la instalación paso a paso.

Los números primos y la temperatura del procesador

El objetivo de este ejercicio es comprobar como sometiendo el procesador a una sobrecarga de tareas hace que su temperatura aumente. Vamos a necesitar varias herramientas, la primera, un test de tortura que permita intensificar el trabajo del procesador. Uno de los más conocidos tests de tortura es prime95.

Este programa usa tu ordenador para calcular números primos y participar en un proyecto de computación distribuida para la búsqueda de números primos (GIMPS). Como procedimiento para someter al procesador a una intensa demanda en coma flotante es también interesante pues puede funcionar indefinidamente y, además, exige un constante acceso a la memoria. Debido a este fuerte stress, el consumo del procesador y, en general del ordenador, también aumenta.

Las restantes herramientas necesarias para el ejercicio lo son para la observación del fenómeno. En primer lugar, necesitaremos un amperímetro para comprobar el consumo o mejor aún, un medidor del consumo eléctrico que se puede comprar en Lidl por 10 euros o en Amazon por 20 euros.

Además, será necesario observar como aumenta el uso de la CPU con una herramienta gráfica fácil de entender como gnome-system-monitor, que muestra también el uso de la memoria y, por último, para vigilar la temperatura, podemos instalar lm-sensors y sensors-applet.

Este último permite añadir un applet a la barra que muestra lecturas de los sensores de temperatura con el intervalo que establezcamos. Si se quiere conocer la temperatura de forma puntual e instantánea se puede usar acpi -t desde la línea de comando.

En una ventana del terminal lanzamos prime95 y visualizamos en el monitor del sistema como el uso de la CPU y memoria se intensifican, al tiempo que observamos el aumento de la temperatura y del consumo eléctrico.

Fallo fuente de alimentación

Varias veces, cada vez con más frecuencia, al desconectar el cable de alimentación de mi HP SR1297ES y volverlo a conectar, la luz o led de la fuente de alimentación se queda parpadeando y el ordenador no arranca al pulsar el botón de encendido. El parpapedo o flash se acompaña de un sonido parecido al tick de un reloj.

Para conseguir arrancar el ordenador, tuve que desconectar la fuente de alimentación de la red, desconectar el conector P1 que va desde la fuente hasta la placa base, reconectar la fuente de alimentación a la red y mientras está conectada, volver a conectar P1.

Otras veces, desconectando el cable de alimentación que va desde la fuente a P1 de su conector ATX 20,  he puenteado PowerOK con un clip por la parte trasera del conector y cuando comienzan a girar los discos y el ventilador de la fuente, conectar el P1 a la placa base. Bastante arriesgado pero funciona. Cuando el ordenador haya encendido puedes desconectar el clip pero no lo pierdas, lo necesitarás la próxima vez.

Al parecer se debe a que la acumulación de polvo en la fuente de alimentación causa un cortocircuito que impide el arranque. Según he leído, se puede solucionar sin necesidad de comprar una fuente nueva con un simple secador de pelo usándolo para limpiar el interior de la fuente. Yo prefiero probar con un spray de aire comprimido.

No se muestran todos los interfaces de red

En una máquina virtual Ubuntu 11.10 Oneiric Ocelot con dos interfaces de red configurados como NAT (eth0) y Bridge(eth1), después de eliminar el interface de red en modo Bridge en VirtualBox, desparece de la máquina virtual Ubuntu y no muestran ni eth0 ni eth1, tan solo el interface local (lo).

Ejecutando:
# dmesg | grep eth0

se muestra:

[    2.874056] eth0: RTL8168d/8111d at 0xffffc90001874000, 08:00:27:02:ff:8f, XID 081000c0 IRQ 32
[    5.981326] udev: renamed network interface eth0 to eth1

y ejecutando:
# ifconfig -a

se muestra:

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:266 errors:0 dropped:0 overruns:0 frame:0
          TX packets:266 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:19124 (19.1 KB)  TX bytes:19124 (19.1 KB)

Se puede comprobar que el interfaz está realmente presente mediante:

# sudo lshw -C network

El archivo de configuración de dispositivos al inicio puede haberse modificado incorrectamente al cambiarse la configuración o eliminarse el adaptador de red en VirtualBox.

# cat /etc/udev/rules.d/70-persistent-net.rules

# This file maintains persistent names for network interfaces.

# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.


# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:02:ff:8f", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x10ec:0x8168 (r8169)

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:02:ff:8e", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

Si no muestra ningún dispositivo o muestra dos líneas, como en el ejemplo, debemos comprobar que la dirección MAC corresponde al interfaz eth* que realmente existe y eliminar cualquier otra entrada en el archivo. Si es así, hacer una copia de seguridad de este archivo de configuración y modificarlo para que muestre los dispositivos que realmente existen y su dirección MAC correcta asociados al interfaz eth correspondiente.

Después reiniciar:

# sudo init 6

Bluetooth falla en Oneiric Ocelot Ubuntu 11.04

Intentado enviar ficheros desde mi Nokia N97 a mi ordenador actualizado a la versión Oneiric Ocelot Ubuntu 11.10 desde Natty falla. Tampoco es posible examinar el dispositivo usando el adaptador Bluetooth aunque si que se detecta cuando se hace scan. Nada de esto ocurría en la anterior versión, Natty.

Si probamos desde el applet de gnome a examinar el dispositivo se monta en el sistema de ficheros el dispositivo pero al tratar de examinarlo con Nautilus se produce un error indicando que no ha podido ser montado.

No se pudo mostrar obex://[XX:XX:XX:XX:XX]Error: DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)Seleccione otro visor e inténtelo de nuevo.

Se puede verificar que efectivamente no está montado accediendo desde la consola al punto de montaje por defecto:

#ls ~/.gvfs/N97

Este comando mostrará que el directorio no está montado.

Lanzando el applet de gnome desde la consola con:

#bluetooth-applet

para poder ver los errores se obtiene en la consola:

Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

#hcitool scan
Scaning ...

detecta el dispositivo Bluetooth, en mi caso un Nokia N97.

#lsusb | grep -i bluetooth

Informa del adaptador Bluetooth conectado al puerto usb, en mi caso:

0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Parece tratarse de un fallo conocido y aún abierto. Después de buscar he probado con la solución provisional descrita y, al menos en mi caso, funciona:

Instalo obexfs con:

#sudo apt-get install obexfs

#sudo mount -t fuse "obexfs#-bXX:XX:XX:XX:XX:XX" /media/N97

donde XX:XX:XX:XX:XX:XX es la MAC de mi dispositivo.