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

martes, 7 de mayo de 2019

Fedora 30. Algunos "problemillas"

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.

jueves, 15 de diciembre de 2016

sysqr no responde. ¿Dónde se activan las teclas mágicas?

Esta entrada tiene cierta relación con la anterior. En los tres ordenadores que tengo funcionando con Fedora 25, dos funcionan perfectamente con Wayland, descontando algunas alteraciones que iré explicando cuando las comprenda, pero un tercero, el más potente, el más moderno, muestra ciertas respuestas extrañas cuando está en el sistema gráfico Wayland. Fundamentalmente, el sistema muestra una granulación en el monitor y a partir de ese momento deja de responder a las órdenes gráficas y no deja llamar a un escritorio de texto (Ctrl+Alt+ F2 a F7, siendo F1 el que soporta el sistema gráfico). Este ordenador es el único que tiene una tarjeta gráfica externa, nVidia, por cierto; los demás llevan gráficas de Intel incorporadas en el procesador, y lo digo por si eso tiene que ver y alguno ve la relación. Además las primeras veces que se me bloqueó  el sistema no fui capaz de realizar una salida ordenada mediante sysrq (REISUB) y tuve que saltar el sistema con la tecla de reseteo.
Como había indicado en una entrada en la instalación de Fedora 18, la localización de los ficheros de configuración del sistema había cambiado de Fedora 17, /etc/sysctl.conf, al directorio /usr/lib/sysctl.d en Fedora 18, actuando desde  ese momento en el fichero /usr/lib/sysctl.d/00-system.conf. Y así apliqué tras la instalación de Fedora 25


y sin embargo no se ejecutaba la orden AltGr+ImpPant + REISUB.  Para comprender lo que supone, cada una de las letras ejecuta lo siguiente:

R pone el teclado en modo RAW (recobrar el control desde el entorno gráfico X al teclado)
E termina todos los procesos (end) (envía el comando Sigterm a todos los procesos, para finalizarlos ordenadamente)
I interrumpe todos los procesos (envía el comando Sigkill a todos los procesos, para forzar su terminación)
S sincroniza el disco duro (synchronize, descargar datos de la memoria a los ficheros en el disco duro)
U desmonta todos los sistemas de ficheros (unmount y volver a montar los sistemas de ficheros como de solo lectura)
B reinicia la máquina (reBoot)


Para evitar un tercer reseteo estuve evaluando los diferentes ficheros de configuración —/usr/lib/sysctl.d/— y en el fichero 50-default.conf aparece un mensaje así

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See sysctl.d(5) and core(5) for documentation.

# To override settings in this file, create a local file in /etc
# (e.g. /etc/sysctl.d/90-override.conf), and put any assignments
# there.

# System Request functionality of the kernel (SYNC)
#
# Use kernel.sysrq = 1 to allow all keys.
# See http://fedoraproject.org/wiki/QA/Sysrq for a list of values and keys.
kernel.sysrq = 16

Para que veamos lo que supone cada número dentro del sysrq, el orden es:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function description):
     2 - enable control of console logging level
     4 - enable control of keyboard (SAK, unraw)
     8 - enable debugging dumps of processes etc.
     16 - enable sync command
     32 - enable remount read-only
     64 - enable signalling of processes (term, kill, oom-kill)
     128 - allow reboot/poweroff
     256 - allow nicing of all RT tasks

Es decir, la el comando kernel.sysrq = 1 ejecutado en el primer fichero (00) de configuración es anulada por la kernel.sysrq = 16 colocado por systemd (50). Así que he sido obediente a systemd y he trasladado a un fichero /etc/sysctl.d/90-override.conf kernel.sysrq = 1, dejándolo fuera del directorio de configuración, y lo he eliminado del fichero 00. Algo exclusivo este systemd


Listo

lunes, 8 de julio de 2013

Fedora 19. Problemas -a veces- en la actualización con FedUp

El otro día había dejado una primera sensación de la instalación limpia de Fedora. Realmente, además de haber instalado un ordenador, también había actualizado otros dos con FedUp. Sobre estos dos la sensación ha sido agridulce. En primer lugar, tiene la ventaja de ser más rápida, dependiendo del ancho de banda disponible. En el caso de mi ordenador principal, con una red con fibra óptica a 100Mbps reales (en ocasiones rinde aun más) la cosa fue de minutos; no lo estaba mirando, pero creo que en media hora estaba el ordenador en marcha. Una segunda ventaja es que el sistema está como lo habías dejado, con lo que no necesitas un tiempo añadido para ponerlo como te gusta. Uno de los dos ordenadores funcionaba perfectamente, así que el resultado era perfecto y lo repetí en mi ordenador principal (que siempre toca después de haber probado con los otros y tras copia doble de seguridad). Como he dicho fue el más rápido, pero ... presentaba un problema que ya había tenido en la actualización Fedora 18; muchas veces unas aplicaciones quedaban bloqueadas por otras y solo se pueden abrir cuando se cerraban las otras. Por supuesto esta situación genera una forma muy incomoda de trabajar. En segundo lugar, al llegar a la Login Screen, donde hay que identificarse, solo tenía una pantalla gris; es usable, por que soy el único usuario, pero no es una forma cómoda de arrancar.
Por todo esto decidí instalar de nuevo desde limpio Fedora 19. Para evitar dependencias, arranque primero con una copia Live y saqué del directorio /home/usuario/ los directorios de configuración (todos los ocultos, .directorio), menos .aMule, .jd, .mozilla y .wine; moví también los fichero ocultos. Luego instalé desde la imagen 64bits Network, ya que disponía de de un buen ancho de banda. La indicación manual de las particiones fue muy sencilla; un disco sólido como sistema (formateo incluido) y swap, otro como home y dos más que se montan al arrancar el sistema anclados al directorio home. La instalación a través de la red supuso 1243 paquetes en 20 minutos y 2 minutos más de postinstalación. No hay que actualizar nada, por que ya lo instala actualizado. A partir de ahí, como el otro día. Podemos seguir la entrada de xenode, teniendo en cuenta que no todos necesitamos todo estos paquetes; lo digo por que algunos de ello necesitan las librerías qt de kde y si no las queréis instalar, debéis evitar algunos de esas indicaciones. Por lo demás es necesario

1. Añadir repositorios

2. Instalar los programas que necesitamos en nuestro trabajo/ocio. En mi caso es fundamental R (R-core, R-devel), gnumeric, Gimp, Inkscape... Cada uno con sus necesidades.

3. Instalar Dropbox, lo que genera otra vez el mismo problema de siempre de repositorios inexistentes para Fedora 19. La solución:

$ su -c 'nano -$ /etc/yum.repos.d/dropbox.repo'
   contraseña

 y añadir (cambiar) la url del repositorio

[Dropbox]
name=Dropbox Repository

# baseurl=http://linux.dropbox.com/fedora/$releasever/
 

baseurl=http://linux.dropbox.com/fedora/18/

gpgkey=http://linux.dropbox.com/fedora/rpm-public-key.asc


Además, esta vez también recibí el texto ya conocido de:

Unable to monitor filesystem
Please run: echo 100000 | sudo tee /proc/sys/fs/inotify/max_user_watches
and restart Dropbox to correct the
problem.

Para solucionar el problema momentáneamente podemos ejecutar ese comando, 

su -
    palabra
echo 100000 | tee /proc/sys/fs/inotify/max_user_watches

pero para arreglarlo definitivamente ver el punto 5.

4. Instalar instalar gnome-tweak-tools y dconf-editor (seguro que lo tenemos ya)

$ su -c 'yum -y install gnome-tweak-tool dconf-editor'
    palabra

5. Habilitar sysrc (como en la instalación anterior) ya que las "teclas mágicas" están sin habilitar (que sería de nosotros sin nuestro Ctrl+Alt + REISUO/B y otras maravillas). Esta vez el fichero aun viene más minimalista, no se llama sysctl.conf y no está en etc. Haremos

$ su -c 'nano -$ /usr/lib/sysctl.d/00-system.conf'
    palabra
y añadiremos unas líneas como estas

# Control de sistema (solo para informar)
kernel.sysrq = 1


y ya que estamos aquí, añadimos además esta otra línea


fs.inotify.max_user_watches = 100000


para solucionar el límite de ficheros controlados por dropbox




y listo al reiniciar.
Ahora perfecto. Se añaden en firewalld los puertos que necesitamos abiertos (no olvidar de hacerlos persistentes, ya que si no solo los podremos usar esa sesión).
Y para terminar, las extensiones de gnome. Esta vez me he limitado a:
- Brightness control
- Hide top bar (fundamental)
- No Top left Hot Corner
- Removable drive menu
- Trash
- User themes (aunque este sigo sin saber por que lo pongo, si nunca añado temas)

Tiempo exacto para todo esto: desde las 21:58 a las 23:55 (1 hora y 57 minutos). Solo me falta lograr en Fedora un arranque en texto para ver todas las líneas de ejecución, que me gusta más que ver una pantalla sin nada interesante, y eso que en este ordenador no dura más de 10 segundos.


jueves, 2 de febrero de 2012

Fedora. Habilitar sysrq

Desde que uso Fedora no he tenido una necesidad de usar nuestro famoso REISUO hasta hoy. sin embargo, en Fedora no están habilitadas las teclas "mágicas", así que no podemos usarlas. Es muy recomendable activarlas para no tener que reiniciar con la tecla de Reset como me ha pasado hoy a mi. Es sencillo editando de nuevo sysctl.conf:
- Terminal; nos identificamos como administrador
$ su -
palabra
# gedit /etc/sysctl.conf
y ponemos el valor de 1 a kernel.sysrq


tras el reinicio ya están disponibles las teclas mágicas (y REISUB/O).