Mostrando entradas con la etiqueta Linux. Mostrar todas las entradas
Mostrando entradas con la etiqueta Linux. Mostrar todas las entradas

miércoles, 22 de mayo de 2024

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



miércoles, 8 de noviembre de 2023

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.



martes, 25 de abril de 2023

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.

martes, 22 de noviembre de 2022

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.

lunes, 31 de octubre de 2022

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.

miércoles, 20 de julio de 2022

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!

jueves, 19 de mayo de 2022

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.

lunes, 14 de marzo de 2022

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!

martes, 7 de diciembre de 2021

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.

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

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.

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.



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.

jueves, 5 de noviembre de 2020

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

miércoles, 22 de julio de 2020

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.

martes, 21 de julio de 2020

Fedora, R, los cambios de versión e infierno de dependencias

Bien. Como podéis ver esta pandemia nos ha llevado a que hagamos menos entradas. El teletrabajo consume más tiempo y te deja más cansado y un poco harto del ordenador.
En nuestro teletrabajo ha dominado la situación Teams, del amigo Microsoft, que para los linuxeros, o al menos para mi han sido un problema. De eso hablaremos más tarde. Mi otro teletrabajo es seguir haciendo estadística en mis ordenadores. Esta vez he tenido un dos problemas. Fedora ha tardado en introducir la versión 4 de R en sus repositorios, y eso ha supuesto dos dificultades en momentos distintos.
Primer peoblema; al haber instalado Fedora 32 de manera limpia, he tenido que instalar de nuevo R sin paquete alguno, por lo que los tuve que añadir todos, que son bastantes.


La versión 4.0 ha introducido algunas características especiales que hacen que la mayor parte de los paquetes tengan que actualizarse, y como yo aun estaba en la 3.6.3, muchas veces me he encontrado en los repositorios con el mensaje de "no hay versión para R 3.6.3". Normalmente cambio de espejo y voy a Nueva Zelanda, de donde R empezó, y suelen tenerlo todo, pero esta vez no ha sido así. Y eso obliga a bajar el código fuente de la versión anterior e instalarlo, a veces con problemas de dependencia. Un pequeño problema...
Segundo problema, después de haber solucionado el primero; ayer R puso a nuestra disposición R 4.0.2. Una vez instalada la versión 3.6.3 y todos los paquetes que uso, al actualizar el sistema, y cambiar R, empezaron los siguientes problemas. Muchos de los algoritmos que he estado utilizando estos días, (MCA, Cluster...) han requerido versiones preparadas para la versión 4 de R. Teóricamente se debería haber solucionado con update.packages(), pero no es así. He tenido que ir instalando paquete a paquete, uno a uno, con infierno de dependencias de hasta 7 niveles de profundidad. Por suerte, al haberlo hecho por la mañana en el ordenador del trabajo, ya dejé apuntadas las ramas de los árboles de dependencia, y en vez de dos horas he tardado una en casa por la tarde (ahora, desde que nos dejan mover, solo teletrabajo por la tarde), pero he acabado con 4 páginas de ramas hasta terminar el árbol de dependencias.
Es lo que hay. ¿Por qué no se ha solucionado con update.packages? ¿En que me he equivocado? Si lo llego a saber, lo desinstalo todo y lo vuelvo a instalar desde el inicio, y no me aparecería continuamente, más o menos, por que no me acuerdo exactamente (y en inglés, claro),
"El paquete x, es necesario para instalar el paquete y; la versión disponible es anterior a R v 4. Por favor instale una versión más moderna..." decenas de veces, y hasta 7 veces z, para y, b para z, d para b, k, para d... Y en Linux, no como en Windows, los paquetes se compilan.
Como antiguamente en Linux, más o menos
Eso sí, esta vez RStudio no ha protestado.

lunes, 6 de abril de 2020

RaspberryPi 4 en un Pi-topCEED

Como había dicho hace unos días, tenía algunas cosas pendientes y he estado solucionando algunas. Empecemos por RaspberryPi 4. La verdad es que tengo muchos RaspberryPi. Para ser exactos tengo 2 2B, 2 3B y un 4B. ¿Para que los uso? Realmente los usaba fundamentalmente para recrear lo que hago en las prácticas que imparto en un equipo menos potente para comprobar que lo que hago se puede hacer en los ordenadores de las salas de informática. Estas salas de informática han sido transformadas en los últimos años y como tenemos equipos modernos y relativamente potentes, en estos últimos cursos no he necesitado hacer este control previo. La segunda utilidad para mi es usar Debian. Estoy usando Fedora desde finales de 2011, y el universo Fedora/rpm es muy distinto, en el terminal, claro, que el Universo Debian/deb (algunos, la mayoría, dirían Ubuntu/deb). Es decir, usar de vez en cuando Debian me refresca un poco en apt-get y todas esas cosas que formaban el universo Linux en el que entré. Hay gente que lo usa como servidor de red, pero no es mi caso. Otros preparan camaras de vigilancia, robots etc... Tampoco es mi caso; en estos momentos los tengo como mero juguete para divertirme cuando tengo tiempo. El mes de junio de 2019 me compre el último, un 4 modelo B con 4GB de RAM, que ya es una máquina con ciertas prestaciones, pero no lo había sacado de la bolsa desde ese día. Aprovechando este aislamiento, ayer, Domingo de Ramos, decidí no teletrabajar más, después de la Misa del Papa, estuve reparando muebles, arreglando la wifi —eso lo dejamos para la siguiente entrada— y sacando de la bolsa el raspi. Me había comprado el kit completo en kubii, la tarjeta-ordenador, alimentador, caja, adaptador USB a USB-C, y al cable HDMI a microHDMI. La idea era ponerlo al lado de mi ordenador principal, usándolos simultáneamente, sirviéndome del mismo monitor Philips 241P. Este monitor tiene muchas entradas de vídeo, y mi ordenador principal usa la HDMI desde su salida DisplayPort. Eso deja libre una DVI que podría conectar al Raspberry y luego ir indicando al monitor lo que quisiera que me enseñase cada vez. Sin embargo, yo siempre tengo al lado de mi ordenador un pi-topCEED con un RaspberryPi Modelo 3B con el que juego un poco cuando tengo tiempo.


Así que en vez de compartir monitor me propuse reutilizar el pi-top para el nuevo Raspi. Como ya ha publicado pi-top, se puede incorporar sin muchos problemas un Rasp4 al pi-top3, el portátil que se había creado basado en un rasp3, así que no debería haber problemas "técnicos" en el uso del rasp4 en el pi-topCEED. Los problemas fueron físicos, de espacio. Primero, la orientación física del rasp4 es diferente al rasp 3, así que la parte con la conexión ethernet, que ocupa algo menos que los doble USB están cambiado de lado y el rasp4 entra con dificultad por que la entrada es más estrecha justo ahí, pensando en el ethernet que tenía el rasp3. Bueno, empujando con cuidado entra.


El segundo problema es que la entrada de imagen en el pi-topCEED es un HDMI-HDMI y como la conexión se debe colocar en un sitio estrecho, trae un cable con entradas en ángulo que favorece la colocación.


El cable que compré esta pensado para su uso en una caja externa y es muy grande y gordo, así que la primera intención fue pedir por Amazon un posible cable adaptador, pero con la alerta, no me llegaría hasta no se sabe que día, así que anulé el pedido y me armé de cuchillo y tornillo y decidí hacerle una entrada al pi-topCEED. No ha quedado muy bonito, por que no tenía las herramientas necesarias, pero es la parte de atrás y no se ve, y es solo un recorte de plástico.



Para verlo mejor, desde delante queda mejor. Si nos fijamos un poco, vemos que la conexión microHDMI está un poco forzada (véase flecha roja), pero no quería perforar más.


Lo más importante, FUNCIONA. La primera foto puesta en esta entrada es de hecho la configuración del Raspbian en el Raspi4, pero tengo más


no será por fotos...
No sé si tendré mucho tiempo para probarlo. El verdadero interés para este RaspberryPi 4, que ya presenta una cantidad de memoria suficiente para hacer muchas cosas para usuarios normales, además basado en un Debian que precisa pocos recursos, sería preparar un portátil barato y funcional. El problema es que el pi-top4 no está pensado como tal y no parece que lo vayan a hacer; el pi-top3 se puede adaptar, pero de manera algo complicada y el precio hace que con ese dinero te puedas comprar un portátil básico pero funcional. Veremos que depara el futuro al raspberry.

jueves, 26 de marzo de 2020

Aislado, y ninguna entrada. La razón es la siguiente

Bien, pues sí, ninguna entrada en más de un mes. Llevo varios días pensando que podía escribir, pero voy a decir la verdad, no hay nada nuevo. Este blog se creó para apuntar las dificultades sobre el uso de un usuario normal en Linux. Por aquel entonces estaba casi de estreno en Linux —no te echamos de menos, Ubuntu— y descubrí que era mucho mejor escribir las soluciones en un blog que apuntarlas en un papel. Sirven a más personas y no hay que preocuparse de donde apuntaste tal o cual solución. Pero en estos momentos he llegado a un punto en que no hay nuevas dificultades o son las mismas de siempre, y no las vamos a contar dos veces. De hecho, yo me leo a mi mismo muchas veces para recordar como habíamos solucionado tal o cual problema, pero no tengo muchas cosas nuevas que contar. En las siguientes entradas hablaré del uso del dúo gimageReader + Tesseract, pero aún estoy en ello. Han aparecido algunas dificultades; cuando las solucione, haré un minitutorial por si le sirve a alguien. Tengo que añadir que a nivel de sistema operativo, Fedora+Gnome han llegado a un punto de aplicabilidad en el que estoy cómodo y sin preocupaciones; todo funciona muy bien, lo que lleva a esas pocas entradas.


Eso no quiere decir que no esté aprendiendo cosas nuevas, pero son muy especializadas, y nunca he considerado que los usuarios normales estén muy interesados en qué comando de un paquete extrae las pruebas de pares de la prueba tal del otro paquete, o que argumento de un comando de un paquete de R hace que la letra salga del tamaño que quieres o como logras que un título de eje entre en la ventana del gráfico. Por que esa es la verdad, ahora me paso la mayor parte del tiempo haciendo estadística en R y RStudio.


Podíamos decir que me he superespecializado y, aparte de las clases, dentro de mi rango de conocimiento —epidemiología parasitaria en animales domésticos, y a veces también silvestres— realmente en estos momentos yo solo diseño estudios y muestreos que luego llevan a la realización de pruebas estadísticas. Y eso interesa a un número muy pequeño de personas —a veces ni a los que trabajan conmigo—. Y es lo que estoy haciendo en mi aislamiento; llevo varios días haciendo las mejores gráficas que expresen lo que pruebas multivariantes muy complejas han extraído. Por supuesto también estoy buscando la forma de intentar compensar de forma no presencial las clases teóricas —eso es fácil, por que normalmente tengo desarrolladas Unidades Didácticas completas de todas mis materias— y prácticas —en eso estoy pensando, como trasladar lo que hacemos con R y RStudio en una sala de informática mediante plataformas virtuales, tutoriales...—. Como veis, muy poco útil, creo yo, para los lectores habituales de este blog. No lo voy a dejar, pero las entradas saldrán cuando haya algo que contar con utilidad, más alguna salida de tiesto sin sentido, como me pasa a veces.
También es verdad que cuando llego a ese estado de comodidad, a lo mejor hay que cambiar a algo nuevo, salir de la zona de confort y sufrir con novedades, por ejemplo, Windows 10 o un Mac. Nunca se sabe...

PD. Si tengo tiempo, por que aun aislados teletrabajamos un montón, puedo probar varias cosas, pero no prometo nada, por ejemplo:
- RaspBerryPi4; tengo 2 desde que salieron y aun no he tenido tiempo de hacer algo útil con ellos
- Hacer un NAS sencillo en un solo disco duro utilizando la entrada USB del router y ver si me sirve para algo. Mi ordenador no tiene más entradas SATA y estoy en un cuello de botella con 4 discos duros magnéticos y uno sólido que suman 22,5TB. Increíble, pero cierto, a más tienes, más necesitas
- Mostrar diferencias, si las hay, al poner home en un SSD, como tengo el sistema. El disco —V-NAND SSD 860 QVO SATA 6Gb/s de 2 TB— lo tengo en una caja desde hace dos meses y estoy esperando a Fedora 32 o a tener tiempo para ponerlo. Hasta ahora he usado discos WD Black para eso, pero en ocasiones veo bloqueos en el trabajo y segundos de congelación. Seguro que se debe a los arreglos provocados por los problemas de seguridad de los procesadores Intel, pero tengo ganas de probar que el disco de sistema y el de trabajo sean ambos SSD
- Poner una controladora para aumentar el número de discos
- Mejorar mis conexiones WIFI, que me tienen a mal traer en mi casa a pesar de tener instalados 1 repetidor y un duplicador PLC
- Criticar cruelmente mi MX475, que ya ni imprime; la dejo con vida por que escanea

Se admiten sugerencias

jueves, 30 de enero de 2020

Reordenar las pistas en un fichero mkv

En estas últimas semanas he tenido un pequeño problema en la manera de reordenar las pistas en ficheros matroska. Todo nace en que una de mis televisiones no lee formato flac de sonido. A los ficheros matroska con alguna pista de sonido con formato flac suelo extraerle la/s pista/s flac (para más detalles, ya lo hemos visto aquí):


mkvextract origen.mkv tracks x:salida.flac

y convertirlas a aac con soundkonverter, una máscara gráfica de diferentes conversores de audio, muy fácil de usar, que permite muchos tipos de codificación y facilita la configuración de la transformación con mucho detalle.
Una vez transformadas, simplemente inyectamos la pista aac en el fichero matroska a través de MKVToolNix Gui, de una forma gráfica y mucho más sencilla que mkvmerge.


Una vez insertada, la colocaba en la posición que deseaba simplemente picando con el ratón y moviéndola a mi gusto. Sin embargo desde hace alguna versiones no es posible recolocarlas de esta manera. No tiene más importancia, pero en ocasiones nos interesa colocarla en algún lugar particular, por ejemplo para que sea la segunda pista de sonido, justo después de la predefinida, o para que se pueda ver entre un montón de pistas, cuando por ejemplo hay muchos subtítulos. Pues ayer decidí comprobar por fin de qué manera se puede mover las pistas sin la ayuda del ratón. La forma más fácil es mantener pulsado Ctrl y ordenar mediante las flechas direccionales. Para más información para curiosos, os dejo el enlace a este vídeo que es bastante aclaratorio. No me han funcionado todas las maneras indicadas en él, pero ahora ya puedo volver a colocar las pistas como quiero. ¡Qué cosa tan sencilla y lo que he tardado en averiguar como funcionaba!