DNF system upgrade: actualización de Fedora 22 a 23

Como ya hemos descrito, la actualización de Fedora se puede —podía— realizarse de manera sencilla con fedup —no voy a poner enlaces sobre ello, por que ya no lo necesitamos—, incluso en ordenadores remotos a través de ssh. Sin embargo el cambio de yum a DNF ha incluido también una nueva aplicación de actualización —DNF system upgrade— que facilita la actualización.
De los diferentes dispositivos que utilizo, he ido cambiando uno a uno de diferentes maneras, pero ninguno mediante esta nueva aplicación. Me quedaba el portátil, así que lo he realizado hoy. He seguido las instrucciones sencillas que nos da este enlace de la revista de Fedora. Si más,

1. Actualización del sistema

$ su -
# dnf upgrade

2. Instalar el plugin de dnf

# dnf install dnf-plugin-system-upgrade

3. Descarga de paquetes (en este caso 2226)

# dnf system-upgrade download --releasever=23

Sencillo y rápido, aunque depende de la red disponible. En WIFI tardó en este caso unos 20 minutos para algo más de 2GB, con una velocidad de bajada alrededor de 2MB/s.

4. Reiniciar y actualizar

# dnf system-upgrade reboot

Una vez ordenada, me fui a tomar un café, y al volver estaba terminando la comprobación final.

Conclusión: más sencillo que nunca, con solo 4 comandos, muy rápido, en función de la red disponible y como dificultades solo ha supuesto el bloqueo del repositorio de Dropbox. Una vez actualizado, todo funciona adecuadamente, incluyendo Dropbox, las aplicaciones de wine y todo lo demás. Aun no he descubierto ningún paquete con problemas ni dependencias no resueltas.

RECOMENDADO.

DD con errores, actualización de la BIOS y otras tribulaciones

He tenido varios problemas en cadena desde la instalación de Fedora 23, aunque la culpa no es del sistema. En esa instalación había introducido un quinto disco para que funcionara como contenedor de un conjunto de ficheros "persistentes" que no cambian nunca y solo van aumentando. Eso permitiría liberar parte del disco espejo que es la primera copia de seguridad. Para ello, en vez de comprar un disco nuevo, había recurrido a uno de los que voy desechando y están en los cajones, olvidados. Pues ese disco (WD Caviar Green 1,5TB; 5 años de uso intenso hasta ser abandonado) empezó a dar el primer problema; primero cambiaba aleatoriamente a "solo lectura" hasta que terminó mostrando un sector erróneo y no poder ser detectado por el sistema.

Eso supone que el Fedora no arranca por que no encuentra el disco que espera encontrar.

Para evitar el problema reinstalé de nuevo Fedora con otro disco sustituto (otro desechado; Caviar Black 1,5TB, antes sistema en un ordenador, ahora sustituido por un disco sólido). Y aquí surge el segundo problema. El sistema no encuentra el disco de arranque, y había que entrar el en menú de arranque y señalárselo cada vez que reiniciamos la máquina.

En la placa madre Intel DZ77BH-55K se habían descrito algunos problemas con los discos duros, así que comprobé que versión de BIOS estaba instalada; era la versión 57 de 2012, siendo la última disponible la 100 de finales de 2013. Bien, cambié la BIOS. Y eso nos lleva al tercer problema. A pesar de que la máquina había señalado que el cambio había sido correcto, no arrancaba, daba una serie de pitidos y quedaba con una pantalla en negro que no decía que hacer. Cambio de monitor y cable de señal y unos dedos mejores que los míos consiguieron reparar la instalación de la BIOS y todo vuelve a la normalidad... relativamente. Como Fedora se había instalado de nuevo, hubo que preparar los repositorios, incluir las aplicaciones de uso común (más fácil si seguimos a xenode), inhabilitar otra vez el VGA1 inexistente pero molesto,

habilitar las teclas mágicas, conectarme a Dropbox, activar mis cuentas para poder disponer de drive en nautilus... Es decir, entre una cosa y otra, de jueves a lunes perdiendo el tiempo en todas estas cosas.
¡ESTO ES DIVERSIÓN!

La necesidad de particionar un disco antes de instalar Fedora

La última instalación que hice, además de todas estas reparaciones y rearreglos que hemos visto, supuso también un cambio de discos duros. El disco de sistema, el disco que actúa como home y uno que utilizo para naterial multimedia son los mismos, pero el disco que funcionaba como copia de seguridad interna se estaba quedando pequeño y quise cambiar por un WD Red NASware de 6TB.

Como el ordenador tiene la posibilidad de conectar 6 unidades, para ocuparlas todas conecté un Caviar Black que tenía por ahí sin usar para ver que todo funcionaba correctamente si los colocábamos bien, es decir, la grabadora de última. En la instalación anaconda me mostró que antes de instalar, hay que formatear los discos. La instalación me permitió introducir todos los discos pero al decidir para que usaremos cada uno no me enseñaba el nuevo de 6TB. En resumen

sda1 /
sdb1 /home
sdc1 /home/multimedia
sdd1 /home/prueba

pero no había la posibilidad de introducir el sde1 para /home/backup por que no existía (lo bueno es que si media el espacio y decía cuantos TB quedaban sin usar).
El problema es que puse el disco directamente desde el estuche, sin formatear y no tenía partición alguna. Simplemente arranqué con un Fedora 22 live y, tras la intalación de gparted, generé una nueva partición y le di formato ext4. Luego ya pudo ser instalado como

sde1 /home/backup

Sí, es una instalación tradicional por unidades y no en volumen lógico (LVM); no estoy seguro de lo que puede pasar cuando se estropee un disco y lo que habría que hacer para recuperar el contenido. Además, no hay swap, por que no quiero poner la swap en sda, ya que es un disco sólido y quiero que dure (Intel 535 con SOLO 3 años de garantía, lo que me tiene algo escamado), y no me atrevo a ponerla en otro disco, por si retrasa el funcionamiento del sistema. Además, con 24GB de RAM no creo que sea estrictamente necesaria.

Como inhabilitar VGA1 y evitar el cambio del sistema a un monitor "fantasma"

Mi equipo personal tiene una placa madre Intel DZ77BH-55K, con doble salida gráfica DisplayPort y HDMI y con un i7 con un sistema gráfico integrado HD4000.

A pesar de que está conectada a un Philips 224 mediante DisplayPort, cada vez que el ordenador entra en ahorro de energía o si deja de recibir al monitor (este monitor tiene sensores de presencia y cuando no hay nadie delante, entra en ahorro de energía y se apaga hasta que alguien se pone delante) el ordenador se pasa a la pantalla secundaria VGA1 de 1024x768, lo que hace perder el panel y hay que entrar en la configuración por terminal y cambiar la pantalla principal. Eso en si mismo no es un problema, salvo que esté activado la protección por palabra, ya que no sale visible y no es posible acceder al sistema gráfico activo. Por supuesto, podemos generar uno nuevo en uno de los posibles terminales (con Ctrl-Alt-F2 a Ctrl-Alt-F6 y startx), pero los programas activos están en "otro" sitio, trabajando. Este error apareción en uno de los cambios de kernel, creo que en el primer kernel 4.x, pero tampoco estoy seguro, ya que he encontrado en la red casos similares con fechas anteriores. El problema es que no encontraba una manera de solucionarlo si quería mantener un control de palabra de identificación. El origen está en que para la máquina existe una salida más que el DisplayPort y HDMI. Si ejecutamos xrandr aparece al final un VGA1 (en este caso aparece disconnected, por que esta imagen la tomé DESPUÉS de haberlo arreglado).

¿Como hemos podido desconectarlo? Buscando en el conocimiento colectivo mundial —otra vez Google— encontré una solución aquí y aquí. Tenemos que editar grub

su -c 'gedit /etc/default/grub'

y añadir "video=VGA1:d" en la línea de GRUB_CMDLINE_LINUX line para deshabilitar VGA1

y luego actualizar grub. En el caso de Fedora no se reconoce la orden update-grub, pero sí esta

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

y al reiniciar, aparte de aparecer líneas de comandos que antes no aparecían, VGA1 está deshabilitado como veíamos en el terminal anterior y el sistema no se ejecuta en el monitor "fantasma" cuando te despistas unos minutos.

Solucionado.

PLC. Compatibilidad entre HomePlug AV y HomePlug AV2

Desde hace años (desde 2012, como podemos ver aquí) he distribuido la red en mi casa por dispositivos PLC (Power Line Communications). Estos dispositivos permiten la transmisión de señal de red a través de los cables eléctricos. Hasta este momento he utilizado dispositivos dLink DHP-P306AV, que ofrecen un ancho de banda de 200 Mbps según el protocolo HomePlug AV. Si bien es cierto que 200 es la capacidad que tengo contratada de entrada, también es cierto que me he comprado una televisión de 49 pulgadas con resolución 4k. La necesidad de un mayor ancho de banda para vídeos de mayor resolución y, por tanto, de mayor "tamaño" me hizo pensar sobre la posibilidad de transformar la red interna a niveles superiores a esos 200 Mbps (25 MB/s), para transferir desde un disco duro conectado al router hasta la propia televisión. Así que he realizado una prueba cambiando el extensor desde el router y el que sirve a la televisión por dos unidades TP-Link TL-PA4010, que son extensores más modernos, pequeños y muy baratos, pero con una capacidad de 500 Mbps (62,5MB/s).

Y ¿por qué le llamo prueba? Por que el resto de los dispositivos siguen bajo extensores dLink DHP-P306AV. En primer lugar, son de marcas diferentes; segundo, los TP-Link siguen protocolo HomePlug AV2, teóricamente compatible con el HomePlug AV de los dLink. En resumen, quería probar si no había problemas de compatibilidad. Como respuesta puedo decir que funcionan perfectamente sin problemas. Cuando mi proveedor me haya aumentado el ancho de banda, cosa que suele pasar cada año, cambiaré el extensor maestro por uno de 1200 Mbps y usaré los dos de 500Mbps para los dispositivos que más lo necesiten y los otros quedarán con los dispositivos de 200 Mbps.

UEFI y las unidades USB arrancables para instalar distribuciones de Linux

La generación del nuevo protocolo de arranque UEFI ("Unified Extensible Firmware Interface") como sustituto de la BIOS tradicional y el control que tiene Microsoft sobre los fabricantes de ordenadores, obligando a poner un arranque seguro ("Secure Boot") con una llave PROPIA nos ha estado provocando muchos problemas a los usuarios de "otros" SO. Muchas placas madre actuales no permiten deshabilitar el arranque seguro, así que es necesario disponer de la llave electrónica en los dispositivos para que en los ordenadores modernos los reconozcan como unidades de arranque. En mi caso aun no es un problema, debido a la antigüedad de mi parque electrónico, pero ahora que he estado instalando Fedora 23, tanto beta como estable, he preparado las unidades USB para que puedan ser utilizadas en todo tipo de máquinas, también las modernas.
Como indican las instrucciones de Fedora, las aplicaciones que hemos utilizado siempre (Unetbootin, MultiSystem...) no son válidas para el sistema de arranque seguro

"Universal USB creation tools such as Unetbootin are a historically popular way to create USB installers from ISOs intended for optical media. They typically function by creating a filesystem on the USB drive, extracting files from the image, and writing syslinux bootloader to the device.
These methods circumvent the bootloader configuration built into Fedora images, which are pre-partitioned and designed to boot on UEFI systems with SecureBoot enabled as well as BIOS systems. They do not produce a consistent result with Fedora's images, especially for use with UEFI systems.
Utilities that use a direct write method, and do not modify the Fedora image, will produce the most consistently successful results."

Es decir, es preferible utilizar otro sistema que nos replique EXACTAMENTE la imagen en el dispositivo. La forma más fácil es la aplicación discos de gnome.

En el menú de la derecha elegimos "restaurar imagen de disco", señalamos el ISO que queramos aplicar y en unos minutos, según la calidad y rapidez del dispositivo, tendremos preparada una unidad arrancable, siempre y cuando la imagen esté preparada para el "Secure boot". Por ejemplo,

Vemos como la ISO incluye diferentes particiones, incluida una EFI, en sistema de archivo FAT-12. Se puede aplicar también la orden dd en terminal, o en el caso de aquellas cuyo escritorio no incluya una aplicación gráfica que permita hacerlo
En ese caso primero hay que saber cual es la unidad del dispositivo, por ejemplo

su -c 'fdisk -l'

y una vez sabido aplicamos dd

su -c 'dd if=/ruta/imagen/Fedora-Workstation-netinst-x86_64-23.iso of=/dev/sdX'

Si bien en principio apliqué la aplicación discos (comando gnome-disks), ya que dd siempre deja libre y sin partición todo lo que sobra del espacio necesario para la imagen, discos también lo hace (usará seguramente dd para ejecutar esta acción) y como podemos ver en las dos imágenes incluidas, en ambos casos queda una parte del dispositivo libre sin particionar (parte azul del último, por ejemplo).

Y así tenemos preparado Fedora, en el primer caso un Live y en el segundo una instalación basada en red.

Fedora 23 (beta o definitivo); amule no arranca [SOLUCIONADO]

Así es. amule no arranca en Fedora 23, tanto beta como estable. He estado intentándolo en mi ordenador personal en beta y achacaba el error a algún "bug" en la versión beta y por que lo había instalado desde ejecutable externo y no desde rpmfusion, ya que no estaban disponibles. Sin embargo, desde ayer estaba trabajando sobre la versión en distribución estable y con la instalación desde repositorio y seguía sin arrancar. Eliminé la configuración personal, que viene desde mi primer Linux, por si alguna característica particular —directorios cambiados, permisos...— podía provocar que amule no arrancara, y nada. Buceando en la sabiduría colectiva —Google— encontré la solución.
El problema radica en un posible bug en el paquete cryptopp en Fedora 23 (véase aquí), así que la solución, como dicen ahí mismo, es bajar a una versión anterior —"degradar", que dicen los anglosajones—. Bajamos una versión anterior, por ejemplo desde aquí, y ejecutamos la orden

su -c 'dnf downgrade /ruta/hasta/ejecutable/cryptopp-5.6.2-9.fc22.x86_64.rpm'

y listo. Ni beta, ni fallo de compilación ni nada similar; simplemente, una dependencia con un "bug".

https://commons.wikimedia.org/wiki/File:EMule_mascot.png

[Actualización]. Como se ha indicado en el título, este problema ha desaparecido. La actualización del 10 de noviembre incluía un paquete amule que funciona con el cryptopp de Fedora 23. Un problema menos.

Canon i-sensys MF6140dn en Linux; esta vez en Fedora 23 beta

Hace unos meses indicaba como se podía instalar una impresora Canon —i-Sensys MF6140DN— en Linux, en concreto Fedora 22. Es una impresora con capacidad múltiple —impresión, copia, escaneo y fax—, de los que en Linux solo se puede usar la impresión (la copia no necesita ordenador y el escaneo se puede hacer en dispositivos USB). Debido al accidente de fregonas también indicado, no quedó más remedio que instalar de nuevo el sistema, en este caso, para adelantarnos, Fedora 23. Sin embargo, ha sido imposible que funcionara la impresora siguiendo las mismas instrucciones antes indicadas. 
Para hacerlo sencillo, en este caso los pasos han sido:
1. Hemos tenido que instalar un driver más moderno, versión 2.09, obtenido de aquí.
2. De nuevo hemos eliminado cualquier versión anterior de esta impresora en el Control de impresión y hemos desenchufado la máquina y USB.
3. IMPORTANTE. Extracción de los PPDs del interior del ejecutable —los correspondientes a la impresora, ya que hay muchos— e introducirlos como administrador en el directorio /opt/cel/ppd, ya que si no luego el programa no podía acceder a los controladores ppds ni indicándoselos, cerrandose la acción.
4. Instalación del paquete binario correspondiente a vuestra distribución. En mi caso

su -c 'dnf install /home/usuario/Descargas/o157oes_linux_CQueRPM_v209_64.rpm'

5. Conexión de la impresora y prueba.


Esta vez ha costado más que aceptara los controladores al enchufarla. Listo.

Morphing múltiple con software libre

La semana pasada una compañera mencionó el interés de hacer un vídeo o presentación que indicara su evolución a lo largo de los años. Unos años atrás yo había realizado un "morphing" entre dos compañeros que había quedado "interesante" y se me "sugirió" como posible autor de ese vídeo. El problema es que en aquel momento utilizaba Windows y ahora, en Linux y software GPL, tras diferentes búsquedas, no he encontrade software libre que pudiera realizar un "morphing" múltiple entre 5 fotos. Por supuesto, por el simple hecho de aprender, hemos llegado a hacer un vídeo avi de 4 segundos con la evolución de esa persona a lo largo de los años.
Partimos de 5 fotos tamaño carnet que copiamos con el móvil (no buscamos la perfección, solo aprender los pasos). En Windows hay diferentes aplicaciones, la mayor parte de pago, que permiten hacer "morphing", pero las que lo hacen con más de 2 fotos —múltiples— son todas de pago. Con aplicaciones de las que usamos todos los días y que podemos instalar desde el terminal tenemos:
- Gimp, con la extensión —"plugin"— de vídeo gap (su -c 'dnf install gimp gimp-gap'
- Mencoder (su -c 'dnf install mencoder')
- Algunos scripts de Gimp

Describamos el proceso por partes:
1. Para hacer la fase de "morphing" hemos usado Gimp con su extensión Gap. Tenemos unas instrucciones más completas aquí. Lo que nos importa es que solo podemos hacer "morphing" entre 2 capas (lo siento, por protección de datos no hay fotos de la persona en cuestión).

Eso nos obliga a hacer una copia de la primera foto en gimp, pegarla como nueva capa y sobre ella añadir una segunda capa de la segunda foto. En el menú Video, que solo tendremos si antes hemos instalado la extensión Gap aparece la posibilidad de morphing - morph, que nos lleva a este menú.

Sobre como debe hacerse, el número de "sharepoints" y todo eso, remito a las instrucciones completas antes citadas. En mi caso, para generar una evolución natural, aplique un solo "sharepoint" en el punto del centro de la parte baja de cada una de las dos fotos. Para generar un segundo de vídeo entre cada dos fotos, pedí 25 superficies, lo que genera 25 capas nuevas que van evolucionando desde la primera foto hasta llegar a la última.
Las posibilidades que nos da Gimp una vez generadas las capas son guardar un gif, con la pérdida de calidad y niveles de color —256 colores— o animación mng, que es un formato de animación asociado a png, pero que no es un estándar y muchos programas no lo reconocen. Por eso decidí grabar cada capa como imagen individual y generar un fichero avi estándar desde la línea de comandos. Gimp no tiene esa posibilidad directamente, pero encontré unos scripts preparados. Guardando los scripts en al directorio /usr/share/gimp/2.0/scripts aparecen en el menú Archivo de Gimp la posibilidad de grabar las capas (como tal o completas) y eso me ha permitido tener la transición entre las dos imágenes.
1capa0001.png - 1capa0025.png (foto 1-2)
2capa0001.png - 2capa0025.png (foto 2-3)
3capa0001.png - 3capa0025.png (foto 3-4)
4capa0001.png - 4capa0025.png (foto 4-5)

2. Generar una salida con transición desde esas 100 imágenes hasta un fichero estándar aplicamos un comando que ya hemos utilizado anteriormente, preparando un avi formato mpeg4 y con 25 imágenes por segundo, aunque esta vez sobre png y no sobre jpg (lo he probado hasta en un windows media player y funciona).

mencoder "mf://*.png" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4

Listo; fácil y "free" (gratis y libre). Tras este experimento hemos comprobado que podemos realizar un morphing múltiple (entre 5 fotos) con aplicaciones de código libre.

Cosas a tener en cuenta:
- Las fotos deben todas tener la misma resolución (ajustar con gimp o bien en terminal con convert de ImageMagick)
- Probablemente sea recomendable ajustar esa resolución a aquella que queramos dar al vídeo (idem)
- La creación de capas en Gimp lleva tiempo; más cuanto menos potente sea el ordenador (y si la RAM está muy justita)
- El comando mencoder, tal como está aquí, sin reconversiones, se ejecuta en poco tiempo

Y cuando las fregonas controlaron el mundo...

Las fregonas... ¿Por qué?
Por que he tardado una semana en reparar mi ordenador después de que una fregona libertaria —o libertina, según se mire— golpeara la regleta de alimentación del SAI del ordenador de trabajo, que nadie se diera cuenta del estruendo de alarma —era medio día, todo el mundo comiendo— y se apagara de mala manera el dispositivo. Resultado final, un arranque con errores:

Como podemos ver en la segunda imagen, el problema de arranque se debe a una inconsistencia en uno de los discos. Erróneamente, culpé al disco de arranque, un WD Raptor de 10.000 rpm, que ya está muy baqueteado, con más de 8 años de uso, y con un sector erróneo por otro apagado sorpresa. Empecé la reparación sustituyendo el primer disco por un sólido, pero me aparecía el mismo error tras la instalación del sistema. Eso me obligó a reconsiderar que el error estaba en el segundo disco, un WD Caviar Green de 1TB, que actúa como /home y que solo tiene 6 años de uso. La prueba smart indicó que no había errores físicos, pero no había tabla de partición. En resumen, todos los datos y configuraciones perdidos.
Instalación nueva, reutilizando los discos originales, con Fedora 23Beta (30 minutos) y recuperación de /home desde una copia de seguridad (varias horas). En resumen, entre unas cosas y otras 3 días seguidos trabajando a medias con un portátil. Peor aun, la copia de seguridad, aunque contiene todo, tiene la estructura del ordenador de casa, no la del trabajo, con lo que hay que cambiar la estrategia mental de localizar las cosas.
Una pérdida lamentable de tiempo, aunque sin coste económico, y unas entradas de retraso por una fregona.