jueves, 7 de octubre de 2021

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.

lunes, 26 de julio de 2021

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.


lunes, 5 de julio de 2021

Cambio de jugador: WD TV Live fuera, entra MECOOL KM2

Prácticamente 10 años después de haber utilizado mi segundo modelo de WD TV Live (véase aquí) he decidido sustituirlo por un MECOOL KM2. ¿Por qué? Pues porque el WD TV Live ya no cubre mis necesidades. A estas alturas, y con las televisiones que existen hoy, que prácticamente lo leen todo, algunos dirán que por qué tengo un TV Live. Pues porque en donde me paso los ratos libres no tengo televisión; tengo solo un monitor de 23 pulgadas y unos altavoces con subwoofer que me permite ver lo que quiero yo, no lo que quieren los directivos de la televisión. ¿Y por qué ya no sirve el TV Live? Pues porque no lee ficheros 4k, ni con 10bits de color, los colores ya no son muy naturales, hace años que no se puede actualizar... Además, múltiples páginas Web insistieron en que el MECOOL KM2 es bueno, bonito y barato.

Barato sí que ha sido —49€ aproximadamente—, y de paso he comprado por primera vez en Aliexpress; bonito lo dejo a gusto de los usuarios —estéticamente no me gusta nada— y lo de bueno se verá si dura tanto como el WD TV Live, que con casi 10 años aún funcionaba perfectamente, aunque no cubría con ficheros más modernos.

Aunque da muchas opciones, lo que más me importa a mi, que es ver lo que me apetece, se cubre simplemente instalando la app de VLC. Lee discos de más de 2TB, eso sí, en formato NTFS, nada de ext4. Lo sé, por que el primer intento ni leía la presencia de un dispositivo de 4TB, hasta que me di cuenta que lo había usado conectado a mi sistema y suelo formatear en ext4. Luego hay que buscar los menús, porque botones útiles en el mando son más o menos como los dedos de una mano. El uso, por supuesto, es muy diferente al antiguo TV Life. Este es un AndroidTV, con muchas más opciones, pero asociadas a la instalación de apps en Google Play. Como se puede ver en la foto, tiene dos entradas USB y una microSD. Además, el puerto HDMI es 2.1.

lunes, 21 de junio de 2021

VPN como respuesta a la identificación mediante una IP

Esto empieza a ponerse de castaño oscuro. Resulta que el Tribunal de Justicia de la Unión Europea aprueba el uso de una IP, bajo petición de una distribuidora de contenido, para culpar a alguien de ¿qué? 

Primer problema; ¿como va a identificar una IP a un usuario, con la facilidad que existe de piratear líneas WIFI? ¿como va a identificar una IP a un usuario, cuando en tu casa tienes un montón de elctrodomésticos IoT —Internet of Things— llenos de sensores y comunicación, que se comunican quieras tu o no y que no sabes cuantas puertas atrás tienen? ¿Cómo se han realizado los últimos ataques DDOS en el mundo? Pues provocando la revolución de los electrodomésticos, máquinas explotadas y obligadas a trabajar 24x7 —pobres neveras—. ¿Qué pasa si mi nevera quiere ver Juego de Tronos? ¿Qué pasa si mi vecino quiere ver Juego de Tronos a través de una de mis 5 redes inalámbricas?

Segundo problema; ¿de que te van a acusar? ¿cómo podrás demostrar que la cosa no va contigo?

Solución, VPN —Virtual Private Network; Red Privada Virtual en lengua de Cervantes— para todo.


 

PD. Para los que aun hagáis ed2k, que es el objetivo principal de esta distopía alucinatoria, en ed2k es preciso el port forwarding o redireccionamiento de puertos. No todos los servidores de VPN lo permiten. Como recomendación, AirVPN. Segunda recomendación; no son recomendables las versiones gratuitas; ya sabéis el dicho, en los servicios gratuitos, el producto eres tú, y tus datos y tu IP...

martes, 15 de junio de 2021

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).

jueves, 10 de junio de 2021

gnome-extensions-app: como levantar las extensiones cuando gnome-shell cae

Fedora 34, y con el gnome 40, trae algunas novedades y algunas ausencias que generan también algunos "problemillas". Por partes:

Hace dos o tres días, después de una actualización de kernel y un reinicio, empece muy rápidamente a lanzar las aplicaciones que tengo funcionando de forma continua. Es decir, Fedora empieza a cargar sus cosas, además tengo en el arranque Dropbox y Teams y además en demonio de onedrive (véase aquí) y yo empecé a lanzarlo TODO. De repente, gnome-shell o wayland se reiniciaron de golpe —¿estaría pidiendo algo antes de que se cargara la parte de Fedora que lo controla?— y tras un nuevo reinicio Fedora funcionaba perfectamente, pero las extensiones estaban caídas, y a través de Firefox no era capaz de levantarlas. En si, no es que sea importante, ya que no son imprescindibles para la mayor parte de las cosas, pero lo más importante para mi es que no se muestran los iconos de Dropbox y Teams, así que no puedo saber si están conectadas o no y tengo que comprobarlo mediante terminal y tampoco puedo cerrarlas o abrirlas o configurarlas; utilizo la extension TopIconsFix para que me muestre en el panel los iconos. Hasta gnome 3.38, retoques (antes configuración avanzada o tweak-tools) contenía una pestaña para manejar las extensiones, pero desde gnome 40 no; ¿qué hacer?

Buscando en la red encontré rápidamente la solución (véase aquí). Esa parte ha sido sacada de retoques y ahora es una app separada, gnome-extensions-app. Por lo tanto, debemos instalarla y llamarla y ya podemos levantar las extensiones.


Sencillo, pero deberían habernos avisado (supongo que lo hicieron, pero no sé donde). Pata terminar, ¿cómo la llamamos?

Bien, por terminal

$ gnome-extensions-app

o también ofrece un icono, Extensions, que aparece cuando lo buscamos mediante tecla super u tecleamos exten.... o en el conjunto de las aplicaciones.



martes, 1 de junio de 2021

He apagado mi ordenador! Paranoia por el consumo eléctrico

Pues es cierto. Hoy he apagado mi ordenador a las 9:25h. Me ha dado la paranoia del consumo eléctrico, o quizás por el coste. Solo apagaba el ordenador cuando me voy fuera o si cambio alguna pieza. Llevo sin apagar los ordenadores desde 1997, evitando reinicios de los HDD. Definitivamente me estoy haciendo viejo.



domingo, 23 de mayo de 2021

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.


miércoles, 10 de marzo de 2021

¿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.

sábado, 13 de febrero de 2021

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...