jueves, 15 de marzo de 2018

Cuando se acaba la batería en el medio de la actualización

Es la primera vez que me pasa algo así. Tengo un portátil que uso en mi trabajo, y como en general dispongo de aulas con equipos fijos, y para que no se vea diferente a los que ven los alumnos —Linux vs. Windows—, rara vez lo uso. Aun así lo suelo llevar como equipo de reserva, por si falla algo. Como tenía la intención de probar todo en todos los sistemas, me puse a actualizar el portátil para luego actualizarlo a Fedora 27 mediante dnf. El problema es que el enchufe libre está al otro lado de la mesa, y mientras estaba trabajando con más equipos, me olvidé de enchufarlo. Debido a su edad, esta batería solo tiene carga para 45 minutos, y entre una cosa y otra en al medio de una actualización de más de 700 paquetes se acabó la batería. Al reiniciar el ordenador —esta vez enchufado—, y ejecutando otra vez el comando de actualización previa al cambio a Fedora 27

su -c 'dnf -y upgrade --refresh'

la respuesta fue múltiples líneas de

el archivo X de la instalación de X-2.3.5-2.fc26.i686 entra en conflicto con el archivo del paquete X-2.3.4-5.fc26.x86_64

Es común que aparezcan estos conflictos  de las versiones 32 y 64 bits, pero por qué al actualizarse. ¿No debieran haber entrado las versiones de 64 bits similares a las anteriores? ¿Es un problema de que no ha dado tiempo a eliminar por que se ha cortado en el medio?
La reparación es la eliminación de la versión i686, pero en este caso hablamos de mas de 200 paquetes duplicados, con lo que habría que repetir un comando más de 200 veces con un resultado final incierto; se acaba antes instalando de nuevo. Los pasos siguientes fueron:

1. Primero intentamos detectar los duplicados y eliminarlos luego en una sola orden:

# dnf repoquery --duplicated
# dnf remove $(dnf repoquery --duplicated)

pero no fue posible por que nos daba un error de salida

Error:
 Problema 1: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 2: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 3: The operation would result in removing the following protected packages: dnf, kernel-core, sudo

Es decir, no nos dejaba eliminar paquetes protegidos

2. Intentar la eliminación tratando de quitar la protección a esos paquetes, orden con resultado incierto:

# dnf --disableplugin=protected_packages remove $(sudo dnf repoquery --duplicated)

pero nos devolvía el mismo error:
Error:
 Problema 1: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 2: The operation would result in removing the following protected packages: dnf, kernel-core, sudo
 Problema 3: The operation would result in removing the following protected packages: dnf, kernel-core, sudo

3. Intenté la actualización con las opciones --allowerasing y luego --best

# dnf update --allowerasing
# dnf update --best

pero el comando enseñaba la misma colección de conflictos que upgrade

4. Intento baldío de ejecutar un distro-sync

# dnf distro-sync

por que nos respondía con los mismos conflictos

5. Intento baldío también de volver hacia atrás los ficheros duplicados con downgrade

# dnf downgrade $(dnf repoquery --duplicated)

con respuestas como esta para todos los duplicados

Hay paquetes para LibRaw-0:0.18.5-1.fc26.x86_64, pero no instalados.
Ya está instalada la versión más baja del paquete LibRaw, no se puede revertir.

6. Sustitución mediante rpm de los ficheros duplicados

# rpm -Uvh --replacefiles $(dnf repoquery --duplicated)

y es todos los paquetes aparecía la misma respuesta de error

error: la apertura de PAQUETE-x.fc26.x86_64 falló: No such file or directory

7. Antes de rendirnos a una instalación nueva y limpia de Fedora 27 recurrí a la opción que mostraba software de actualizarse a la versión 27 de manera gráfica. Parecía funcionar:


Pero al reiniciar el ordenador el sistema mostró una pantalla en negro con el cursor del ratón congelado y de ahí no volvió a salir.

Resultado final, instalación limpia de Fedora 27 desde dispositivo USB de 2GB. Esta vez, debido a la antigüedad del ordenador, sin necesidad de UEFI; 1 hora y todo listo.

PD. Y no los 5 días de instalación de un Windows 7 que he tenido desde el jueves de la semana pasada; 2 o 3 horas de instalación, 5 días de actualización. Cuando estaba por el reinicio número 20, y amenazando con 14 actualizaciones más ya le dije al compañero que se lo llevara y que lo acompañara en sus sentimientos.

miércoles, 14 de marzo de 2018

jdownloader, youtube y ffmpeg

Estos días me he encontrado con un "pequeño" problema cargando vídeos de youtube. Empecemos por el principio. Cuando un vídeo de Youtube me interesa o me apetece verlo con más calidad, resulta muy fácil poner la dirección del vídeo en youtube en jdownloader y este programa baja la mejor versión en muy poco tiempo para cuando quieras verla. Realmente nunca me he preocupado como Youtube guarda los vídeos ni nada por el estilo; lo utilizo de vez en cuando como observador y alguna vez, muy pocas, incluyendo algún vídeo con fin didáctico. Por lo que parece youtube guarda los vídeos con diferentes formas de vídeo y sonido por separado, y jdownloader los junta cuando lo utilizamos para bajarlos. Para ello debe utilizar —es una suposición lógica, según lo visto estos días— ffmpeg.
En una actualización jdownloader ha debido instalar plugins propios de ffmpeg que no funcionan, y el programa para en el intento de bajar los ficheros de vídeo y audio y pide una instalación de ffmpeg. Al decirle que sí, la respuesta es que ya está actualizado, y sigue sin bajar los ficheros; círculo infernal sin solución aparente.
La solución es bastante simple. En Opciones, Ajustes Avanzados, buscamos la ruta de ffprobe y ffmpeg. La ruta que estaba antes del arreglo era una ruta interna de jdownloader. Picamos con la derecha del ratón y las volvemos a las anteriores. Listo.


Estuve un montón de tiempo hasta que lo resolví, pero la respuesta directa estaba aquí. La de tiempo que me hubiera podido ahorrar.