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


 


miércoles, 13 de enero de 2021

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



sábado, 19 de diciembre de 2020

Logo navideño de VLC

¡Lo que me he reído del logo de VLC en estas Navidades! Por si no lo habéis visto, simplemente es así


A reirse tocan

lunes, 7 de diciembre de 2020

Transformación de los DVDs a ficheros contenedores. Casos problemáticos

Como ya decía hace más de un año, estoy en la paulatina —y lenta, por falta de tiempo— eliminación del material óptico que tengo, CDs, DVDs etc, porque ocupa mucho mucho espacio y ya no tengo dispositivos para oírlos/verlos, practicamente, solo la consola PS4. Los de música es sencillo, sigo usando Sound Juicer, como decía hace mucho tiempo, pero convirtiendo a FLAC, para evitar pérdida de calidad. Con los DVDs es otra historia. Una vez conseguido saltarse la protección, que algunos países puede ser ilegal —comprobar donde está uno antes de seguir con la operación copia privada—, parece sencillo con HandBrake; simplemente indicas como fuente el directorio VIDEO_TS y listo, previa configuración del codec de vídeo, tasa de imágenes, calidad requerida, codecs de audio y formato de subtítulos. Bien, a veces es así, y otra no. Por ejemplo, puede tener un menú inicial que confunde al programa, dando como resultado un vídeo vacío. Ejemplo,

Un segundo error que me tiene pasado se da cuando el DVD tiene más de un vídeo, y Handbrake decide que el objetivo es el último, que resulta ser un extra o una entrevista o lo menos importante de todo el DVD. La solución podría ser aislar los ficheros vob que contienen lo que queremos, por ejemplo en este caso,


y que Handbrake los recodificara, pero bajo estas circunstancias Handbrake los trata individualmente, no como un vídeo completo. Dándole algunas vueltas, la forma más sencilla de arreglarlo es unirlos mediante MKVToolNix Gui. Al abrir el primero, recoge el conjunto de los ficheros que forman vídeo que interesa como partes adicionales y se une sin transformación alguna en uno o dos minutos en un fichero contenedor mkv matroska.


Después se edita y codifica el mkv resultante con Handbrake,


 y ahora sí que está listo; un Dvd menos ocupando sitio.

miércoles, 11 de noviembre de 2020

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.