Fedora 40 y otros problemas

 Como de costumbre, al liberarse Fedora 40 empecé a actualizar los equipos. Esta vez tenía la intención de retrasarlo, porque el trabajo aprieta, pero la tentación era muy grande y me lancé. Primero el de trabajo en terminal y los 4 comandos de siempre (aquí); unos 45 minutos y listo. Ningún problema. Luego el portátil; lo mismo. Para terminar, tengo el principal, sobre el que cae toda copia, sistema, seguridad y todo. En éste, debido a que desde que salió el kernel 6.7 tengo un problema con el bus USB, no me atrevía, ya que tenia reservado el kernel 6.6.13. El problema reside en que de repente, todo dispositivo en USB se desconecta; se ve como el ordenador sigue funcionando, pero soy incapaz de hacer nada, ya que dejan de funcionar el teclado y ratón (y tampoco sirve conectar otro en otro puerto), así que tengo que apagar a macheta. Y no, no sirve darle un toque a la tecla de apagar, porque aparece una ventana que dice cancelar o reiniciar, pero está en cancelar a los 60 segundos, y ahí se queda, y no puedo cambiar a reiniciar. El sistema también da otros síntomas, como el bloqueo de todos los vídeos en Youtube, tanto en Firefox como en Chrome. He buscado casos parecidos, y lo único que he encontrado ha sido un usuario que afirmaba que se debía a un error en el bus de la placa madre (esperemos que no, porque barata no es). En resumen, decidí instalarlo de nuevo desde una imagen en USB Fedora-Everything-40-1.14.

La verdad es que tardó poquísimo y funciona perfectamente, pero ya me ha aparecido uno de los síntomas; ya se me ha cortado Youtube. A ver como evoluciona. Por lo demás, Fedora 40 va como la seda. Lo voy a probar en equipos viejos a ver que tal, porque con Fedora 39 he resucitado equipos viejos que estaban para ser retirados. Parece como si Fedora se estuviera puliendo y consumiera cada vez menos recursos. 

Ah! fondo muy artístico

Fedora 39. Rápido y sin problemas, como de costumbre

No vamos a contar el cuento de todas las veces anteriores. Para los detalles, lea esta entrada. 

Igual de rápido y sin problemas. Nada más que decir. Por cierto, precioso fondo.

Fedora 38: la actualización es cada vez más sencilla

A pesar de que he intentado esperar un mes antes de actualizar a Fedora 38, no me he podido resistir y he transformado mis tres ordenadores principales (trabajo, casa y portátil personal).

Impresiones... Cada vez más fácil. Fue tal que así (ejecución como administrador):

dnf upgrade --refresh # sin problemas

dnf install dnf-plugin.system-upgrade # solo preciso en el portátil

dnf system-upgrade download --releasever=38

Un solo problema aquí, con una incompatibilidad entre la librería libheif instalada y la futura de fedora 38. Hubo que desinstalarla para que el proceso siguiera. Sin embargo, no fue necesario aplicar --allowerasing, siempre necesario hasta ahora. La carga necesitó entre 11 y 19 minutos, según ordenador. El que más necesitó, aparte de la velocidad de la red, tenía que bajar 3807 paquetes, 6,1GB

dnf system-upgrade reboot

Listo. Luego revisé lo más importante:

1. Si no se había modificado el fichero 90-override.conf de /etc/sysctl.d, donde incluyo kernel.sysrq = 1 para activar las teclas mágicas y fs.inotify.max_user_watches = 300000 para que dropbox no proteste por los ficheros que puede abrir. Sin problemas.

2. Estado de Dropbox - activo  y sin problemas

3. Demonio onedrive - activo  y sin problemas

4. Control de extensiones de gnome - hubo que actualizar casi todas y alguna ya no era compatible y hubo que eliminarla. Ningún problema. Cada día uso menos...

5. Aprovechando la situación, actualización de paquetes de R mediante update.packages(ask = F) dentro de R (que se actualice R no quiere decir que se actualicen los paquetes internos, que no dependen de Fedora)

Listo. Todo actualizado, sin pérdida de datos.

Tengo que decir que ni siquiera había realizado copia de seguridad, por varias razones: 

1. Siempre ha funcionado.

2. La aplique primero en el ordenador que no contiene la copia maestra.

3. La que pesó más, actualicé tan rápido debido a las discusiones que tengo en diferentes foros frente a los fanboys de Ubuntu. Como me caliento, no me pude contener. Defectos que tiene uno.

Fedora 37: impresiones

Como había dicho en la entrada anterior, tenía la necesidad de instalar Fedora 37 en uno de los ordenadores, porque había dejado algo que provocaba de vez en cuando un corte en el sistema gráfico. Pues ya lo he probado varios días en tres equipos instalando de limpio y actualizando. Todos funcionan adecuadamente, no se ha producido ningún corte y todo va como la seda (casi; ahora lo explico). En resumen, recomiendo el cambio inmediato. Tengo la sensación incluso de que los ventiladores hacen menos ruido, como si hubiera bajado en consumo y las necesidades del sistema.

 ¿Cuál ha sido el único problema que me he encontrado? Dropbox

En el ordenador que he instalado de nuevo en limpio, dropbox no se ha instalado correctamente por un problema entre dropbox y nautilus, por lo que no arranca al principio. La solución ha sido que cada vez que arranco o reinicio el sistema genero un terminal en el que ejecuto la orden ~/.dropbox-dist/dropboxd y lo fuerzo a arrancar. Simplemente tendremos que esperar a que dropbox corrija el problema y volveremos a la normalidad.

A la espera de Fedora 37, pero estrenamos Linux Kernel 6

Estábamos esperando a Fedora 37. Al principio debería ser el 18 de octubre, luego el 25 y finalmente iba a ser el el 1 de Noviembre. Sin embargo, Fedora Magazine nos avisó el 27 de octubre que tenían que retrasar la versión final de Fedora 37 debido a un bug de seguridad de OpenSSL. Bien, no pasa nada por esperar dos semanas por seguridad del sistema. Yo realmente tengo que cambiar de versión porque cometí un error en la instalación de Fedora 36 en el equipo nuevo. Admití que el usuario habitual entrara en permisos de administrador, y ocasionalmente hay un conflicto en el sistema que viene a ser que algo sucede desde el usuario y no es correcto y el sistema salta. He revisado los logs y no encuentro exactamente que fallo es, así que tengo que instalar de limpio y esperaba la versión 37. 

Aparte de este pequeño detalle, para compensar el retraso de la nueva versión esta mañana Fedora nos ha enviado la actualización del sistema al Kernel Linux 6.

Esta es una de las razones por las que uso Fedora. Quieres rapidez en las actualizaciones, usa Fedora.

Completando el equipo

Como había indicado en el cambio de equipo, no estaba terminado. Mi intención era poner un disco m-2 WD 2TB Blue modelo nuevo para home, pero no estaba disponible y el WD BLACK SN850 de 2 TB SSD NVMe se me iba de presupuesto (entre 320 a más de 400€ según distribuidor), así que quedó con el disco SSD SATA del equipo anterior (Samsung 870 QVO SSD 2.5"). Por suerte, en los días de Prime Day pude adquirir el Black 850 (208 €, con disipador incluido)

y por fin pude sustituir la unidad home. La ventaja de que en ese precio incluya el disipador también supuso que tuve que sacar el disipador que trae la propia placa Asus PRIME Z690-A.

Voy a poner un ejemplo para medir lo que ha supuesto todos estos cambios en tiempo de trabajo. La recodificación de una película 4k Remux de 70-80 GB a una versión razonable 4k x265 15-20GB llevaba en el equipo antiguo unos 3 días. Con el nuevo equipo más o menos, según duración de la película, oscilaba ente 11-17 horas. Pero luego reutilice el disco SSD SATA para dedicarlo solo a los ficheros origen y destino de esa codificación (antes usaba uno magnético WD RED PRO) y ahora, bajo esas condiciones, nuevo equipo, sistema y home en dos unidades WD BLACK SN850 NVMe PCIe Gen 4 de 500GB y 2 TB, respectivamente y un SATA SSD Samsung 870 QVO para manejar los ficheros de imagen, podemos hacerlo entre 5-8 horas. Seguramente, como la placa admite 4 NVMe podríamos acelerar más aún el proceso poniendo una unidad NVMe como origen y destino de los ficheros de codificación. Pero eso será cuando bajen de precio... A lo mejor no puede mejorar más, ya que cuando estaban los ficheros en un disco magnético, los cores del procesaro empezaban la codificación a tope, temperatura cerca de 90ºC y ventiladores a todo meter, pero luego se estabilizaban y volvían a la normalidad. En las condiciones actuales los ventiladores despiertan al edificio sin descanso ni normalización (tengo que cerrar la puerta). A lo mejor el procesador, i7-12700, que incluye tarjeta integrada, no puede más.

En la sustitución del disco SATA por el NVMe he tenido que realizar diferentes intentos:

1. Clonado con dd. Esto generó algún problema que no he podido entender. Como es natural, al clonar con dd quedan los discos con el mimo UUID, como ya habíamos visto aquí, así que supuse que simplemente podría arrancar de manera idéntica sin más, como me pasó aquí, sin tener que tocar fstab. Sin embargo no arrancaba el sistema; ¿alguna diferencia entre un SATA y NVMe? No lo sé.

2. En vista del fallo con el clonado por dd, instalación limpia. Muy rápida. Por alguna razón que no he encontrado en los logs, en las primeras horas el sistema gráfico saltaba aleatoriamente y precisaba reiniciar dos veces para arrancar el escritorio. A partir del día siguiente no lo ha vuelto a hacer. Parece como si el sistema se estuviera actualizando por detrás y se reseteara, pero eso no tiene sentido porque la instalación fue con Fedora-Everithing, con lo que extrae de los repositorios lo que hay que instalar y está actualizado. Bueno, no he encontrado la razón de esos fallos aleatorios del principio y ahora todo funciona perfectamente y hemos ganado fluidez en el trabajo (no lo he medido, aparte del tiempo de codificación; es solo una sensación).

En resumen, para que el sistema trabaje bien y rápido, pon el sistema operativo y el home (Mis documentos para los windoseros) en unidades NVMe, aprovechando las ofertas cuando aparezcan. Eso si, copia de seguridad, porque de estas unidades NVMe no se recupera nada cuando fallan (tampoco de las SSD SATA). Cuando el sistema podía acceder directamente a los chips de almacenamiento sí podíamos, pero ahora entre el sistema y los chips de almacenamiento existe un chip de control que es el único que sabe como se distribuye el material por dentro, y si este chip falla, adiós contenido. ¡Estáis avisados!

Actualización en terminal a Fedora 36

¡Actualizado a Fedora 36!

Suelo esperar a que pase un mes para actualizar, por razones de estabilidad, pero tenía tantas ganas de probar gnome 42 que no me he podido contener. Y de hecho, en vez de empezar por el portátil, para probar, lo he instalado directamente en los dos ordenadores de trabajo. Sin problemas, por cierto.

He realizado una actualización por terminal:

$ su -

# dnf upgrade --refresh

# dnf install dnf-plugin-system-upgrade # ya lo tenía instalado

# dnf system-upgrade download --releasever=36

Al contrario que la última vez, con el beta de Fedora 35, no he tenido que añadir --allowerasing.

# dnf system-upgrade reboot

Muy rápido y funcionando todo a la primera, incluidas las impresoras.

Kernel 5.16.12. Impresoras Canon dejaron de funcionar

Tanto en el trabajo como en casa tengo impresoras Canon, en concreto i-sensys MF421dw y MF443dw. Con Fedora 35, tras la actualización con kernel 5.16.12, ambas desararecieron del sistema. Fue imposible recuperarlas; de hecho el sistema no las reconocía ni las encontraba con lsusb. Sin embargo, al actualizar a 5.16.13, el sistema las reconoce y las puedo instalar y hacer funcionar. No encontré ni ningún comentario en la red sobre ello, así que supongo que fue un fallo que afectó a poca gente o a algunos modelos nada más. Seguiremos sobre el asunto, porque una de ellas, a pesar de ser reconocida, imprime en negativo. 

¡Cuidado con el kernel 5.16.12!

Ratones que no responden adecuadamente y alcohol isopropílico

 En octubre de 2019 decidí cambiar a un teclado mecánico —Logitech G413— y, para que el conjunto quedara bien, puse al mismo tiempo un ratón acorde al teclado —Logitech G203—; véase aquí. El teclado es una maravilla y no ha dado ningún problema. El ratón también funciona muy bien, y en los ordenadores con Windows no da problemas (sí, en mi casa tengo desertores al lado oscuro); en Fedora he tenido que conectarlo a un puerto USB3, y así funciona perfectamente; en la entrada natural del ratón no se puede controlar, con un movimiento errático y demasiado rápido. Bien, la noticia es que con solo dos años de uso, y teniendo en cuenta que no lo uso para jugar, salvo al solitario, el ratón empezó a responder al click simple como si fuera doble, lo que hace muy incómodo trabajar. De hecho, tengo en la caja de herramientas, aparte de un ratón Logitech M100 básico para cuando hace falta para cualquier cosa, otro ratón Logitech modelo más antiguo al que le pasaba lo mismo. Es una pena, por que es un ratón muy bueno, de alta resolución y muy ergonómico y cómodo de usar. Como no quería tirarlo, estuve buscando en la red a ver si otros usuarios habían tenido el mismo problema y lo habían solucionado. Y sí, debe ser un fallo bastante común, pero también fácil de reparar. En este vídeo lo explican perfectamente.

Así que simplemente soltamos los tornillos y con un cepillito de limpieza de máquina de afeitar lo he limpiado por todos los lados con alcohol isopropílico (2-propanol). 

El ratón tenía un montón de pelusa que entra por la rueda y se acumula en la parte de abajo, al lado de la rotación de la rueda, y justo ahí están los sensores de los botones de ejecución del ratón. También le hice lo mismo al otro ratón que tenía,y funciona también de nuevo perfectamente. Y la pregunta es ¿por qué isopropanol? Pues según parece, se seca mucho más rápido que el etanol, no deja residuos, permite extraer la suciedad adherida, que no se elimina con aire comprimido. Además, eso es una suposición mía, si limpiamos con etanol puro el precio incluye un impuesto que es más alto que el alcohol, salvo que lo compres con benzalconio, es decir, algo añadido con efectos no conocidos sobre el equipo. Además, en general lo venden en farmacias al 96%, lo que supone que hay un 4% de agua que a los equipos electrónicos no les gusta mucho.

En resumen, no tiréis los ratones antes de limpiarlos por dentro. Antes se estropeaban por desgaste, y por la suciedad que entraba por la bolita inferior. Ahora el problema es la rueda superior y todo el polvo que entra y que interfiere en los sensores.

Fedora 35 listo!

 ... y para los que tenemos beta, se actualiza a la versión estable.

Esperando por el 36!

Fedora 35 beta

Instalé Fedora 35 beta el mismo día de su presentación. 

¿Razones?; fundamentalmente por que tenía R anclado en la versión 4.05, sin poder actualizar porque algunas librerías del sistema no llegaban a versiones superiores en Fedora 34. He realizado una actualización por terminal:

$ su -

# dnf upgrade --refresh

# dnf install dnf-plugin-system-upgrade

# dnf system-upgrade download --releasever=35 (en este caso he tenido que añadir --allowerasing, debido a algunas cosas que ya no existen asociadas a pipeware)

# dnf system-upgrade reboot

vamos, lo de siempre. Esta vez más rápido aun. Resultado, todo funcionando menos Teams. Desde aquel día (28/09?) he estado matando Teams (killall teams) y volviéndolo a llamar, y a veces funcionaba. Sin embargo, desde la actualización de hoy ya funciona como antes (es decir, más o menos).

En resumen, si se necesita una versión muy actualizada de algún programa que no está —ni estará— disponible en Fedora 34, adelante, instalar la versión beta. En mi equipo funciona perfectamente (x86_64 Linux 5.14.9-300.fc35.x86_64, Intel Core i7-6850K, Radeon RX 560). Si no es así, como siempre recomiendo esperar a 1 mes después de que salga la versión estable.

Conflicto entre paquetes tras un fallo en la actualización del sistema con dnf

En los últimos días he tenido dos problemas que me han traído —un poco, tampoco hay que exagerar— por la calle de la amargura. Uno ya está solucionado y hablaremos de ese. Al segundo aun le estoy dando vueltas.

El viernes 16 de julio lancé la orden de actualización

su -c 'dnf -y update'

    passwd

y cuando empezaba a actualizar el sistema saltó. Bien, no le dí más importancia y al reiniciar el sistema intenté actualizar de nuevo y me apareció este mensaje, cortando la actualización,

...

Ejecutando verificación de operación
Verificación de operación exitosa.
Ejecutando prueba de operaciones
Los paquetes descargados se han guardado en caché para la próxima transacción.
Puede borrar los paquetes de la caché ejecutando 'dnf clean packages'.
Error: Error de prueba de transacción:
  el archivo /usr/share/doc/libdrm/README.rst de la instalación de libdrm-2.4.107-1.fc34.i686 entra en conflicto con el archivo del paquete libdrm-2.4.105-1.fc34.x86_64
  el archivo /usr/share/libdrm/amdgpu.ids de la instalación de libdrm-2.4.107-1.fc34.i686 entra en conflicto con el archivo del paquete libdrm-2.4.105-1.fc34.x86_64
  el archivo /etc/odbcinst.ini de la instalación de unixODBC-2.3.9-3.fc34.i686 entra en conflicto con el archivo del paquete unixODBC-2.3.9-2.fc34.x86_64
  el archivo /usr/share/doc/unixODBC/README.dist de la instalación de unixODBC-2.3.9-3.fc34.i686 entra en conflicto con el archivo del paquete unixODBC-2.3.9-2.fc34.x86_64
  el archivo /usr/share/doc/pango/NEWS de la instalación de pango-1.48.7-1.fc34.i686 entra en conflicto con el archivo del paquete pango-1.48.5-1.fc34.x86_64
  el archivo /usr/share/man/man1/pango-view.1.gz de la instalación de pango-1.48.7-1.fc34.i686 entra en conflicto con el archivo del paquete pango-1.48.5-1.fc34.x86_64

Es decir, libdrm-2.4.107, unixODBC-2.3.9 y pango-1.48.7 habían quedado como duplicados y se cortaba la actualización.

Mi primer intento instintivo fue instalar esos paquetes por encima,

su -c 'dnf install libdrm-2.4.107 unixODBC-2.3.9 pango-1.48.7'

pero esa orden me daba un mensaje similar. Intenté con --allowerasing y luego--skip-broken, pero nada. Como había muchas cosas que hacer lo dejé correr y estuve trabajando sin actualización. Ayer por la noche, 25 de julio, día de Santiago, con más tiempo libre, decidí mirar por la red una solución. A la primera salió (véase aquí). La primera idea era la buena, pero estaba mal escrita. La solución es REinstalarlo de nuevo. O sea,

su -c 'dnf reinstall libdrm'

su -c 'dnf reinstall pango'

Sin embargo, no funcionó con 

su -c 'dnf reinstall unicODBC', seguía diciendo que chocaban entre unixODBC-2.3.9-3.fc34.i686 y unixODBC-2.3.9-2.fc34.x86_64 y esta no quedó más remedio que escribir

su -c 'dnf reinstall unicODBC-2.3.9-3'

Y listo, ya se pudo actualizar.

El segundo problema es más extraño. De repente, la BIOS de uno de mis ordenadores ha dejado de reconocer el ssd que contiene el sistema como unidad de arranque, con lo que ese ordenador arranca siempre en la BIOS y tengo que decirle por donde tiene que arrancar. Al intentar decirle a la BIOS el orden de los dispositivos, ese no aparece para reconfigurarlo y tengo que recurrir al F8 en cada arranque. Pero eso será otra historia, si encuentro la solución.

Problemas con emule a través de wine en Fedora 34

Desde mi inicio en Linux, que si no recuerdo mal fue con Ubuntu 7.10, tuve que cambiar de emule a amule. Sin embargo, en julio de 2018, como señalaba aquí, amule empezó a congelar el sistema por consumo excesivo de memoria y CPU. En ese momento me volví al emule de toda la vida a través de wine. Y eso fue hasta la última actualización de wine (wine 6.10) y kernel (5.12.9-300.fc34.x86_64). En ese momento, emule empezó a utilizar el sistema sin control y se congelaba —emule, no el sistema; ventaja de que estaba en wine—, así que me he cambiado de nuevo a amule. Funciona razonablemente, al contrario de lo que había pasado en 2018, y tiene algunas ventajas. Primero, estoy en una aplicación de Linux; segundo, puedo utilizar un comando que me permite reiniciar automáticamente amule cuando salta, lo que pasa frecuentemente, sin que me tenga que preocupar. ¿Cómo se hace? Véase esta entrada.

 

Otra cosa que he realizado aprovechando la situación fue cambiar la estructura del ordenador añadiendo un disco nuevo para toda la parte ed2k. La idea es evitar una escritura continua sobre un disco ssd (/home), que hará que dure poco tiempo, por lo que instalé un hdd NAS (WD Red Plus) para ed2k, colocando Incoming y Temp en ese disco, liberando el disco /home (SSDV-NAND SSD 860 QVO SATA 6Gb/s de 2 TB). Debemos tener en cuenta que nuestros discos de trabajo a estas alturas son ssd o m2, en todo caso discos sólidos que no viven mucho tiempo si los tenemos grabando de manera continua, como pasa con ed2k. Por si hay dudas sobre esto, ya sabéis que los discos ssd de los mineros que minan por almacenamiento, como es el caso del minado de Chia coin, se estropean muy rápidamente y las compañías fabricantes no cambian los discos que se hayan sometido a minado. Y esa es la razón de que los discos hayan subido de esa manera de precio, situación que parece se está recuperando.

Para terminar, parece ser que podemos volver a amule y debemos cuidar nuestros discos utilizando para ed2k discos magnéticos (mientras existan).

Actualizando a Fedora 34 por terminal

[ACTUALIZACIÓN] El problema del icono de Dropbos ya está solucionado (27 de mayo, kernel 5.12.6)

Durante esta semana he instalado Fedora 34 en mis tres ordenadores de uso diario. Esta vez he realizado una actualización por terminal, que ha funcionado en los tres. Las instrucciones para hacerlo están en esta página, por si lo necesitáis.

Primero actualicé el portátil, mientras estaba trabajando con otras cosas en otro ordenador, por lo que no fui atendiendo a los diferentes pasos, tiempos... Era una prueba inicial para ver como iba todo. Una vez terminado, actualicé el principal de casa y luego el del trabajo. Estos sí que los fui controlando y vamos a exponer la tabla de tiempos. El ordenador de casa tiene ya 9 años, con una placa Intel DZ77BH-55K, i7-3770, 24GB RAM DDR3 1600 y discos sdd (sistema WD 250GB y home Samsung 860 2TB. El del trabajo es más moderno, algo más de 4 años, con una placa ASUS X99-A, i7-6850K, 64 GB RAM DDR4 PC2400 y dos discos m2 WD Black de 512GB sistema y 1 TB home). Teóricamente, debido a la diferencia de equipo, debiera terminar mucho antes el del trabajo. Veremos:

ACCIÓN	CASA	TRABAJO
Actualización (dnf upgrade --refresh)	7:10h	13:00h
Instalación plugin (dnf install dnf-plugin-system-upgrade)	7:12h	13:06h
Descarga paquetes (dnf system-upgrade download --releasever=34)	7:13h	13:08h
Repetición añadiendo --allowerasing	7:14h (3205 paquetes; 3,9GB)	13:19h (3220 paquetes, 3,9GB)
Aceptar llave Fedora 34	7:18h	13:28h
Reinicio y actualización (dnf system-upgrade reboot)	7:21h	13:30h
Limpiando	7:36h	13:42h
Scriptlets (tiempo necesario sobre todo en Selinux)	7:41h	13:47h
Verificación	7:45h	13:50h
Fin	7:51h	13:56h
TOTAL	41minutos	56 minutos

En primer lugar, la única dificultad, que exigió --allowerasing en los tres ordenadores fue un problema entre iptables y una librería. Todo queda solucionado actualizando los paquetes al terminar la instalación. Al actualizar todo queda configurado y en marcha, salvo las extensiones. Muchas dejan de funcionar, y algunas no son necesarias, por ejemplo la desactivación de la esquina superior izquierda se puede deshabilitar en retoques (por lo que podemos prescindir de No Topleft hot corner, por ejemplo).

Otras no funcionan. Por ejemplo Topiconsplus puede ser sustituida por TopIcons Fix, pero lo que me importaba, el icono de Dropbox, no se puede ver ni manejar (por ahora, espero). La instalación es sencilla, rápida y Fedora 34 va como la seda. Recomendable cambiar a 34, con el nuevo gnome y algunas sorpresas.

La segunda cuestión es la "carrera" entre los ordenadores. Si bien es cierto que en la primera parte, la que depende de la red, el de casa solo necesitó 11 minutos (más actualizado y una red de 500Mbits toda para él), frente a los 30 minutos del ordenador de trabajo (red con mayor capacidad, pero decenas de ordenadores trabajando sobre el mismo armario de reparto), la segunda parte me ha sorprendido mucho. La actualización y sustitución de paquetes ha supuesto para el de casa 30 minutos, frente a los 24 del otro. Sorprende gratamente la capacidad de trabajo de un ordenador hasta cierto punto obsoleto. Y no, no hay grandes diferencias en el software actualizado, por que uso el mismo software en casa y el trabajo, salvo emule. En mi mente estaba la idea de cambiarlo, y hasta ahora se había salvado por el precio tan alto de algunos componentes, debido a tanto minero sacando bitcoins. Pues ahora pienso mantenerlo hasta que ya no sea capaz de hacer algo imprescindible para mi. Me conformaré con ponerme un monitor de 27 pulgadas, 4k y a 144Hz.

¿Qué podemos hacer si el ordenador nos dice que hay que aumentar el tamaño de /boot/efi?

Ahora que el problema de parpadeo y congelación de wayland ha desaparecido (véase aquí), podemos hablar de algunas sorpresas que aparecen de vez en cuando.  Entre las personas que trabajan conmigo hay una que también usa Fedora. Tiene un ordenador nuevo del trinque que se encargó con un disco M2 de 500 GB (WD Black) y que se instaló automáticamente, dejando a Fedora que particionara como le diera. Curiosamente, desde hace unas semanas todo iba muy lento y se negaba a actualizar el software por falta de espacio en /boot/efi y /boot. Es un problema, porque con el sistema en marcha no se puede correr el resto de las particiones hacia la derecha con gparted, dejando espacio para hacer crecer a las otras dos. La solución, por supuesto, es bien sencilla; arrancar con un USB Live, instalar gparted y correr las particiones. /boot/efi tenía 631 MB, que deberían sobrar, y /boot 1,1GB, que también debería ser suficiente. Este de la foto es el mío escogido manualmente, y solo un poco mayor, y no me ha dado problemas.

Para evitar problemas posteriores, le robé a la última partición 4GB, que luego repartí entre /boot/efi y /boot. No tenía muy claro si el sistema arrancaría después, pero como la seda, y además funciona bien, sin la lentitud anterior de los últimos días. Y por supuesto ya se pudo actualizar.

VIVA GPARTED!

PD. No digo que no se puediera hacer en terminal, pero los conocimientos llegan hasta donde llegan y el saber ocupa lugar y pesa; no adquieras demasiado que no sea imprescindible.

Fedora 33, kernel 5.10.x y los navegadores parpadeando. Algunas soluciones

ACTUALIZACIÓN 2: Solo ahora, con kernel 5.10.19, parece funcionar todo como debería ser. Era hora!

Linux localhost.localdomain 5.10.19-200.fc33.x86_64 #1 SMP Fri Feb 26 16:21:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

 

ACTUALIZACIÓN: No solo desde los navegadores. Parpadea por ejemplo usando VLC; y cuando empieza el parpadeo, tiembla muchacho, que se acerca la congelación gráfica... Esperando solución en el kernel 5.11

Desde hace unas semanas, como de costumbre por no anotar, no sé cuantas, Firefox parpadea al navegar (en inglés, según domde miremos, flickering o blinking).

 

Si solo fuera eso, pues solo sería una pequeña molestia, pero en ocasiones bloquea completamente wayland y no se puede trabajar, de tal manera que cuando tenía algo importante ejecutándose, activaba un segundo escritorio (Ctrl+Alt+F3 a F7, ya que el activo suele estar en F2) y hacer otras cosas en el segundo escritorio mientras el anterior, sis sistema gráfico, continuaba su trabajo (copia de ficheros, codificación de vídeo...) y cuando creía que todos estaba terminado, iba cerrando el sistema y reiniciaba. Y yo que casi me había olvidado del REISUB 

¿Qué he intentado hacer?

1. Lo primero fue culpar a Firefox, y encontré que la búsqueda de proxy provocaba este problema. Lo reconfiguré sin búsqueda de proxy, y todo seguía igual. No se debía a eso.

2. Empece a quitar extensiones de Firefox, hasta que llegué a las que no puedo eliminar por que sería difícil para mi navegar sin ellas. Todo igual (de mal).

3. Me pasé a Chrome. El problema fue que en la segunda entrada en Chrome me bloqueó completamente el sistema. Es decir, no es solo cosa de Firefox.

4. Culpé a Youtube, por que me pasaba fundamentalmente al estas activando un vídeo en youtube (suelo poner vídeos de guitara clásica y los escucho mientras trabajo), pero me paso simplemente conectando Firefox o Chrome antes de llegar a ningún vídeo, así que no se debe solo a youtube o a los vídeos por internet.

5. Culpé a los cambios que había realizado en el ordenador, como añadir un sexto disco duro, así que redistribuí las cosas y eliminé ese sexto disco y lo deje como antes, pero todo sigue igual de mal. No era por el sexto disco.

6. Culpé a la BIOS, que había estado trasteando en ella. Volví a un estado estandar, pero nada ha ido a mejor. No era por la BIOS.

7. Culpé a Wayland, y me pase a x11. Lo mismo, así que no es cosa de Wayland.

8. Solo me queda como culpable el kernel 5.10.x. He leído en alguna página que el uso del kernel 5.11 experimental evita este parpadeo. Esperemos que sea así.

¿Y mientras, que podemos hacer? En estos momentos he encontrado dos soluciones:

1. Arrancar en terminal mediante firefox -safe-mode, y no parpadea. Obviamente navegas con un navegador pelado sin ninguno de los asistentes a los que estamos acostumbrados. Esto nos indica que realmente es alguna extensión (¿cuál y que relación tiene con el kernel 5.10? ¿es realmente así?). He sacado todas las relativas a flash, java, imágenes y me queda solo complementos de trabajo, gnome, amazon y adblock)

2. Siguiendo los consejos de hckorootx instalé Firefox para Linux (aquí). Obtenemos un firefox en tar comprimido (en mi caso es la versión firefox-85.0.2.tar.bz2). La descomprimimos (tar -xjvf firefox-85.0.2.tar.bz2). Lo arrancamos desde terminal (./firefox) y todo va bien, hasta que sincronizamos con el firefox de siempre, ya que carga las extensiones y todo lo demás. Es decir, nos permite, frente al arranque en modo seguro, añadir cosas, pero cuidado, son esas cosas las que están generando el problema.

Opciones:

1. Eliminar todos los complementos. Sencillo bien mediante firefox -safe-mode (Solución 1) o instalar esta versión que queda en un directorio (Solución 2) y no sincronizar.

2. Probar brave como navegador. De hecho, lo tengo instalado, pero nunca lo he usado por que llevo muchos años con Firefox y no es fácil para mi cambiar a otro navegador; tiene el él muchos años de historia (desde la desaparición de netscape).

3. Pasarse a Debian (Ubuntu está fuera de mis espectativas; de pasarme al lado oscuro me voy directamente a Windows y no a un advenedizo aspirante). Penúltimo recurso. El último es por supuesto Windows.

Veremos...

 

¿Cuánto tiempo necesitamos para instalar Linux en un ordenador moderno?

Debido a unos errores que cometí en la instalación de Fedora 33 mi ordenador de trabajo no estaba funcionando de manera adecuada. La solución era instalar todo de nuevo desde cero o descubrir que estaba mal en los ficheros de configuración, pero en ambos casos me daba la impresión de que me iba a llevar bastante tiempo solucionarlo, así que estaba trabajando en condiciones poco óptimas. Cuando ya no pude aguantar más los errores decidí cortar por lo sano y instalar todo de nuevo, ya que pensaba que sería menos costoso en tiempo. Empecé a las 13:15, arranqué en un USB con Fedora 33 DVD Live —Fedora-Workstation-Live-x86_64-33-1.2.iso— para cambiar el nombre del usuario en el disco home y evitar arrastrar la configuración que estaba provocando todos los problemas. Luego arranqué con una unidad Fedora 33 de instalación en red —Fedora-Everything-netinst-x86_64-33-1.2.iso—, que tiene varias ventajas sobre la anterior. Primero, permite generar administrador, no como la versión estándar, que no lo permite en la instalación, y así nos ahorramos el agujero de seguridad de sudo; segundo, permite escoger cualquier escritorio y software añadido; tercero, como se instala desde la red queda actualizado. La instalación base lleva unos minutos, por que hay que configurar la red, generar usuario y administrador y configurar los discos duros, qué particiones y formateo se quiere poner al disco de sistema y disponer los arranques adecuados a cada partición y disco (/boot/efi, /boot, /, /home, al menos; como se ve, ya no uso swap, debido a varias recomendaciones que he visto en los últimos meses y asociadas a Fedora 33 y discos sólidos). Pero una vez iniciada ya solo dependemos de la velocidad de descarga de los paquetes y lo rápido que se instala en el ordenador.

La secuencia fue así:

- 1655 paquetes para instalación de Fedora 33 workstation 64, aproximadamente 4 minutos (no me acordé de apuntar los MB/GB totales). Este es el punto más importante para saber cuanto tiempo va a tardar en hacerse el proceso, ya que dependemos totalmente de la velocidad que te permite tu operadora de red y la saturación de los repositorios de tu distribución.

- Instalación, entre 2 y 3 minutos. Muy rápido, seguramente por que el sistema lo permite (procesador muy potente, 64GB de RAM y dos discos M2, uno como sistema y otro como /home), por lo que la instalación va como un tiro.

- Configuración del sistema: 1-2 minutos.

Pero ahora estos supone un sistema limpio y actualizado, pero no con todo lo necesario. Falta todavía:

- Software adicional que utilizo; eso supone añadir repositorios y una lista larga de paquetes. Pero lo tengo preparado un fichero en el que tengo disponible un comando para añadir los repositorios rpmfusion y otro para instalar todos los paquetes que necesito. Total, 1337 paquetes, 1,7GB de descarga; tiempo de descarga: 3-4 minutos; instalación 3-4 minutos.

- Mientras están bajando e instalando este software adicional, añado un fichero /etc/sysctl.d/90-override.conf que ya tengo escrito y preparado para activar las teclas mágicas y aumentar el número de ficheros que controla el sistema para que Dropbox no se queje. Además muevo los directorios de datos del usuario antiguo modificado al usuario que voy a ser en la nueva instalación e instalo las extensiones de gnome que preciso.

- Instalación de Onedrive.

- Reinicio y listo; son las 13:58; todo en 43 minutos. Si tienes todo preparado en ficheros de texto plano (comandos y el fichero 90-override.conf) lo que más tiempo consume es la configuración inicial de los dispositivos, ya que en mi caso particiono el disco de sistema y defino cada partición, aprovecho sin modificación el disco /home y defino el arranque de todos los demás discos que formarán el sistema. En este caso, en el ordenador de trabajo incluyo un disco magnético denominado /datos que sirve como copia de seguridad interna de /home (copias incrementales mediante rsync que tengo predefinidas).

Fácil y rápido. Para mi todo ha sido más fácil desde que Fedora tiene en su sistema de instalación Anaconda.

Cuidado con los discos clonado

He tenido un "pequeño" accidente que he tardado en entender. El problema nació de mi decisión de eliminar la grabadora del ordenador, que ya no uso para nada. Eso supone disponer de un SATA libre. Como siempre, estamos escasos de espacio, y decidí recuperar uno de los discos retirados que tengo por ahí. Empecé por uno de 2,5TB, pero tenía algún sector erróneo, así que recuperé el más "moderno" de los disponibles, un Caviar Black de 2TB y fabricado en 2013. Lo incorporo, veo que está en ext4, así que decido no borrarlo y simplemente leo el UUID con blkid y lo incorporo al /etc/fstab

UUID=nume-rito-en-cuestion /mantener2     ext4    defaults        1 2

y reinicio.

En su interior había un directorio home, ya que este era mi antiguo home —véase aquí para ver el cambio de un HD Black Caviar a un SSD— y decido borrarlo... DESASTRE, por que borra todo ese disco y mi /home activo entero, es decir, todo mi trabajo. A otros les hubiera dado un ataque, pero para mi no es nada nuevo, porque me pasa de vez en cuando (esas manos quietas, muchacho!), así que sacamos el disco problema, tiramos de copia de seguridad para recuperar la información básica, instalamos todo de nuevo, porque mi copia de seguridad no guarda las configuraciones, y restaurado lo fundamental dejamos copiando el grueso de la información perdida; en total, unas 7 horas perdidas. Cosas a tener en cuenta:

1. La sincronización que tengo del OneDrive —véase entrada anterior— supone que al borrar el home borró también TODO, la nube y los otros ordenadores, cosa que no me ha pasado en Dropbox. MUY IMPORTANTE tener una copia de seguridad local y no fiarse solo de la nube.
2. ¿De dónde viene este problema? Al principio se lo atribuía a que el disco tenía un directorio /home y que la máquina los hubiera "unido" de alguna manera, pero no debería, ya que uno es /home/usuario y el otro es /mantener2/home. Después, mientras estaba intentando instalar Fedora 33 otra vez, anaconda me decía que detectaba dos discos con la misma UUID. ¿Cómo? Pues por que el disco Caviar Black ERA mi antiguo home, y el nuevo es un clon de él (aquí la prueba del delito clonador).

Sí, había clonado uno sobre otro, y eso ha supuesto que tuvieran para el sistema la misma UUID, y debería saberlo, por que como había dicho en la entrada donde explicaba ese cambio, no había sido necesario recurrir a editar fstab, ya que tenía la misma identificación y, además, debería haberlo visto al editar fstab, pero como lo hacemos todo a velocidad terminal, no nos fijamos en el resto del ambiente. Es decir, al decirle al sistema a través de nautilus —ahora llamado Archivos— que borrara el contenido de un disco, el sistema borró los dos que tenían la misma UUID.

En resumen, antes de reutilizar un disco clonado, formatearlo previamente y a ser posible en un ordenador distinto al que contenga la copia, no vaya a ser que también formatee a los dos en paralelo. Y además, copia de seguridad para todo, y no nos fiemos de tener algo en la nube, por que las nubes se las lleva el viento, o un borrado accidental.

Onedrive actualizado en Linux

A pesar de ser un usuario de Dropbox desde que esta aplicación nació, y que además tengo contratada una licencia plus de 2TB, por razones profesionales —los documentos oficiales de mi Universidad tienen que localizarse solo en el software y en el servicio de alojamiento contratado por ella— no me ha quedado más remedio que usar también OneDrive. El problema para lograr un trabajo fluido por alguien que usa software libre para todo está en que no existe un demonio cliente oficial que permita sincronizar OneDrive con el disco duro de trabajo en un sistema operativo Linux. He mirado las posibilidades no oficiales. La que parece más sencilla, Insync, no es GPL y además es de pago. La siguiente posibilidad, Rclone (página propia aquí), sí es GPL y gratuita, y que además permite sincronizar Google Drive, la veo complicada en su configuración (véase aquí y aquí, para el que quiera). Lo que he visto más sencillo y rápido es onedrive, el cliente gratuito y libre de OneDrive de MS.

La instalación y preparación es sencilla. Una buena página que indica lo más importante es ésta. Por pasos:

1. Instalamos

su -c 'dnf install onedrive'

2. Ejecutamos:

$ onedrive

y en el terminal aparece una URL muy grande que nos conecta al sistema Microsoft. Hay que abrir la cuenta y luego (o si ya la tienes abierta también) queda una página en blanco. Copiamos la URL de esa página en el terminal donde decía Enter the response uri:

y con ello permitimos la conexión y sincronización de onedrive con nuestro disco duro.

 

3. Sincronizamos

$ onedrive --synchronize

y aparece en nuestro nautilus —ahora llamado Archivos—. Esta orden actualiza en ambas direcciones TODO el contenido de OneDrive. Si queremos sincronizar solo parte de los directorios o ficheros de nuestro OneDrive, generamos un fichero sync_list en el directorio /home/usuario/.config/onedrive. Ese fichero podría líneas similares a: 

Apuntes
Imagenes
Documenots/fichero1.odt

Siendo los primeros directorios y el último un fichero en concreto que queremos que se sincronice. 

Hasta ahora estoy sincronizándolo todo.

Después de cada cambio, se resincroniza mediante

$ onedrive --synchronize --resync

4. Si queremos evitar la resincronización continua, podemos incluir el cliente onedrive en systemd. De este modo se sincroniza de manera continua desde el inicio y nos olvidamos de resincronizar

$ systemctl --user enable onedrive # permiso
$ systemctl --user start onedrive # inicio servicio

Si queremos comprobar que onedrive está monitorizando los cambios:

$ systemctl status --user onedrive

Si tenemos la monitorización activada y aparece un problema al ejecutar una sincronización al ejecutar onedrive --synchronize --resync—que no es necesario hacer, ya que el sistema se monitoriza automáticamente—, podemos apagar el servicio onedrive en systemd

$ systemctl --user stop onedrive

luego resincronizar OneDrive

$ onedrive --synchronize --resync 

y luego reiniciar el servicio
 
$ systemctl --user start onedrive

Sencillo.

# ACTUALIZACIÓN

He tenido algunos problemas de corte de sincronización y pérdida de identificación. La única forma de solucionarlo ha sido ejecutar

$ onedrive --logout

y luego repetir el proceso de identificación (onedrive, copia del url, acceder a el y copiar la respuesta en el terminal, para luego sincronizar de nuevo onedrive --synchronize).

Linux, Wayland y compartir escritorio en Teams

Como decíamos en la última entrada, hemos tenido problemas en el teletrabajo. El más importante ha sido el uso de Teams y compartir escritorio. La Universidad, al menos la mía, ha puesto como paquete de software oficial Office 365, que incluye un conjunto completo de aplicaciones, además de Word, PowerPoint y Excel. Para dar clase o para enseñar como se hacen ciertas cosas en clases prácticas o simplemente en una discusión de como se hace algo en aislamiento es necesario una aplicación de reuniones, y ahi tenemos Teams. Pero el problema fundamental en Teams se presenta para los usuarios de Linux con sistema gráfico Wayland cuando se quiere compartir un escritorio. Como es bien sabido, Wayland no deja fácilmente compartir y al tocar la opción compartir, Teams salta inmediatamente, y aunque se reinicia, te ha mandado fuera de la reunión y hay que volver a entrar; un problema si el profesor eres tú. Y como puedes enseñar si no puedes mostrar como lo haces tú. De hecho, he intentado cambiar permisos, y nada; he intentado arrancar la aplicación de escritorio de Teams, y Wayland no lo permite (completamente lógico). Finalmente, y para evitar un ordenador con Windows, requerí a la última esperanza, arrancar Fedora 32 en xorg (con el que accedemos a x11). ¡Y FUNCIONA!

Es decir, por ahora, mientros Microsoft, este nuevo amante profesional (póngale el sinónimo que quieran) de Linux, no arregle esta situación, y mientras gnome nos permita tener en la recámara un arranque en x11, tenemos una solución; cuando nos toque una conversación, clase, discusión o lo que sea con Teams, y por si durante el transcurso de la misma tenemos que compartir información a través del uso de cualquier programa en el ordenador y mostrarlo, arranquemos en xorg.