Tras varios años sigo usando Manjaro Linux en muchos de mis PC personales, que llevan todo este tiempo sin una reinstalación ya que al ser una distribución rolling release siempre está a la última. Demasiado a la última algunas veces.
Esto no evita problemas con la paquetería, sobre todo si te quedas varios meses sin actualizar, pero hasta ahora siempre he salido airoso de los pequeños líos que se montan ocasionalmente.
Esta semana me puse a actualizar una máquina y me encontré con este nuevo error:
# pacman -Syyuu
....
....
error: Error de GPGME: No hay datos
error: no se pudo actualizar core (base de datos no válida o dañada (firma PGP))
....
....
Mirando en Internet vi muchos consejos: refresca la lista de mirrors, refresca los países desde dónde descargas, etc. Ninguna funcionaba hasta que encontre esta solución:
Aunque pude actualizar luego me encontré con otro problemilla. La compilación-instalación del paquete:
# pamac build mjpg-streamer-git
Me daba de nuevo el error "error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida" cuando iba a instalarlo tras la descarga y compilación. Este tipo de problemas suelen ser cuestiones puntuales con los repositorios pero en este caso tenía prisa. Solución:
# pamac build -k mjpg-streamer-git
Esto descarga y compila el paquete, pero además deja una copia del paquete instalable binario en /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst. Vamos a intentar instalarlo a mano:
# cp /var/cache/pamac/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst /root
# pacman -U /root/mjpg-streamer-git-1\:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst
error: 'mjpg-streamer-git-1:1.0.0.r1.g310b29f-1-x86_64.pkg.tar.zst': paquete sin la firma exigida
Nada, sigue fallando. Para saltar el problema hay que desactivar la comprobación de firmas para paquetes que se instalen localmente. Editamos el fichero /etc/pacman.conf y cambiamos la línea:
LocalFileSigLevel = Never
Tras esto, ya podemos instalar el paquete sin contratiempos con:
Pasada mi penúltima pelea con los certificados digitales y recibiendo una sorpresa más al comprobar, en otra escaramuza posterior, que para solicitar el certificado digital por vez primera la FNMT también te obliga a usar Firefox 68 o Internet Explorer (no Edge) en el cual además el usuario raso debe configurar zonas a mano (la configuración automática no funciona las veces que he probado), me propuse ver si hacía funcionar el certificado digital del DNIe en Manjaro, usando el lector USB correspondiente. Es una tarea que he intentado varias veces en los últimos años casi siempre con mala fortuna.
Veo en AUR que hay varios paquetes con "dnie" en su nombre y que además parecen actualizados y mantenidos por sus respectivos héroes.
Nota: el paquete libpkcs11-dnie de AUR es una adaptación del paquete Ubuntu_libpkcs11-dnie_1.5.3_amd64.deb para Ubuntu que el DNIe publica en su página de software para Linux. Entiendo que casi todos los pasos que aquí damos pueden realizarse de forma similar para Debian/Ubuntu.
El paquete ca-certificates-dnie trae todos los certificados raiz necesarios para tratar con el DNIe, mientras que libpkcs11-dnie trae las librerias de acceso al dispositivo. Al finalizar la instalación del paquete nos da unas directrices para completar la instalación a mano:
Instalando libpkcs11-dnie (1.5.3-1)... [1/1]
Configurando libpkcs11-dnie...
>>>
>>> Installation:
>>>
>>> 1) If you don't already have it, enable and start pcscd: systemctl enable --now pcscd.service
>>> 2) Connect your smartcard reader without any smartcard in it and run: pcsc_scan
>>> 3) It should show info about your smartcard and tell you that there isn't any in it. Now insert your DNIe and it
>>> should show info about it. Now you know that your DNIe can be read by your smartcard reader.
>>> 4) To use your DNIe on Firefox, search for dnietif in your desktop environment applications launcher, run it
>>> and follow instructions
>>>
Hacemos lo que nos dice y seguimos los pasos: habilitamos y arrancamos pcscd.service...
# systemctl enable --now pcscd.service
Conectamos el lector de DNIe y hacemos pcsc_scan a ver si de detecta el dispositivo:
Buscamos el programa dnietif para configurar el Firefox y usarlo con el DNIe:
En el menú de aplicaciones "dnietif" aparece como "Registrar módulo PKCS#11 dnie (1.5.3)" y en realidad es un lanzador al ejecutable "/usr/share/libpkcs11-dnie/launch.pl". Este ejecutable no hace nada especial, simplemente nos abre una página web (/usr/share/libpkcs11-dnie/launch.html) con más instrucciones a realizar manualmente:
Los pasos descritos se realizarán sobre Firefox:
Instalación del DNI Electrónico. Para usar el DNI electrónico se requiere:
Instalar el Módulo de Seguridad PKCS#11
Para instalar el módulo PCKS#11 debe ir a Editar/Preferencias/Avanzado/Cifrado/Dispositivos de seguridad
Seleccione "Cargar"
Dele un nombre al módulo. (Por ejemplo "DNIe Modulo PKCS # 11")
Indique manualmente la ruta del módulo: /usr/lib/libpkcs11-dnie.so
Pulse el botón "Aceptar"
Instalar el Certificado Raíz de la Autoridad de Certificación del DNIe
Para instalar el certificado raíz ir a Editar/Preferencias/Avanzado/Cifrado/Ver certificados
Seleccione "Importar".
Indique manualmente la ruta del certificado raíz: /usr/share/libpkcs11-dnie/ac_raiz_dnie.crt
El asistente le pedirá que establezca la confianza para el certificado.
Marque las tres casillas de confianza.
Pulse el botón "Aceptar".
Una vez hecho esto, reiniciamos el navegador, vamos a "Visualizar certificados" en las Preferencias para ver el DNIe y nos pedirá el correspondiente PIN para acceder:
Y ahí está el certificado del DNIe junto con los que ya tenía antes de la FNMT:
No son pasos triviales, pero sorprendentemente y por primera vez en mucho tiempo funcionan a la primera sin mayor complicación, lo cual es todo un avance. Eso si: me preocupa que la parte de configuración del Firefox no pueda automatizarse de alguna manera... En fin, para una vez que funciona algo relacionado con la firma digital no vamos a quejarnos.
Como cualquier informático me toca muchas veces dar soporte a familiares, amigos y arrimados usando teamviewer. Cuando tienes Ubuntu o Fedora están en la página de descarga los paquetes preparados para descargar e instalar, pero cuando trabajamos con otra distribución con sistema de paquetes propio no nos queda otra que bajar el fichero .tar.xz con el ejecutable y los ficheros necesarios, descomprimirlo a mano y ejecutarlo.
Exite un paquete AUR de teamviewer para Manjaro, pero la verdad es que la versión original se actualiza tanto que el paquete no va muy fino y muchas veces no funciona. Es mejor descargar el tar.xz y trabajar directamente con él.
Un problema frecuente es que al abrir el programa se nos queda en estado de "error de conexión" y no funciona. Suponiendo que tengamos red y que no haya problema en los servidores de Teamviewer la razón típica es la versión del programa que tenemos instalado. A día de hoy solo Teamviewer 14 me funciona en el Manjaro, las versiones anteriores no conectan. Desconozco si es algo propio de Manjaro o afecta a otras implementaciones.
El segundo problema que me pasa es que cuando lanzamos el ejecutable de teamviewer:
$ cd teamviewer
$ ./teamviewer
Init...
CheckCPU: SSE2 support: yes
Checking setup...
Launching TeamViewer ...
Starting network process (no daemon)
Network process started (3703)
Launching TeamViewer GUI ...
Y ahí se queda sin mostrar nada.
El motivo real es que faltan por instalar dependencias, pero resulta que el ejecutable es tan mudito que no da error ninguno. Esto me recuerda un programa de Indra que vi una vez cuyo código tenia:
Si instalamos esos paquetes con pacman la cosa funciona sin problema.
El cometa interestelar 2I/Borisov. El segundo objeto extrasolar detectado en la historia, detectado el 30 de agosto de 2019 por el astrónomo aficionado Borisov en Crimea (Rusia, diga lo que diga Ucrania) con un telescopio modesto. Dado el aviso, la comunidad de aficionados se volcó en hacer seguimiento del objeto y determinar su órbita en los días siguientes, resultando que era un cuerpo que venía de fuera del Sistema Solar e iba a irse de nuestro lado. Ciencia ciudadana se llama.
La última noticia es una foto del Hubble y se ha confirmado que es un cometa que trae agua de otro sistema solar.
Teniendo en cuenta que 1I/ʻOumuamua se descubrió 2 años antes está claro que esos visitantes de fuera son mucho mas frecuentes de lo que podríamos pensar. Sería maravilloso ver llegar otro con tiempo para mandar una sonda...
Después de instalar nuestro Manjaro XFCE en el primer arranque nos pide que instalemos los paquetes de idioma. Con las ansias de empezar a enredar lo dejamos para mas tarde y cerramos la ventana...de tal forma que luego no lo vuelve a pedir más veces y nos encontramos con que Firefox, Libreoffice y otras cosas están en inglis.
¿Cómo instalamos los paquetes de idiomas perdidos? Podemos ir al Gestor de Paquetes y buscarlos uno a uno, pero Manjaro nos tiene un sistema mejor para hacerlo de forma centralizada y ordenada.
Nos vamos al Gestor de Configuración de Manjaro en el menú:
Ahí elegimos "Configuración de idioma":
En esta ventana podemos ver los paquetes de idiomas instalados y los disponibles:
Con el botón de "Instalar paquetes" podemos elegir nuevos paquetes para añadir a las distintas aplicaciones:
Y ya está. Sencillo e indoloro, como todo en Manjaro.
El otro día hice una macroactualización de paquetes que me pedía desde hacía tiempo mi Manjaro de casa. A raíz de ello Steam dejó de funcionar, quedaba cargando sin avanzar nada y mis hijos, con un juego recién comprado, estaban bastante nerviosos.
Después de investigar un poco veo que es debido a la actualización del paquete con los drivers nvidia-340. La última versión de los mismos fastidia Steam (y más aplicaciones que usan opengl) tanto en Arch/Manjaro como en Ubuntu. Como no hay paquetes mas modernos todo apuntaba a que había metido la pata hasta el corvejón.
Entonces se me ocurrió: ¿no tendrá Manjaro algún sistema para volver a paquetes antiguos de una forma sencilla?. A fin de cuentas, Manjaro es la distribución de Linux mas molona. Pues si, lo tiene: la herramienta downgrade.
Primero tengo que ver que paquetes tengo instalados y a que paquetes puedo retroceder haciendo "rollback" en el tiempo. Para ello tecleo como root:
Aquí se ve la lista de paquetes cacheados y que puedo instalar. En mi caso el fallo ha venido por actualizar el otro día a nvidia-340xx-utils-340.102-1-x86_64.pkg.tar.xz, generado el 10 de junio. Debo volver a uno anterior, cuando Steam funcionaba, por ejemplo nvidia-340xx-utils-340.101-8-x86_64.pkg.tar.xz del 3 de abril.
El problema es que no solo basta con volver atrás dicho paquete, ya que tiene como dependencias linux49-nvidia-.. y linux44-nvidia-.. y por tanto también tengo que volver a la versión de 3 de abril de ambos paquetes (que son del kernel, por cierto). Las versiones destino son:
-rw-r--r-- 1 root root 4780588 abr 3 16:06 linux44-nvidia-340xx-340.101-14-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 4779344 abr 3 16:06 linux49-nvidia-340xx-340.101-18-x86_64.pkg.tar.xz
-rw-r--r-- 1 root root 23800248 abr 3 16:06 nvidia-340xx-utils-340.101-8-x86_64.pkg.tar.xz
El comando nos preguntará de forma interactiva que versiones instalar mediante un menú del tipo 1) 2) 3)... simplemente elegimos el paquete correcto en cada una de las listas que nos muestra y le dejamos hacer. Si elegimos paquetes no compatibles (por tema de dependencias) el proceso se interrumpe y nos dice que paquete causa el problema.
Tras instalar los paquetes correctos, reiniciamos al acabar y.... tachán, ya funciona Steam. Ya puedo dormir tranquilo.
Para evitar las preguntas podríamos forzarle a que haga el downgrade instalando nosotros los paquetes directamente con:
# cd /var/cache/pacman/pkg
# pacman -U linux44-nvidia-340xx-340.101-14-x86_64.pkg.tar.xz linux49-nvidia-340xx-340.101-18-x86_64.pkg.tar.xz
nvidia-340xx-utils-340.101-8-x86_64.pkg.tar.xz
También es importante dejar esos paquetes a salvo de futuras actualizaciones en tanto en cuanto no estemos seguros de que el problema persiste. Eso se hace editando /etc/pacman.conf y añadiendo
Como siempre, dejo abierta una línea de investigación para volver aquí si hace falta: ¿qué pasa si queremos ir mas atrás y usar paquetes que no están en cache (/var/cache/pacman/pkg)?. Pues si hacemos:
# downgrade
Branch = stable
Downgrading from A.L.A. is disabled on the stable branch. See https://wiki.archlinux.org/index.php/downgrading_packages for more details.
Uso: downgrade , ... [-- ]
ver downgrade(8) para más detalles.
Podemos ver que hay algo llamado "A.L.A." que es el repositorio online de paquetes antiguos. No he investigado más pero queda apuntado que podemos ir mas atrás en el rollback usando esta funcionalidad.
Bueno, pues tarea resuelta, ya podemos relajarnos con unos minutos musicales mientras los niños le dan caña al Steam...
