miércoles, 27 de noviembre de 2019

90 segundos de retraso en el arranque mientras el sistema busca un UUID inexistente

En las últimas semanas he tenido dos problemas en el ordenador y una curiosidad. La curiosidad la dejamos para después y los problemas los he solucionado ayer. ¿Dos problemas?, si el título solo habla de uno. Al solucionar uno ha desaparecido el otro. Los problemas eran, primero, que el ordenador mostraba ciertos momentos de congelación en fases cada determinado tiempo —20-30 segundos—; el segundo, que solo lo notaba al reiniciar el ordenador, lo que pasa solo por actualización de kernel, era que el sistema se paraba 1 minuto y 30 segundos buscando un dispositivo con un UUID —Identificador Único Universal— inexistente en mi sistema. Al arrancar notaba un tiempo en vacío; si le damos a ESC, en vez de verse el logo de Fedora aparece el protocolo de arranque y ahí se podía leer:

A start job is running for /dev/disk/by-uuid/9013.... (34s / 1 min 30s)

y tenía 90 segundos para leer el mensaje hasta que seguía el arranque, que si no fuera por esto tarda unos 30s. Al apagar también tardaba y aparecía el mensaje

A stop job is running for Disk Manager (7s / 1 min 30s)

Lo primero que hice fue comprobar los UUID de los dispositivos del equipo, así que edité fstab

su -c 'nano -$ /etc/fstab'

y ninguna de las particiones del disco del sistema (/, /boot, /boot/efi) ni los otros 4 discos duros tienen ese UUID.
Ademas, lo comprobé de nuevo con blkid, que muestra los atributos de los dispositivos:


su -c 'blkid'

así como

su -c 'lsblk -ff'

que lo deja más claro, ya que dibuja un árbol mejor distribuido. Y, como debería ser, tampoco coincide ningún dispositivo con ese UUID. Revisando la red en muchos sitios se achaca este problema a un cambio de swap y que el UUID nuevo no haya sustituido al antiguo. Sin embargo mi partición swap muestra el UUID que se le asigna por fstab y la swap funciona como podemos ver


Entonces, si no estaba en fstab, y no era un problema de swap, ¿de dónde venía la orden de buscar ese dispositivo? Me puse a buscar parte de la cadena en los ficheros del sistema

su -c 'grep -lir "9013ddb2" /'

y el resultado fue nulo. Luego revisé los logs, y tampoco apareció nada. Miré todo lo que pude sobre systemd, y nada. Así que finalmente acabé en /boot/efi/EFI/fedora/grub.cfg y ahí estaba:

... resume=UUID=9013ddb2-...

Primero, ¿por qué el sistema no me lo había mostrado al pedírselo?; será que el administrador no puede entrar en EFI...
Segundo, el grub.cfg no se debe editar directamente, como dice el mismo,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

así que revisamos el fichero /etc/default/grub y los del directorio /etc/grub.d. Ninguno contenía ese UUID, así que ejecutamos

su -c 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg'

y reiniciamos y arrancó en un suspiro.

El segundo problema era la congelación temporal del sistema. En algunos sitios había observado que se podía deber a mutter, y que ere error se había corregido para la versión 3.34.1.11, pero era la que tenía y seguía congelándose. Sin embargo, al reiniciar después de haber cambiado grub.cfg el sistema dejo de estar congelado, asi que asumo que cada 20 o 30 segundos el sistema seguía buscando un dispositivo inexistente.

Queda por satisfacer la curiosidad, que es sobre sudo. Si me pongo a ello, lo pondré en otra entrada.


lunes, 18 de noviembre de 2019

Lectores de tarjetas flash como unidades USB

Desde hace bastante tiempo usamos las tarjetas flash como almacén de datos. La primera que tuve fue una Memory Stick que acompañaba a una cámara Sony. Era una tarjeta de poca capacidad—32MB—, así que la sustituí por una Memory Stick Pro de 256MB, que para aquel entonces no estaba mal, ya que las fotos ocupaban alrededor de 1MB y podía sacar bastantes, muchas más que las que entraban en un carrete. Por cierto, conservo esas primeras tarjetas y aun funcionan pero la cámara ya no está conmigo. Las cámaras que siguieron al modelo Sony fueron todos diferentes modelos TZ de Lumix, y todas ellas utilizan tarjetas SD (Security Digital). La primera que tuve fue una Ultimate de Kingston de 2GB, el máximo que podía alcanzar una SD estándar (relegada hoy como unidad de lectura de un escáner de negativos). Presentaba por aquel entonces una velocidad de grabación de 120x, es decir 0,150MB x 120 = 18MB/s; poca cosa hoy en día, pero en las cámaras de aquel entonces permitía grabar vídeos muy dignos. A lo largo del tiempo he ido comprando tarjetas con mayor volumen de almacenamiento y mayor velocidad (SDHC y SDXC), hasta las últimas que tengo disponibles, de 128 y 256GB, clase 3 V30, que en teoría garantizan una escritura mínima de 30MB/s, aunque prometen mucho más.
Para leer esas tarjetas podemos hacer una lectura directa de la cámara, con los cable que suelen acompañar a esos dispositivos —no las he leído así jamás— o extraer la tarjeta de almacenamiento y leerla mediante diferentes tipos de lectores. En esta entrada mostraba diferentes modelos de lectores que he utilizado. La verdad es que son dispositivos que vienen para ser usados un número de veces, y luego fallan, incluso los de marcas conocidas y de garantía teórica —por ejemplo, Kingston, que me ha fallado alguno—. En estos momentos tengo un UGreen, hasta que falle. Sin embargo, hay otros dispositivos que podemos utilizar para leer las tarjetas, diseñados originalmente para las SD, por su tamaño más reducido frente a las CompactFlash y más corto que las MemoryStick, pero ahora también con las MicroSD; son las unidades USB con apertura para la tarjeta. El primero que tuve fue un modelo Kingston TravelLite SD Reader:


El objetivo que nos planteamos con este dispositivo fue probar el uso de las tarjetas SD como unidad de información protegida al usar una unidad USB  en un ordenador no controlado. Las tarjetas SD disponen de una pestaña de bloqueo que impide la escritura en ellas, y permite una protección que un dispositivo USB no presenta. La inseguridad que teníamos como usuarios de ordenadores de acceso público quedaba hasta cierto punto cubierta así. Ese modelo en concreto estaba diseñado para tarjetas SD estándar, pero cuando aparecieron las SDHC probamos otro modelo de DataTraveler Reader,


que además de leer las tarjetas, llevaba interno 1 o 2GB de memoria flash interna. Sin embargo, ¿de que servía proteger la tarjeta si se te infectaba la unidad USB? Después de diferentes pruebas abandonamos el uso de estos dispositivos y preferimos el uso de un repositorio en la nube, Dropbox para ser exactos.

Actualmente disponemos de tarjetas flash SDXC y microSDXC de hasta 512GB. Personalmente tengo unidades de hasta 256GB, SDXC y hasta 128GB microSDXC, pero no las uso en las cámaras o en el teléfono, por varias razones. En mi cámara Lumix TZ100 llevo una SandiskPro clase 10 U3 para que garantice una grabación de videos 4K, pero solo de 64GB —y otra de reserva—, por que esa tarjeta permite aproximadamente grabar 1500 imágenes en la calidad más alta combinada raw2 + jpg. Sí, es cierto, ya no estamos en la época de los carretes, que suponía un coste por carrete de aproximadamente 25-30€ de aquel entonces por carrete, por lo que en ningún viaje he usado más de 4 carretes (140-150 fotos dependiendo de como cargara el carrete la cámara, en doble vuelta o directo). Ahora el coste es la cámara y la tarjeta y no hay revelado, ni impresión a papel y da igual el número que hagas, pero nunca en ningún viaje o salida he pasado de 1500 fotos, así que a partir de 64GB sobra espacio, sobre todo por que llevo dos. Entonces, ¿para que necesitamos unidades tan grandes? Las uso como unidades USB. Es más barato conseguir una unidad de 256GB en SDXC o microSDXC que en un dispositivo USB. Y además hoy disponemos de lectores de tarjetas muy baratos que son carcasas USB. Por ejemplo tengo varias unidades Sandisk para leer microSD,


que funcionan muy bien. Además, para mayor cobertura tengo un dispositivo Kingston que me permite incluir simultáneamente una tarjeta SD y una microSD,



con lo que con las tarjetas de las que dispongo puedo llevar en una unidad 384GB. El inconveniente de la unidad Kingston es que las tarjetas salen hacia afuera y se pueden soltar fácilmente. Respecto a la unidad Sandisk, al caer al suelo, se puede soltar la tarjeta microSD (me ha pasado). Pero ahora he encontrado una unidad que evita esos problemas, el MagiDeal 5GBPS USB 3.0 Mini Lector de Tarjetas Micro SD/SDXC. Es un dispositivo USB en el que la tarjeta microSD se introduce en la base de lectura de una unidad USB


¿Qué puede haber más cómodo? Y al mismo tiempo el coste es menor que las unidades flash con las mismas prestaciones. Como inconvenientes, tanto de la unidad SanDisk como de esta última, es que son muy fáciles de perder; aun no he perdido nunca una, pero siempre estamos a tiempo. Otro problema es la duración de las unidades microSD. Las tarjetas SD que he tenido funcionan aun hoy TODAS, pero las microSD, sobre todo las que usamos en el teléfono, hemos tirado más de media docena.
En resumen, en estos momentos podemos utilizar las unidades SD y microSD como unidades USB, con menor coste, sobre todo por que en general tenemos unidades que ya no usamos en el teléfono o cámara y podemos darle una segunda vida; de hecho tengo una cajita llena de tarjetas que he dejado de usar por ser de volumen pequeño o por otras razones que tengo la intención de usar con estos dispositivos lectores USB.


Por cierto, la caja es de carretes Agfa, así que es muy antigua, de mis primeros carretes, por que luego usé Kodak Ektachrome, de más calidad, y luego Fuji NPH, con un color natural y grano muy fino a pesar de ser ISO400, y así se podían sacar incluso interiores con poca luz.
Último consejo, recomiendo formatear las tarjetas con exFAT, ya que el formato NTFS me está dando bastantes problemas últimamente. Las tarjetas de cierto volumen (64 o más) ya vienen así de fábrica.

martes, 5 de noviembre de 2019

Joystick Logitech F310 en Fedora 31

Estos últimos tiempos comentamos más sobre hardware que sobre software. Quizás se deba a que no profundizo más sobre software, por que no lo necesito, o por que ya quedan pocas cosas que decir en un Linux que está, desde mi punto de vista, bien asentado y cada vez con menos necesidad de ir a terminal. Es decir, otra de hardware. Hace unos meses, por curiosidad, compramos un joystick Logitech F310 para jugar con Cuphead a través de wine. En aquel momento no lo conseguimos, y ni siquiera recuerdo por qué. Ayer encontré de nuevo el joystick y estuve buscando qué era necesario para que funcionara adecuadamente. En muchas páginas señalan la necesidad de incorporar kernel-modules-extras, pero solo unas pocas indican que es necesario incorporar también joystick-support. Además, para ver si está conectado y funcionando recomiendan evtest.
Es decir, ejecutar

su -c 'dnf install kernel-modules-extras joystick-support evtest'

y sí funciona. Como ejemplo, el propio Cuphead:


Si algún usuario de Fedora no había conseguido su funcionamiento, a mi sí me va ahora; a ver si podemos ayudar.