Para aquellos fans de Fedora que aún no hayan actualizado a Fedora 30, vamos a describir los problemas que me he encontrado en la actualización y luego en la instalación. Tranquilos, nada nuevo que no hayamos visto:
Primera fase: actualización. El día de salida de Fedora 30 mi página web base, Fedora magazine, señalaba ya la posibilidad de actualizar. Como estaba tranquilo tomando un café nocturno, decidí seguir la corriente... ¿qué son 45 minutos? Siguiendo las indicaciones habituales, primero actualicé completamente el sistema,
su -c 'dnf -y update --refresh'
luego instalé el plugin de actualización,
su -c 'dnf install dnf-plugin-system-upgrade'
comencé la actualización, que lo que hace es bajar las actualizaciones de TODO,
su -c 'dnf system-upgrade download --releasever=30'
esta vez no fue necesario incluir --allowerasing, supongo por que no encontró problemas de dependencias ni paquetes sin sustitución; por cierto, tardo solo 4 minutos, con una red que alcanzaba picos de 42MB/s
y finalmente ejecutamos la actualización
su -c 'dnf system-upgrade reboot'
Tardó 23 minutos y ahí se acabó, por que el sistema gráfico no volvió a arrancar. Las condiciones de ese equipo son Intel i7-3770 con hd400 integrada y 24Gb de RAM. El sistema sí funcionaba, por que el terminal 1 y los de 3 al 7 funcionaban, pero el 2, que lleva el sistema gráfico, al poner la palabra de entrada, volvía a pedirla una y otra vez. Después de trastear con los terminales a ver si era capaz de encontrar una solución, decidí instalar desde limpio y no, nunca arrancó el sistema gráfico con startx en los terminales.
Segunda fase: instalación de limpio (que bien, así empiezo de nuevo; eso si, ya no llegan 45 minutos).
Tras bajar una versión live y otra netinst preparé con Fedora Writer (en un portátil, claro) dos unidades USB con ambas versiones. Primero probé la versión live, a ver si era capaz de arrancar el sistema gráfico, y así fue, así que luego instalé con una versión netinst, que permite establecer usuario y administrador y deja el sistema actualizado. Una vez realizada la instalación, bastante rápida por cierto, hubo que arreglar las teclas mágicas, (línea kernel.sysrq = 1 al fichero /etc/sysctl.d/90-override.conf), aumentar los ficheros permitidos para Dropbox (añadiendo al mismo fichero una línea con fs.inotify.max_user_watches = 200000), abrir repositorios, instalar las aplicaciones que faltan y las extensiones de gnome. Cuando parecía que todo iba bien, empieza a congelarse el sistema. Siguiendo a top me encontré con lo siguiente:
es decir, un amule vacío que ocupaba toda la CPU.
Este problema ya lo hemos visto anteriormente en el verano pasado, cuando una actualización de amule nos tuvo una semana congelándonos el sistema. Simplemente dejé de usar amule y me he pasado temporalmente a emule a través de wine.
Sin embargo, ahí no acabaron los problemas. Los discos giraban como escapando de alguien y como son 5 (4 de ellos magnéticos) se oían desde el piso de abajo. Además el sistema estaba colapsado. Esto también lo hemos visto en alguna instalación limpia de Fedora; son los malditos trackers, fiscalizándolo todo; véase aquí y aquí. Como lo que hice en la primera indicación no fue suficiente, aplique la anulación de las notificaciones (segunda indicación), pero esta vez a TODAS las aplicaciones.
Una maravilla, ya me he podido sacar los cascos antirruido, y el sistema va razonablemente. y digo razonablemente por que aun no está a mi gusto. Noto ciertos retrasos en las páginas web con Firefox, me da la sensación de que va todo algo más lento. Lo de siempre, hasta dentro de un mes y un poco de pulido no estará perfectamente. En cada arranque me aparece el mensaje
Lo sentimos, parece que BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.0.9.301.fc30.x86_64 ...
aunque luego todo sigue.
Y mira que lo sé, nunca actualizar un equipo importante hasta un mes después...
PD. y el terminal... sobre el terminal haremos otra entrada, una historia para no dormir.
ACTUALIZACIÓN 2019-05-07: El problema de BOOT_IMAGE... ha desaparecido después de la actualización del kernel a 5.0.11. Un problema menos.
ACTUALIZACIÓN 2019-05-15: Sobre el terminal, en un principio no me aparecían opciones en la etiqueta Sin nombre. Fundamentalmente, lo que más me preocupaba es la parte desplazamiento y la configuración de líneas de desplazamiento hacia atrás, es decir, que número de líneas me conserva. Para los usuarios de R en terminal es básico poder mantener cientos de miles (o millones) de líneas para extraer los resultados de análisis complejos. Pero era un problema de instalación o de no reiniciar, por que cuando estaba generando una entrada disparando a matar a los programadores de gnome, resulta que sí pude acceder a esas opciones. Y para terminar, tras varias actualizaciones de kernel, Fedora 30 va ahora como la seda.
Mostrando entradas con la etiqueta tracker-miner. Mostrar todas las entradas
Mostrando entradas con la etiqueta tracker-miner. Mostrar todas las entradas
martes, 7 de mayo de 2019
Fedora 30. Algunos "problemillas"
Etiquetas:
aMule,
Dropbox,
Fedora,
Fedora 30. Actualización,
Instalación,
Instalar,
install,
Linux,
netinst,
sysrq,
tracker,
tracker-miner,
Update
jueves, 30 de mayo de 2013
tracker-miner. Alto consumo de CPU y disco duro
En los últimos tiempos estaba notando que cada reinicio del sistema el disco duro giraba a alta velocidad durante un tiempo muy largo, en ocasiones horas. Revisando top siempre encontraba tracker-miner-fs en la parte alta de la lista de procesos, indexando no se sabe que.
Hoy ya me estaba provocando dolor de cabeza (mi ordenador es muy silencioso si no fuera por el rascado continuo del disco), así que después de ver que tracker-miner es un gran consumidor de recursos, decidí eliminarlo.
Entre las diferentes opciones (véase aquí) apliqué la que me pareció mas sencilla:
$ su -c gnome-session-properties
y en la ventana eliminé directamente tracker-miner
Como el disco sonaba a muchos decibelios, así que rematé
$ pkill tracker*
Y se acabó. Ahora un simple silbido muy bajito de los ventiladores.
Sin embargo esto no es una solución, por que aparece al siguiente reinicio. Lo que he encontrado y funciona bien (una sola comprobación) es lo siguiente, tomado de bugzilla, comentario 24:
"...I had the exact same problem and appending "X-GNOME-Autostart-Delay=60" to /etc/xdg/autostart/tracker-miner-fs.desktop solved this issue. It really seems like some race condition upon startup. It is possible that some other value much lower than 60 would already suffice but for now I'll leave as is."
Es decir,
$ su -
# gedit /etc/xdg/autostart/tracker-miner-fs.desktop
y añadiruna línea con
X-GNOME-Autostart-Delay=60
justo debajo (así lo hice yo) de la de X-GNOME-Autostart-Enable=True
y en el siguiente reinicio el uso del disco duro ha sido mucho más comedido. Espero que os sirva.
Hoy ya me estaba provocando dolor de cabeza (mi ordenador es muy silencioso si no fuera por el rascado continuo del disco), así que después de ver que tracker-miner es un gran consumidor de recursos, decidí eliminarlo.
Entre las diferentes opciones (véase aquí) apliqué la que me pareció mas sencilla:
$ su -c gnome-session-properties
y en la ventana eliminé directamente tracker-miner
Como el disco sonaba a muchos decibelios, así que rematé
$ pkill tracker*
Y se acabó. Ahora un simple silbido muy bajito de los ventiladores.
Sin embargo esto no es una solución, por que aparece al siguiente reinicio. Lo que he encontrado y funciona bien (una sola comprobación) es lo siguiente, tomado de bugzilla, comentario 24:
"...I had the exact same problem and appending "X-GNOME-Autostart-Delay=60" to /etc/xdg/autostart/tracker-miner-fs.desktop solved this issue. It really seems like some race condition upon startup. It is possible that some other value much lower than 60 would already suffice but for now I'll leave as is."
Es decir,
$ su -
# gedit /etc/xdg/autostart/tracker-miner-fs.desktop
y añadiruna línea con
X-GNOME-Autostart-Delay=60
justo debajo (así lo hice yo) de la de X-GNOME-Autostart-Enable=True
y en el siguiente reinicio el uso del disco duro ha sido mucho más comedido. Espero que os sirva.
Suscribirse a:
Entradas (Atom)




