viernes, 24 de febrero de 2017

En esos momentos en los que todos los errores —técnicos— se juntan...

Aunque sea accidental, fastidia bastante. Empecemos por el principio...
1. Resulta que tengo un equipo nuevo... que desde el principio ha necesitado un reset para arrancar. La presión del trabajo, más el hecho de que solo lo apago el viernes ha llevado a que hasta ayer no intentara un arreglo.
2. La última actualización, justo antes de llevar a arreglar, no terminó correctamente, y algunos ficheros quedaros a medias y no se limpió correctamente el sistema.
3. Se arregla, un simple cambio de BIOS (era lo esperado) y...

El sistema arranca, pero el sistema no funciona adecuadamente (por decirlo suavemente). No arranca el terminal, no responde a los comandos en Alt-F2 y está inestable (un bloqueo sin respuesta a las teclas mágicas).

Sin terminal, la situación es complicada, así que solo queda un recurso, los escritorios no gráficos adicionales (Ctrl+Alt+F1 a 7). Al instalar una herramienta para comprobar el sistema empieza a eliminar paquetes. Y en ese momento me doy cuenta del problema, ya que hasta ese instante estaba preparado para instalar de nuevo. Ya fue posible en la pantalla de texto actualizar, se limpió todo y tras el reinicio funciona como debe ser. Por cierto, no solo funciona, si no que lo hace de forma más fluida que antes, o quizás sea solo una sensación...

jueves, 23 de febrero de 2017

Kernel Linux 4.10

Se ha liberado el kernel 4.10. Para comentarios más técnicos existen páginas especializadas, pero en lo que importa a un simple usuario como yo destaco la mejora de la gestión de escritura a disco. Cuando Linux escribe al disco e intentas arrancar alguna aplicación, todos los procesos se bloquean hasta que el proceso de escritura se acaba, y como prueba de la relatividad del tiempo, a mi siempre me parecen horas. Como señala D'Oh! aquí estos problemas ocurren porque las escrituras intensas llenan las colas de la capa de bloques, y otras peticiones de E/S tienen que esperar mucho para ser atendidas. Teóricamente la versión 4.10 añade un mecanismo que controlará las escrituras y el bloqueo por la copia. Así que, Fedora, ¡ya estás tardando para actualizar el kernel! —ahora mismo tenemos instalada la versión 4.9.10—.


A ver si es verdad la rapidez en las actualizaciones en Fedora.

miércoles, 22 de febrero de 2017

Herramientas para una edición sencilla de un PDF

En alguna entrada hemos señalado las limitaciones que los usuarios de Linux tenemos en la edición de los PDF (Portable Document Format). En general, para arreglos rápidos, como cambios de orden de páginas, rotaciones, añadir o borrar páginas o fusionar documentos suelo usar pdf-shuffler o pdfmod. Como usuario de Fedora, y por tanto de gnome, lo más natural es el uso de pdfmod, ya que es una utilidad nativa de gnome y debería funcionar como un guante. La mayor parte de las veces es así, pero en ocasiones, sobre todo con PDFs grandes, da problemas y en la edición se pierden, en ocasiones, algunas páginas —aun no sé por qué—. Por ello, y hasta el día de hoy, recomiendo la utilidad pdf-shuffler. La apariencia es algo más antigua,


pero funciona adecuadamente.

miércoles, 1 de febrero de 2017

Dispositivo USB SanDisk Extreme PRO. Cuando no nos podemos permitir la paciencia

Como ya había indicado en alguna entrada, si usamos dispositivos USB baratos es necesario tener paciencia y no pedir demasiada velocidad a las unidades al copiar, y en ocasiones ni siquiera al leer. Sin embargo, a veces es necesario hacer algo rápido, y para ello es bueno tener dispositivos rápidos. En general uso unidades antiguas que cumplen su función; por ejemplo para llevar presentaciones uso un dispositivo SanDisk Cruzer Titanium de 4GB, que como su nombre indica tiene una carcasa de titanio que soporta presiones de 1000Kg; tiene bastantes años, pero funciona perfectamente, con una velocidad de lectura de 20MB/s y escritura 10MB/s, lo que nos recuerda lo ya dicho de la paciencia, aunque en sus tiempo no estaba mal. Por aquel entonces, cuando compre aquella unidad utilizaba como dispositivo USB rápido un Kingston DataTraveler ELITE, que copiaba a 29MB/s, que de aquella era increíble, pero tenía dos defectos, solo 1 GB y el precio desorbitado. Es aun hoy un lápiz muy rápido para ser USB 2, pero con 1GB dejé de usarlo rápidamente. De ahí me pasé a un Kingston DT R3.0 de 32 GB; lo uso aún hoy para instalar sistemas, por que es más rápido que el ELITE y me permite meter mucho material dentro. Cuando mi Dropbox empezó a ocupar un volumen grande, y para llevar una copia del trabajo diario en el bolsillo empece a utilizar unidades de 64GB, y tengo un Kingston HyperX 3.0 DataTraveler, que ha sido el fracaso más grande de todas los dispositivos USB que he tenido; teóricamente debería copiar a velocidades superiores a 100MB/s, pero nunca lo ha logrado, y consigo mejores resultados con el DT R3.0. Debido a ello y a que Dropbox sigue creciendo, lo sustituí por una tarjeta SD clase 10 de 128MB leída a través de un lector SanDisk Extreme PRO UHS-II. El lector es una maravilla, pero la tarjeta no funcionó tan rápido como era de esperar ni en formato exFAT ni en NTFS. Esto nos lleva al título de la entrada... finalmente he encontrado la unidad que buscaba, un SanDisk Extreme PRO USB 3.0 de 128GB. Me permite hacer un rsync de 80 GB en pocos minutos y funciona realmente bien. Teóricamente debería leer a 260MB/s y escribir a 240MB/s, pero en circunstancias reales la verdad siempre le aleja de estas cifras, así que bajo cronómetro he realizado estas pruebas:
1. Copiar 3 ficheros con 2,9 GB (las ISOs de Fedora) - 20,6s, a 144 MB/s hasta el desmontaje
2. 1 fichero multimedia de 18,2GB - 3m 15s, a 95 MB/s
3. 3991 ficheros de 14,9 GB en total (hojas de cálculo, documentos, fotos...) - 3m 23s, a 75 MB/s

De hecho la primera copia que hice con él se realizó a 214MB/s, pero ni lo desmonté ni cronometré el tiempo, así que no estoy seguro de la velocidad real de copia.


Es decir, ¡una maravilla!
Ah!, el que se quiera permitir un coste superior, SanDisk tiene una unidad Extreme PRO USB 3.1 que lee a 420MB/s y escribe a 380 MB/s. Ustedes mismos.

PD. A pesar de este largo viaje, aun me funcionan todos los dispositivos USB que he tenido, incluido el primero, un Kingston de 256MB de forma de torpedo. Realmente no se puede usar para nada, por qe cn ese tamaño no llega ni para actualizar las BIOS de los ordenadores.

lunes, 16 de enero de 2017

RaspberryPi como herramienta docente. R y Calc. Episodio 2

Como ya habíamos comentado en alguna entrada anterior, en ratos libres estamos probando la posibilidad del uso de unidades RaspberryPi como sustituto posible en el hardware para las prácticas en la materias que impartimos en la Universidad. Las aplicaciones que utilizamos en estas materias son Calc, como hoja de cálculo para la introducción y presentación de datos y R para cálculos estadísticos.
Como hemos visto, una vez eliminada la posibilidad de utilizar unidades de RaspberryPi modelo 2b, hemos estado probando unidades 3B con Raspbian. Sin ninguna modificación disponemos de Calc y se puede instalar R, pero en una versión muy antigua —3.01—. Esta versión podría servir para docencia, pero genera problemas a la hora de instalar paquetes, ya que muchos servidores espejo no disponen de versiones de los paquetes para versiones antiguas. Para poder instalar las versiones más modernas de R tenemos que incluir repositorios debian testing (stretch). Es decir,

1. Actualizamos los repositorios ya activos en el sistema

sudo apt-get update

2. Accedemos a la lista de repositorios del sistema

sudo nano -$ /etc/apt/sources.list

3. Introducimos al final una línea como la siguiente para activar el repositorio de prueba —testing— de debian para raspberry; en este caso sería

deb http://archive.raspbian.org/raspbian/ stretch main

4. Guardamos y reiniciamos el sistema

5. Después deberemos actualizar el sistema entero, ya que se instalarán muchos paquetes nuevos, que incluyen también LibreOffice (ya sabemos que Debian tiende a ser bastante conservador para mantener la estabilidad en los repositorios estables).

sudo apt-get update
sudo apt-get upgrade

6. Instalaremos R

sudo apt-get install r-base r-core r-base-core r-base-dev

Y ya tenemos R instalado en una versión moderna

R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"




Y la simulación de las prácticas ha sido perfecta, sin ningún contratiempo, pudiendo realizar todo sin problemas y con tiempo de respuesta adecuado, y sin problemas a la hora de instalar paquetes.




martes, 10 de enero de 2017

Wayland en Fedora; algunos inconvenientes

Llevo hasta este momento unos tres meses probando Wayland bajo diferentes circunstancias (portátil, sobremesa...) en Fedora 25. Teniendo en cuenta que solo soy un usuario normal, y no un desarrollador, hasta ahora he encontrado los siguientes problemas:
1. gparted, como indicamos aquí. No estoy completamente seguro de que se deba a Wayland, ya que me había pasado antes en X11. Aun así, como hemos visto, es fácilmente solucionable.
2. gnome-boxes, como habíamos indicado aquí. Solucionable con facilidad.
3. jdownloader. En ocasiones se cuelga y lanza una lista larga de errores (que desgraciadamente nunca he guardado). En las últimas actualizaciones no se ha producido, así que podemos darla por resuelta; además, era solo un pequeño problema que aparecía en ocasiones, al manipular la aplicación.
4. mkvtoolnix-gui. En terminal funciona perfectamente, pero la versión 9.40 de la máscara gráfica se colgaba (literalmente desparecía) al intentar realizar cualquier tipo de acción. Es un problema importante, ya que si bien en terminal se realizan fácilmente las extracciones, los montajes y añadidos de líneas de sonido o texto son complejos e incómodos en terminal. En la versión actual 9.60 funciona perfectamente, así que ya está solucionada.


5. vlc. Esta es la única alteración que me está afectando en mis ordenadores que aun no ha tenido solución. Al intentar visualizar cualquier fichero de vídeo el vlc simplemente no arranca. si se intenta por terminal da un mensaje de error como este:


A pesar de lo que dice, la reinstalación, incluido una previa desinstalación, no ha funcionado. Es el único problema que por ahora no he podido solucionar satisfactoriamente. Sí, hay otros programas, pero no me gustan tanto. Un pequeño fastidio.

ACTUALIZACIÓN:
No, jdownloader no está resuelta. De hecho, me ha vuelto a pasar. esta vez si he grabado el error. Para aclarar las cosas, esun error de Java, y empieza así (unas pocas líneas de unos cientos):
 

jueves, 15 de diciembre de 2016

sysqr no responde. ¿Dónde se activan las teclas mágicas?

Esta entrada tiene cierta relación con la anterior. En los tres ordenadores que tengo funcionando con Fedora 25, dos funcionan perfectamente con Wayland, descontando algunas alteraciones que iré explicando cuando las comprenda, pero un tercero, el más potente, el más moderno, muestra ciertas respuestas extrañas cuando está en el sistema gráfico Wayland. Fundamentalmente, el sistema muestra una granulación en el monitor y a partir de ese momento deja de responder a las órdenes gráficas y no deja llamar a un escritorio de texto (Ctrl+Alt+ F2 a F7, siendo F1 el que soporta el sistema gráfico). Este ordenador es el único que tiene una tarjeta gráfica externa, nVidia, por cierto; los demás llevan gráficas de Intel incorporadas en el procesador, y lo digo por si eso tiene que ver y alguno ve la relación. Además las primeras veces que se me bloqueó  el sistema no fui capaz de realizar una salida ordenada mediante sysrq (REISUB) y tuve que saltar el sistema con la tecla de reseteo.
Como había indicado en una entrada en la instalación de Fedora 18, la localización de los ficheros de configuración del sistema había cambiado de Fedora 17, /etc/sysctl.conf, al directorio /usr/lib/sysctl.d en Fedora 18, actuando desde  ese momento en el fichero /usr/lib/sysctl.d/00-system.conf. Y así apliqué tras la instalación de Fedora 25


y sin embargo no se ejecutaba la orden AltGr+ImpPant + REISUB.  Para comprender lo que supone, cada una de las letras ejecuta lo siguiente:

R pone el teclado en modo RAW (recobrar el control desde el entorno gráfico X al teclado)
E termina todos los procesos (end) (envía el comando Sigterm a todos los procesos, para finalizarlos ordenadamente)
I interrumpe todos los procesos (envía el comando Sigkill a todos los procesos, para forzar su terminación)
S sincroniza el disco duro (synchronize, descargar datos de la memoria a los ficheros en el disco duro)
U desmonta todos los sistemas de ficheros (unmount y volver a montar los sistemas de ficheros como de solo lectura)
B reinicia la máquina (reBoot)


Para evitar un tercer reseteo estuve evaluando los diferentes ficheros de configuración —/usr/lib/sysctl.d/— y en el fichero 50-default.conf aparece un mensaje así

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See sysctl.d(5) and core(5) for documentation.

# To override settings in this file, create a local file in /etc
# (e.g. /etc/sysctl.d/90-override.conf), and put any assignments
# there.

# System Request functionality of the kernel (SYNC)
#
# Use kernel.sysrq = 1 to allow all keys.
# See http://fedoraproject.org/wiki/QA/Sysrq for a list of values and keys.
kernel.sysrq = 16

Para que veamos lo que supone cada número dentro del sysrq, el orden es:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function description):
     2 - enable control of console logging level
     4 - enable control of keyboard (SAK, unraw)
     8 - enable debugging dumps of processes etc.
     16 - enable sync command
     32 - enable remount read-only
     64 - enable signalling of processes (term, kill, oom-kill)
     128 - allow reboot/poweroff
     256 - allow nicing of all RT tasks

Es decir, la el comando kernel.sysrq = 1 ejecutado en el primer fichero (00) de configuración es anulada por la kernel.sysrq = 16 colocado por systemd (50). Así que he sido obediente a systemd y he trasladado a un fichero /etc/sysctl.d/90-override.conf kernel.sysrq = 1, dejándolo fuera del directorio de configuración, y lo he eliminado del fichero 00. Algo exclusivo este systemd


Listo

miércoles, 14 de diciembre de 2016

Error en gnome-boxes bajo Wayland

He encontrado un problema en la ejecución de una máquina virtual en gnome-boxes en Fedora 25 utilizando Wayland. Más o menos resulta que tras la ejecución de gnome-boxes en terminal (si lo ejecutamos pinchando en el icono no se pueden leer los errores), al lanzar la máquina (en este caso Windows XP, para probar un programa), el sistema operativo comienza a cargarse y ahí se queda horas o días.


Podemos ver un error crítico en el terminal:

gnome-boxes:2361 Gtk-CRITICAL:gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed

Debe ser un bug que viene de atrás, desde Fedora 22, y que está indicado aquí.
Tenemos dos soluciones:

La primera, recurrir a virt-manager, con el que la máquina virtual funciona como se esperaba,


o volver a X11 en gnome y boxes funciona adecuadamente (errores no críticos más o menos),


A Wayland aun le falta un pequeño empujón.

miércoles, 30 de noviembre de 2016

gparted Gtk-WARNING: cannot open display - root y xhost

No es la primera vez que me pasa esto; instalación de sistema, llamar a gparted y se obtiene un mensaje de

Gtk-WARNING **: cannot open display

Esto se debe a que gparted requiere privilegios de administrador para poder usarse

Root privileges are required for running gparted

y que es una máscara GRÁFICA. El administrador solicita la apertura de un nuevo sistema gráfico y ya está en posesión del usuario. En general muchas páginas recomiendan una orden como

xhost +

pero esto genera un problema de seguridad, ya que se abre el sistema gráfico a cualquiera (véase por ejemplo aquí). Es además matar moscas a cañonazos, ya que si lo único que necesitamos es que el administrador local tenga acceso al sistema gráfico, ¿por qué añadimos todos? Así que creo que es más lógico añadir al administrador local

xhost local:root

y listo. gparted en marcha


jueves, 24 de noviembre de 2016

Actualización a Firefox 50. Bloqueo del navegador por el mensaje de error de la extensión dragdropupload

Eso mismo; por cierto, un error repetido en el tiempo y especialmente molesto. En la última actualización de Fedora Firefox se actualizó a la versión 50 (y otras muchas cosas). Al lanzar el nuevo navegador apareció un mensaje de error que lo bloqueaba continuamente haciendo imposible su uso. No he guardado instantáneas, pero era un mensaje de un Java Script similar a

"...dragdropupload TypeError: can't access dead object..."

La única solución fue, tras tratar de cerrar el mensaje muchas veces, aceptar la posibilidad de eliminar todos las extensiones. Al arrancar empezará a cargar de nuevo todas las extensiones, ya que se sincroniza entre todas las máquinas, y hay que estar rápido de reflejos para eliminar la extensión en cuestión. De paso eliminé algunas que tenía desde hace tiempo y que ya no utilizo.

Las ventajas has sido claras; en primer lugar Firefox arranca antes (se ve que tenía demasiadas extensiones) y además sincronizan los cambios a las otras máquinas, con lo que al día siguiente ya estaban aplicadas en mi despacho, como se puede ver en la siguiente captura de pantalla.


Menos mal, por que estos 15 minutos de Chrome me habían generado un dolor de cabeza...