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.
sábado, 24 de marzo de 2012
sábado, 18 de febrero de 2012
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.
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.
martes, 31 de enero de 2012
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"
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
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
lunes, 2 de enero de 2012
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.
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:
#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.
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.
miércoles, 14 de diciembre de 2011
Ubuntu 11.04 no se inicia en modo gráfico con drivers de NVIDIA
En Ubuntu 11.04 y después al pasar a Ubuntu 11.10 oneiric, después de muchas de las actualizaciones automáticas, no consigo que se inicie el modo gráfico y la pantalla se queda en negro. El único modo de acceder al sistema es mediante alguna de las consolas de texto [CTRL] + F2 por ejemplo.
Buscado información en los logs, se observa que no hay ningún error en /var/log/kern.log referido a los drivers de NVIDIA pero, sin embargo, en /var/log/Xorg.0.conf aparece un error indicando 'failed to load nvidia drivers'
Parece que esto ocurre cada vez que se actualiza el núcleo en algunas de las actualizaciones automáticas.
En mi caso, observando el fichero de actualizaciones: /var/log/dkpg.log veo que la versión anterior linux-image-2.6.38-10-generic 2.6.38-10.46 ha sido sustituida por linux-image-3.0.0.14-generic 3.0.0.14.23
Para volver a tener el entorno gráfico siempre he seguido el mismo procedimiento:
#sudo apt-get remove --purge nvidia-*
#sudo Xorg -configure
#sudo sh NVIDIA-Linux-x86-290.10.run
Obviamente, hay que sustituir el driver NVIDIA-Linux-x86-290.10.run por el que te hayas descargado de la página de NVIDIA
Si lo prefieres puedes descargarte previamente la última versión de los repositorios de Ubuntu usando:
#sudo apt-get install nvidia-current
Buscado información en los logs, se observa que no hay ningún error en /var/log/kern.log referido a los drivers de NVIDIA pero, sin embargo, en /var/log/Xorg.0.conf aparece un error indicando 'failed to load nvidia drivers'
Parece que esto ocurre cada vez que se actualiza el núcleo en algunas de las actualizaciones automáticas.
En mi caso, observando el fichero de actualizaciones: /var/log/dkpg.log veo que la versión anterior linux-image-2.6.38-10-generic 2.6.38-10.46 ha sido sustituida por linux-image-3.0.0.14-generic 3.0.0.14.23
Para volver a tener el entorno gráfico siempre he seguido el mismo procedimiento:
#sudo apt-get remove --purge nvidia-*
#sudo Xorg -configure
#sudo sh NVIDIA-Linux-x86-290.10.run
Obviamente, hay que sustituir el driver NVIDIA-Linux-x86-290.10.run por el que te hayas descargado de la página de NVIDIA
Si lo prefieres puedes descargarte previamente la última versión de los repositorios de Ubuntu usando:
#sudo apt-get install nvidia-current
viernes, 11 de noviembre de 2011
Iniciar Ubuntu siempre en modo texto
Para que Ubuntu se inicie siempre en modo texto, tenemos que modificar el grub.
Editamos el fichero de la configuración por defecto de grub:
#sudo nano /etc/default/grub
Sustituye la línea:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
y cámbiala por:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"
Reescribe el grub en el sector de arranque del disco:
#sudo update-grub
La próxima vez que reinices el entorno gráfico no se iniciará. Si quieres hacerlo, puedes usar:
Editamos el fichero de la configuración por defecto de grub:
#sudo nano /etc/default/grub
Sustituye la línea:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
y cámbiala por:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash text"
Reescribe el grub en el sector de arranque del disco:
#sudo update-grub
La próxima vez que reinices el entorno gráfico no se iniciará. Si quieres hacerlo, puedes usar:
#startx
jueves, 10 de noviembre de 2011
Reemplazar disco duro en un portátil por SDHC (micro-SD)
Como experimento, he sustituido el disco duro de un portátil TOSHIBA con Intel Centrino de los que distribuye la Junta de Andalucía a los centros TIC, concretamente uno modelo PTM50E-07302KLX, por un adaptador SATA 2.5" para SDHC, es decir, he sustituido el disco duro, un TOSHIBA HDD2D34 y en su lugar he puesto una SDHC de 8GB de clase 10.
Para comprobar el funcionamiento, he instalado Ubuntu 10.10 en la micro SDHC de 8GB clase 10 con un adaptador para SATA y ejecutado un test de benchmarking con System Profiler and Benchmark tool.
El equipo tiene un procesador es un T1300 @ 1600GHz, 2M caché con 512MB de memoria.
Después de ejecutar varios test, estos son los resultados con el Ubuntu 10.10 instalado en la micro-SDHC:
CPU Blowfish: 20.11 (cuanto menos, mejor)
CPU CryptoHash: 61.77 (cuanto menos, mejor)
CPU Fibonacci: 5.94 (cuanto menos, mejor)
CPU N-Queens: 13.98 (cuanto menos, mejor)
FPU FFT: 10.47 (cuanto menos, mejor)
FPU Raytracing: 28.21 (cuanto menos, mejor)
Los resultados de los mismos tests con el disco duro de origen, un TOSHIBA HDD2D34 de 40GB son los siguientes:
CPU Blowfish: 20.15 (cuanto menos, mejor)
CPU CryptoHash: 62.11 (cuanto menos, mejor)
CPU Fibonacci: 5.89 (cuanto menos, mejor)
CPU N-Queens: 13.97 (cuanto menos, mejor)
FPU FFT: 10.51 (cuanto menos, mejor)
FPU Raytracing: 28.23 (cuanto menos, mejor)
Los tests anteriores han sido hechos con hardinfo 0.5.1 y no parecen mostrar mucha diferencia ya que están destinado a medir y comparar el procesador.
Los resultados con hdparm son los siguientes:
Con disco duro TOSHIBA:
#sudo hdparm -Tt /dev/sda
Timming cached reads: 2022 MB in 2.00 seconds = 1011.18 MB/seg
Timming buffered disk reads: 94 MB in 3.04 seconds = 30.95 MB/seg
Con tarjeta SDHC 8GB clase 10:
#sudo hdparm -Tt /dev/sda
Timming cached reads: 1874 MB in 2.00 seconds = 937.07 MB/seg
Timming buffered disk reads: 28 MB in 3.17 seconds = 8.85 MB/seg
Concluyendo: la tarjeta es ciertamente más lenta con bastante diferencia. Otra cosa es el consumo. Con una SDHC la batería puede llegar a duplicar su autonomía.
Los resultados de hdparm con un disco WDC WD6401AALS-00L3B2 de 3.5" son los siguientes:
Timming cached reads: 1228 MB in 2.00 seconds = 613.75 MB/seg
Timming buffered disk reads: 332 MB in 3.17 seconds = 107.06 MB/seg
Para comprobar el funcionamiento, he instalado Ubuntu 10.10 en la micro SDHC de 8GB clase 10 con un adaptador para SATA y ejecutado un test de benchmarking con System Profiler and Benchmark tool.
El equipo tiene un procesador es un T1300 @ 1600GHz, 2M caché con 512MB de memoria.
Después de ejecutar varios test, estos son los resultados con el Ubuntu 10.10 instalado en la micro-SDHC:
CPU Blowfish: 20.11 (cuanto menos, mejor)
CPU CryptoHash: 61.77 (cuanto menos, mejor)
CPU Fibonacci: 5.94 (cuanto menos, mejor)
CPU N-Queens: 13.98 (cuanto menos, mejor)
FPU FFT: 10.47 (cuanto menos, mejor)
FPU Raytracing: 28.21 (cuanto menos, mejor)
Los resultados de los mismos tests con el disco duro de origen, un TOSHIBA HDD2D34 de 40GB son los siguientes:
CPU Blowfish: 20.15 (cuanto menos, mejor)
CPU CryptoHash: 62.11 (cuanto menos, mejor)
CPU Fibonacci: 5.89 (cuanto menos, mejor)
CPU N-Queens: 13.97 (cuanto menos, mejor)
FPU FFT: 10.51 (cuanto menos, mejor)
FPU Raytracing: 28.23 (cuanto menos, mejor)
Los tests anteriores han sido hechos con hardinfo 0.5.1 y no parecen mostrar mucha diferencia ya que están destinado a medir y comparar el procesador.
Los resultados con hdparm son los siguientes:
Con disco duro TOSHIBA:
#sudo hdparm -Tt /dev/sda
Timming cached reads: 2022 MB in 2.00 seconds = 1011.18 MB/seg
Timming buffered disk reads: 94 MB in 3.04 seconds = 30.95 MB/seg
Con tarjeta SDHC 8GB clase 10:
#sudo hdparm -Tt /dev/sda
Timming cached reads: 1874 MB in 2.00 seconds = 937.07 MB/seg
Timming buffered disk reads: 28 MB in 3.17 seconds = 8.85 MB/seg
Concluyendo: la tarjeta es ciertamente más lenta con bastante diferencia. Otra cosa es el consumo. Con una SDHC la batería puede llegar a duplicar su autonomía.
Los resultados de hdparm con un disco WDC WD6401AALS-00L3B2 de 3.5" son los siguientes:
Timming cached reads: 1228 MB in 2.00 seconds = 613.75 MB/seg
Timming buffered disk reads: 332 MB in 3.17 seconds = 107.06 MB/seg
miércoles, 9 de noviembre de 2011
UNITY no funciona después de actualización automática teniendo drivers de NVIDIA
Después de una actualización automática, al reiniciar el sistema, el escritorio está visible y operativo pero se ha iniciado con Ubuntu clásico en lugar de UNITY que era el escritorio por defecto que estaba configurado.
Para comprobar si el driver gráfico y el hardware instalado es capaz de ejecutar UNITY puedes escribir el comando:
#/usr/lib/nux/unity_support_test -p
Si no se puede iniciar el modo gráfico de ninguna forma, podemos intentar recuperar la configuración segura accediendo a un terminal desde el modo de recuperación y escribiendo:
#sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.copia
#sudo cp /etc/X11/xorg.failsafe /etc/X11/xorg.conf
Se pueden ver cuáles han sido las últimas actualizaciones en el fichero /var/log/dpkg.log
En mi caso, las únicas actualizaciones que considero que han podido cambiar la configuración establecida están relacionadas con la instalación de mesa-dri puesto que ninguna otra aparece en el fichero relacionada con el sistema gráfico.
En todo caso, solución pasó por reinstalar el driver de NVIDIA. Paso a paso:
En primer lugar, abrir una consola de texto con CTRL-ALT-2 o acceder al sistema usando el modo de recuperación y desactivar en el entorno gráfico escribiendo:
#sudo telinit 3
A continuación, eliminamos todo rastro del driver antiguo:
#sudo apt-get remove --purge nvidia-*
Configuramos las X de nuevo con:
#sudo Xorg -configure
y por último reinstalamos el driver que deberemos tener previamente descargado en algún directorio:
#sudo sh NVIDIA-Linux-x86-285-05-09
La versión del driver puede variar en función de la tarjeta gráfica o de la versión de Ubuntu.
Para comprobar si el driver gráfico y el hardware instalado es capaz de ejecutar UNITY puedes escribir el comando:
#/usr/lib/nux/unity_support_test -p
Si no se puede iniciar el modo gráfico de ninguna forma, podemos intentar recuperar la configuración segura accediendo a un terminal desde el modo de recuperación y escribiendo:
#sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.copia
#sudo cp /etc/X11/xorg.failsafe /etc/X11/xorg.conf
Se pueden ver cuáles han sido las últimas actualizaciones en el fichero /var/log/dpkg.log
En mi caso, las únicas actualizaciones que considero que han podido cambiar la configuración establecida están relacionadas con la instalación de mesa-dri puesto que ninguna otra aparece en el fichero relacionada con el sistema gráfico.
En todo caso, solución pasó por reinstalar el driver de NVIDIA. Paso a paso:
En primer lugar, abrir una consola de texto con CTRL-ALT-2 o acceder al sistema usando el modo de recuperación y desactivar en el entorno gráfico escribiendo:
#sudo telinit 3
A continuación, eliminamos todo rastro del driver antiguo:
#sudo apt-get remove --purge nvidia-*
Configuramos las X de nuevo con:
#sudo Xorg -configure
y por último reinstalamos el driver que deberemos tener previamente descargado en algún directorio:
#sudo sh NVIDIA-Linux-x86-285-05-09
La versión del driver puede variar en función de la tarjeta gráfica o de la versión de Ubuntu.
viernes, 19 de agosto de 2011
Chromium bloqueado en pantalla completa
En Ubuntu 11.04, con dos monitores configurados con diferente resolución, el navegador Chromium se queda bloqueado en modo pantalla completa al maximizarlo en el segundo monitor.
Parece ser un fallo de Compiz debido a que Chromium carece de barra de menu, en este link se reporta el bug.
Hay varias alternativas para poder solucionarlo. Se mencionan en el comentario #34.
Una de ellas, consiste en iniciar chromium con un directorio de configuración temporal, diferente del habitual del usuario, por ejemplo:
Mientras está ejecutándose el navegador, abrimos otra ventana del terminal y copiamos la configuración creada por defecto de forma temporal al sitio del usuario.
Con esto, reemplazamos la configuración del usuario que impedía cambiar el modo de pantalla completa por la configuración por defecto del navegador.
Otra posible opción consiste en crear un panel en el segundo monitor de forma tal que el navegador no se podrá mostrar a pantalla completa en este monitor.
Para crear un panel en el segundo monitor, crearlo en el primero y moverlo al segundo tal como se describe aquí.
Parece ser un fallo de Compiz debido a que Chromium carece de barra de menu, en este link se reporta el bug.
Hay varias alternativas para poder solucionarlo. Se mencionan en el comentario #34.
Una de ellas, consiste en iniciar chromium con un directorio de configuración temporal, diferente del habitual del usuario, por ejemplo:
#mkdir /tmp/chromium
#/usr/bin/chromium-browser --user-data-dir=/tmp/chromium
Mientras está ejecutándose el navegador, abrimos otra ventana del terminal y copiamos la configuración creada por defecto de forma temporal al sitio del usuario.
#cp -R /tmp/chromium/* ~/.config/chromium
Con esto, reemplazamos la configuración del usuario que impedía cambiar el modo de pantalla completa por la configuración por defecto del navegador.
Otra posible opción consiste en crear un panel en el segundo monitor de forma tal que el navegador no se podrá mostrar a pantalla completa en este monitor.
Para crear un panel en el segundo monitor, crearlo en el primero y moverlo al segundo tal como se describe aquí.
sábado, 23 de julio de 2011
Instalar Microsoft Fingerprint reader en Ubuntu 11.04
El procedimiento seguido está descrito aquí.
Aún no tiene soporte para las aplicaciones Gnome que hacen uso de los privilegios de administrador como Synaptic o Update pero se describe un atajo para solucionarlo de forma temporal.
Aún no tiene soporte para las aplicaciones Gnome que hacen uso de los privilegios de administrador como Synaptic o Update pero se describe un atajo para solucionarlo de forma temporal.
viernes, 22 de julio de 2011
Configurar un monitor como primario en un sistema con dos monitores
En una instalación de Ubuntu 11.04 con dos monitores, por ejemplo, al conectar un monitor externo a un portátil, se quiere configurar como primario uno de los dos monitores.
Usamos:
para conocer el modelo de nuestra tarjeta gráfica
A continuación,
para conocer el nombre asignado a cada uno de las salidas de la tarjeta gráfica. En mi caso, VGA-0, DVI-0 y S-video
Para establecer como primario el monitor conectado a la salida DVI-0, utilizamos el comando:
Este cambio no es permanente, quiere decir, que al reiniciar el sistema gráfico, los cambios se perderán.
Una posible solución sería incluir este comando en las aplicaciones al inicio:
y crear una nueva tarea al inicio donde ejecutaremos el comando.
Más info en este post.
Usamos:
#lspci | grep VGA
para conocer el modelo de nuestra tarjeta gráfica
A continuación,
#xrandr --prop
para conocer el nombre asignado a cada uno de las salidas de la tarjeta gráfica. En mi caso, VGA-0, DVI-0 y S-video
Para establecer como primario el monitor conectado a la salida DVI-0, utilizamos el comando:
#xrandr --output DVI-0 --primary
Este cambio no es permanente, quiere decir, que al reiniciar el sistema gráfico, los cambios se perderán.
Una posible solución sería incluir este comando en las aplicaciones al inicio:
Sistema->Preferencias->Aplicaciones al inicio
y crear una nueva tarea al inicio donde ejecutaremos el comando.
Más info en este post.
domingo, 17 de julio de 2011
bad geometry al montar un disco usb en Ubuntu
Al conectar un disco duro usb que contiene información valiosa se muestra el siguiente mensaje al hacer dmesg:
EXT4-fs (sdc): bad geometry: block count 156282966 exceeds size of device (156282965 blocks)
Este dispositivo fue formateado cuando estaba conectado al puerto SATA y de hecho, cuando lo conecto a un puerto eSATA, la información es accesible sin problemas.
Lo cierto es que todo indica que el número real de bloques del dispositivo es 156282966, esto se puede comprobar haciendo:
#sudo dumpe2fs /dev/sdc | less
En cambio, al ejectuarlo y buscar el último inode se puede observar que el último grupo ocupa desde los bloques 156270592 hasta el 156282965, ejecutando
#sudo e2fsck -v /dev/sdc
encuentra errores: puede ser que el superbloque, o la tabla de particiones, estén corruptos!
Si tratamos de montarlo:
#sudo mount /dev/sdc /mnt/tmp
devuelve error: superbloque incorrecto
El error también se muestra cuando ejecutamos:
#sudo fsck.ext4 /dev/sdc
Devuelve:
Para mostrar información del sistema de ficheros se puede utilizar mke2fs con la opción -n, esto mostrará dónde se encuentran las copias de respaldo del superbloque:
#sudo mke2fs -n /dev/sdc
Para comprobar la tabla de particiones en el dispositivo usamos:
#sudo sfdisk -l /dev/sdc
La información que muestra es la siguiente:
Ya sabía que el disco no tenía creada ninguna partición
Máximo permitido: 1250263725
Después de probar varias opciones, entre ellas, reescribir una nueva tabla de particiones con:
#sudo sfdisk -f /dev/sdc -O PT.save < PT.txt
donde PT.txt contiene una sola línea que indica lo siguiente:
donde 1250263724 es el número de sectores menos 1, que se calcula multiplicando el número de bloques por 8.
Hecho esto, se crean cuatro particiones en el disco.
Para solucionar el problema, lo que haremos será cambiar el tamaño del sistema de ficheros para que coincida con el tamaño del dispositivo con:
#sudo resize2fs -f /dev/sdc 156282965
el nuevo valor es el indicado en dmesg como el tamaño real del dispositivo.
Información sobre el procedimiento
Información general sobre la recuperación de particiones
EXT4-fs (sdc): bad geometry: block count 156282966 exceeds size of device (156282965 blocks)
Este dispositivo fue formateado cuando estaba conectado al puerto SATA y de hecho, cuando lo conecto a un puerto eSATA, la información es accesible sin problemas.
Lo cierto es que todo indica que el número real de bloques del dispositivo es 156282966, esto se puede comprobar haciendo:
#sudo dumpe2fs /dev/sdc | less
En cambio, al ejectuarlo y buscar el último inode se puede observar que el último grupo ocupa desde los bloques 156270592 hasta el 156282965, ejecutando
#sudo e2fsck -v /dev/sdc
encuentra errores: puede ser que el superbloque, o la tabla de particiones, estén corruptos!
Si tratamos de montarlo:
#sudo mount /dev/sdc /mnt/tmp
devuelve error: superbloque incorrecto
El error también se muestra cuando ejecutamos:
#sudo fsck.ext4 /dev/sdc
Devuelve:
El tamaño del sistema de ficheros (de acuerdo con el superbloque) es de 156282966 bloques
El tamaño físico del dispositivo es de 156282965 bloques
Para mostrar información del sistema de ficheros se puede utilizar mke2fs con la opción -n, esto mostrará dónde se encuentran las copias de respaldo del superbloque:
#sudo mke2fs -n /dev/sdc
Para comprobar la tabla de particiones en el dispositivo usamos:
#sudo sfdisk -l /dev/sdc
La información que muestra es la siguiente:
Disco /dev/sdc: 77825 cilindros, 255 cabezas, 63 sectores/pista
sfdisk: ERROR: el sector 0 no tiene una firma msdos
/dev/sdc: tipo de tabla de particiones no reconocido
No se ha encontrado ninguna partición
Ya sabía que el disco no tenía creada ninguna partición
Máximo permitido: 1250263725
Después de probar varias opciones, entre ellas, reescribir una nueva tabla de particiones con:
#sudo sfdisk -f /dev/sdc -O PT.save < PT.txt
donde PT.txt contiene una sola línea que indica lo siguiente:
#partition table of /dev/sdc
unit: sectors
/dev/sdc1 : start= 1, size=1250263724, Id=83
donde 1250263724 es el número de sectores menos 1, que se calcula multiplicando el número de bloques por 8.
Hecho esto, se crean cuatro particiones en el disco.
Para solucionar el problema, lo que haremos será cambiar el tamaño del sistema de ficheros para que coincida con el tamaño del dispositivo con:
#sudo resize2fs -f /dev/sdc 156282965
el nuevo valor es el indicado en dmesg como el tamaño real del dispositivo.
Información sobre el procedimiento
Información general sobre la recuperación de particiones
domingo, 22 de mayo de 2011
Instalar un nuevo disco duro en Ubuntu
Conectar el disco duro y asegurarse de que éste es detectado por la BIOS al iniciar el equipo. Para determinar cómo Ubuntu recono reconoce el disco, usamos el comando:
# sudo lshw -C disk
Busca en la lista de discos conectados el disco recién añadido y escribe el nombre del dispositivo que aparece junto a logical name, ese será el nombre por el que Ubuntu reconocerá el nuevo disco.
Particionando el disco
Elige si prefieres una única paritción o si utilizarás varias particiones. Iniciar el particionado en modo gráfico con palimpsest o:
Sistema->Administración->Utilidad de discos
Realizar el particionado haciendo click derecho sobre el dispositivo. Si se va a utilizar todo el disco, seleccionar la opción No particionar. .
A continuación formatear el volumen.
Elegir el sistema de archivos, ext3 o ext4 o fat32 si se piensa en que el disco sea compatible con Windows
A continuación, crear el punto de montaje. Normalmente en /media
# sudo mkdir /media/nevera
Realizar una copia de seguridad del fichero /etc/fstab y editarlo con:
# sudo nano /etc/fstab
Incluir la siguiente línea:
/dev/sdb /media/nevera defaults 0 2
El número 2 al final de la línea indica que debe realizarse una pequeña comprobación del sistema de archivos con cada inicio del sistema.
Guardar el archivo y montar el dispositivo con:
# sudo mount -a
Reiniciar y comprobar si el dispositivo se monta correctamente.
# sudo lshw -C disk
Busca en la lista de discos conectados el disco recién añadido y escribe el nombre del dispositivo que aparece junto a logical name, ese será el nombre por el que Ubuntu reconocerá el nuevo disco.
Particionando el disco
Elige si prefieres una única paritción o si utilizarás varias particiones. Iniciar el particionado en modo gráfico con palimpsest o:
Sistema->Administración->Utilidad de discos
Realizar el particionado haciendo click derecho sobre el dispositivo. Si se va a utilizar todo el disco, seleccionar la opción No particionar. .
A continuación formatear el volumen.
Elegir el sistema de archivos, ext3 o ext4 o fat32 si se piensa en que el disco sea compatible con Windows
A continuación, crear el punto de montaje. Normalmente en /media
# sudo mkdir /media/nevera
Realizar una copia de seguridad del fichero /etc/fstab y editarlo con:
# sudo nano /etc/fstab
Incluir la siguiente línea:
/dev/sdb /media/nevera defaults 0 2
El número 2 al final de la línea indica que debe realizarse una pequeña comprobación del sistema de archivos con cada inicio del sistema.
Guardar el archivo y montar el dispositivo con:
# sudo mount -a
Reiniciar y comprobar si el dispositivo se monta correctamente.
lunes, 16 de mayo de 2011
Conocer el uid y gid de un usuario
A veces puede resultar necesario conocer el uid y gid del usuario. Utiliza el comando:
# id
Devuelve información sobre el usuario actual. Si quieres conocer el uid y gid de todos los usuarios del sistema, tendrás que visualizar el fichero passwd:
# cat /etc/passwd
Para copiar todo un directorio con sus subdirectorios a otro:
# cp -arvf origen destino
# id
Devuelve información sobre el usuario actual. Si quieres conocer el uid y gid de todos los usuarios del sistema, tendrás que visualizar el fichero passwd:
# cat /etc/passwd
Para copiar todo un directorio con sus subdirectorios a otro:
# cp -arvf origen destino
jueves, 7 de abril de 2011
Obtener el offset para montar un disco formateado en HP MediaVault
Este post está directamente extraído de un artículo de Steven Pritchard. Un disco montado en un HP MediaVault MV2010 tiene formato reiserfs pero éste no comienza al inicio del disco sino que el sistema de ficheros se ubica tras un offset. El procedimiento para averiguarlo consiste en localizar una cadena de texto en el dispositivo que indica el inicio. La cadena a localizar es "ReIsErFs", "ReIsEr2Fs" ó "ReIsEr3Fs".
Para localizarla se puede utilizar el programa hexedit.
# sudo apt-get install hexedit
Suponiendo que tenemos conectado el disco duro en /dev/sdb
# hexedit /dev/sdb
Pulsar el tabulador para cambiar al campo de visualización ASCII, pulsar / para buscar e introducir la cadena a buscar, en nuestro caso "ReIsErFs"
El editor hexedit indica en la última línea la posición u offset donde la cadena ha sido encontrada. Por ejemplo, en 0x2685A034. Por tanto, el inicio del superbloque estará ubicado en 0x2685A000. Ahora ya tenemos el offset donde se encuentra la cadena, el inicio del sistema de ficheros estará situado 64K antes.
Para montar el sistema de ficheros:
# losetup -o $[646291456 - 65536] /dev/loop0 /dev/sdb
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp
El sistema de ficheros quedará accesible en /mnt/tmp
Para localizarla se puede utilizar el programa hexedit.
# sudo apt-get install hexedit
Suponiendo que tenemos conectado el disco duro en /dev/sdb
# hexedit /dev/sdb
Pulsar el tabulador para cambiar al campo de visualización ASCII, pulsar / para buscar e introducir la cadena a buscar, en nuestro caso "ReIsErFs"
El editor hexedit indica en la última línea la posición u offset donde la cadena ha sido encontrada. Por ejemplo, en 0x2685A034. Por tanto, el inicio del superbloque estará ubicado en 0x2685A000. Ahora ya tenemos el offset donde se encuentra la cadena, el inicio del sistema de ficheros estará situado 64K antes.
Para montar el sistema de ficheros:
# losetup -o $[646291456 - 65536] /dev/loop0 /dev/sdb
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp
El sistema de ficheros quedará accesible en /mnt/tmp
Montar automáticamente un disco duro del hp media vault mv2010
Después de averiarse completamente la placa base del HP Media Vault MV2010 que utilizaba con servidor NAS, he decidido configurar una máquina emachines EL1200 con Ubuntu 10.10 como servidor NAS.
Para poder utilizar el disco duro del media vault tal cual, es decir, sin formatearlo y sin perder los datos que contenía, debemos montarlo con un offset diferente (para averiguarlo seguir el procedimiento descrito en la página de Steven Pritchard)
Así pues, los pasos a seguir son:
Puedes comprobar que se automontará con:
#sudo mount -a
Para poder utilizar el disco duro del media vault tal cual, es decir, sin formatearlo y sin perder los datos que contenía, debemos montarlo con un offset diferente (para averiguarlo seguir el procedimiento descrito en la página de Steven Pritchard)
Así pues, los pasos a seguir son:
- Conectar el disco duro en un canal SATA y observar en dmesg dónde ha quedado instalado, en mi caso en /dev/sdb
- Averiguar el offset empleando el método descrito en el link.
- Crear un directorio que servirá de punto de montaje:
- Modificar /etc/fstab para que el dispositivo se monte automáticamente, editar con:
- Y añadir la siguiente línea:
- los valores están separados por tabulador
Puedes comprobar que se automontará con:
#sudo mount -a
viernes, 18 de febrero de 2011
Instalar webmin en Ubuntu Maverick
La aplicación se puede descargar de http://www.webmin.com. Elegir el paquete Debian package suitable for Debian, Ubuntu or other derived Linux.
Además del paquete, tenemos que instalar previamente todas sus dependencias. Para saber que paquetes instalar, suponiendo que nos hemos bajado webmin_1.530_all ejecutamos:
#dpkg-deb -I webmin_1.530_all.deb
Mirar donde dice Depends: bash, perl, libnet-ssleay-perl, openssl, libauthen-pam-perl, libpam-runtime, libio-pty-perl, apt-show-versions
Instalar manualmente y uno a uno todos los paquetes que se indican en las dependencias:
#sudo apt-get install openssl libauthen-pam-perl libio-pty-perl libnet-ssleay-perl apt-show-versions
Tal vez obtengas un error instalando apt-show-versions, si es así, ejecuta:
#sudo apt-get install libapt-pkg-perl
#sudo apt-get -f install
A continuación, ya podemos instalar webmin con:
#sudo dpkg -i webmin_1.530_all.deb
Suponiendo que no tenemos Internet, podemos descargar los paquetes necesarios con aptitude download en un ordenador que tenga conexión a Internet y copiar todos los archivos descargados en /var/cache/apt/archives a un pendrive usb. También podemos instalarlos en el ordenador con conexión con apt-get install y los ficheros se copiaran en la misma carpeta.
Después, en el ordenador sin conexión, repetir la secuencia de instalación, una a una, de las dependencias usando el comando: #sudo dpkg-deb -i paquete.deb
y finalmente, instalar el paquete webmin.
Para comprobar que webmin funciona, escribir en el navegador: https//localhost:10000
Recuerda que Apache debe estar instalado y funcionando.
Además del paquete, tenemos que instalar previamente todas sus dependencias. Para saber que paquetes instalar, suponiendo que nos hemos bajado webmin_1.530_all ejecutamos:
#dpkg-deb -I webmin_1.530_all.deb
Mirar donde dice Depends: bash, perl, libnet-ssleay-perl, openssl, libauthen-pam-perl, libpam-runtime, libio-pty-perl, apt-show-versions
Instalar manualmente y uno a uno todos los paquetes que se indican en las dependencias:
#sudo apt-get install openssl libauthen-pam-perl libio-pty-perl libnet-ssleay-perl apt-show-versions
#sudo apt-get install libapt-pkg-perl
#sudo apt-get -f install
A continuación, ya podemos instalar webmin con:
#sudo dpkg -i webmin_1.530_all.deb
Suponiendo que no tenemos Internet, podemos descargar los paquetes necesarios con aptitude download en un ordenador que tenga conexión a Internet y copiar todos los archivos descargados en /var/cache/apt/archives a un pendrive usb. También podemos instalarlos en el ordenador con conexión con apt-get install y los ficheros se copiaran en la misma carpeta.
Después, en el ordenador sin conexión, repetir la secuencia de instalación, una a una, de las dependencias usando el comando: #sudo dpkg-deb -i paquete.deb
y finalmente, instalar el paquete webmin.
Para comprobar que webmin funciona, escribir en el navegador: https//localhost:10000
Recuerda que Apache debe estar instalado y funcionando.
jueves, 17 de febrero de 2011
Instalar SWAT en Ubuntu Maverick 10.10
Desde el modo gráfico ir a Aplicaciones->Centro de software de Ubuntu e instalar los paquetes swat (Samba Web Administration Tool) y xinetd.
Desde el terminal:
#sudo apt-get install swat xinetd
A continuación, tenemos que editar el fichero /etc/xinetd.d/swat. Si el archivo no existe, tendremos que crearlo con el siguiente contenido:
Asegúrate de dejar un espacio a ambos lados del operador '='
Puesto que SWAT es una interfaz web, nuestro servidor debe tener instalado y funcionando un servidor web, por ejemplo Apache. Para comprobar si tienes Apache instalado:
#dpgk -l | grep apache
Para saber si está funcionando:
#service apache2 status
Para validar los cambios realizados en el fichero de configuración de SWAT, reiniciamos el proceso xinetd:
#sudo /etc/init.d/xinetd restart
Para acceder a SWAT, escribe en el navegador: http://localhost:901
El usuario root debe tener password configurada:
#sudo passwd root
Si no consigues acceder, comprueba qué está pasando en el archivo syslog:
#tail /var/log/syslog
Desde el terminal:
#sudo apt-get install swat xinetd
A continuación, tenemos que editar el fichero /etc/xinetd.d/swat. Si el archivo no existe, tendremos que crearlo con el siguiente contenido:
service swat
{
port = 901
socket_type = stream
wait = no
# Activar esta opcion quitando el comentario si se
# quiere acceso a swat solo desde el equipo local
# donde este instalado
# only_from = localhost
user = root
server = /usr/sbin/swat
log_on_failure += USERID
disable = no
}
Asegúrate de dejar un espacio a ambos lados del operador '='
Puesto que SWAT es una interfaz web, nuestro servidor debe tener instalado y funcionando un servidor web, por ejemplo Apache. Para comprobar si tienes Apache instalado:
#dpgk -l | grep apache
Para saber si está funcionando:
#service apache2 status
Para validar los cambios realizados en el fichero de configuración de SWAT, reiniciamos el proceso xinetd:
#sudo /etc/init.d/xinetd restart
Para acceder a SWAT, escribe en el navegador: http://localhost:901
El usuario root debe tener password configurada:
#sudo passwd root
Si no consigues acceder, comprueba qué está pasando en el archivo syslog:
#tail /var/log/syslog
lunes, 7 de febrero de 2011
Cambiar el sonido de la ventana de entrada
Para cambiar el sonido al inicio en Ubuntu Lucid 10.04, podemos seguir el siguiente procedimiento:
Copia el archivo de sonido que quieres que se reproduzca al inicio en la carpeta /usr/share/sounds/ubuntu/stereo/
El archivo debe tener formato y extensión .ogg
Ahora ve a Sistema->Preferencias->Aplicaciones al inicio
Busca GNOME Login Sound y, si no quieres que suene ningún sonido al inicio, deshabilita la opción, si quieres cambiar el sonido, pulsa en Editar.
En la ventana Editar programa al inicio cambia el campo Orden. Donde pone /usr/bin/canberra-gtk-play -id="desktop-login" -description="GNOME Login", sustituye "desktop-login" por el nombre del archivo de sonido que quieres que se reproduzca sin la extensión.
Pulsa Guardar.
Copia el archivo de sonido que quieres que se reproduzca al inicio en la carpeta /usr/share/sounds/ubuntu/stereo/
El archivo debe tener formato y extensión .ogg
Ahora ve a Sistema->Preferencias->Aplicaciones al inicio
Busca GNOME Login Sound y, si no quieres que suene ningún sonido al inicio, deshabilita la opción, si quieres cambiar el sonido, pulsa en Editar.
En la ventana Editar programa al inicio cambia el campo Orden. Donde pone /usr/bin/canberra-gtk-play -id="desktop-login" -description="GNOME Login", sustituye "desktop-login" por el nombre del archivo de sonido que quieres que se reproduzca sin la extensión.
Pulsa Guardar.
miércoles, 2 de febrero de 2011
Actualizar un repositorio local en Ubuntu
En Ubuntu Lucid, cuando intentas actualizar un repositorio local que está alojado en un dispositivo usb, haciendo:
#sudo apt-mirror /etc/var/apt-mirror.list
aparece el siguiente error:
comprueba que el fichero /etc/var/apt-mirror.list establece la variable set_base correctamente y apunta al dispositivo usb donde se encuentra el repositorio, en mi caso:
############# config ##################
#
# set base_path /var/spool/apt-mirror
set base_path /media/usbdisk/repo
A pesar de que el fichero de configuración mirror.list está configurado correctamente, el error aparece.
Para solucionarlo, crea la estructura mínima necesaria en el directorio por defecto de apt-mirror, es decir, crea el directorio apt-mirror en /var/spool con:
#mkdir /var/spool/apt-mirror
y ya puedes actualizar.
#sudo apt-mirror /etc/var/apt-mirror.list
aparece el siguiente error:
can't create /var/spool/apt-mirror/mirror directory at /usr/bin/apt-mirror line 245.
comprueba que el fichero /etc/var/apt-mirror.list establece la variable set_base correctamente y apunta al dispositivo usb donde se encuentra el repositorio, en mi caso:
############# config ##################
#
# set base_path /var/spool/apt-mirror
set base_path /media/usbdisk/repo
A pesar de que el fichero de configuración mirror.list está configurado correctamente, el error aparece.
Para solucionarlo, crea la estructura mínima necesaria en el directorio por defecto de apt-mirror, es decir, crea el directorio apt-mirror en /var/spool con:
#mkdir /var/spool/apt-mirror
y ya puedes actualizar.
Suscribirse a:
Entradas (Atom)


