Fedora 28. Problemas asociados a sudo (o no?) y otras menudencias

Como ya habíamos mencionado en la entrada anterior, Fedora 28 Workstation Live instala un Linux sin usuario administrador. Eso solo me ha pasado con uno de mis ordenadores, al que cambié el SSD del sistema por necesidades de espacio —esta es otra historia que si tenemos tiempo contaremos algún día— y lo instalé de nuevo desde un Fedora 28 Live. Lo primero que hice tras la sorpresa fue crear un usuario root desde sudo. Sin embargo, esta situación genera un problema; todo lo que realizábamos como root ahora tiene que hacerse desde sudo (configurar cortafuegos, llamar a aplicaciones de sistema...). Pero además me encontré con dos problemas nuevos:
1. Amule tomaba el control de sistema hasta su congelación completa. Este problema se soluciona poniendo emule por wine (véase aquí), pero solo fue necesario una semana, por que era un "bug" de amule que ya ha sido controlado en su última actualización. Pero este era el menor de los problemas...
2. Este segundo problema era doble. Si lanzaba nautilus (ahora denominado "Gnome Files" o Gnome Archivos) tardaba horas en aparecer de forma gráfica, lo que me obligó a instalar Thunar para poder trabajar de forma gráfica. Curiosamente, si lo lanzaba desde root aparecía inmediatamente, pero no debemos trabajar como administrador con nautilus. Pero aún hay más; tanto con nautilus (al día siguiente de haberlo lanzado) o con thunar, al copiar cualquier bloque mayor de 1 GB, cuando llevaba unos segundos copiando, se congelaba el sistema de manera completa, sin respuesta a Alt+F2, Ctrl+Alt+Fx ni a las teclas mágicas REISUB, lo que obligaba a reiniciarlo por las "malas" (y la pérdida de ficheros de los discos duros que se estaban copiando en ese momento). Este segundo problema me ha tenido preocupado hasta esta semana, por que en pleno fin de curso el trabajo aprieta y no podemos arriesgarnos a que una instalación no salga a la primera. Esta situación se ha encontrado en muy pocas ocasiones con diferentes causas:
- Tarjetas Nvidia. No es el caso, por que este ordenador lleva un i7 3770 con HD4000 integrada y nunca he tenido problemas gráficos.
- Errores asociados a Nautilus (véase bug 1208993 o bug 1133477). Parece que nautilus llena la memoria del sistema antes de enviarlo a la copia física al dispositivo destino y el sistema se congela. En algunos de estos casos recomiendan controlar el máximo de memoria que puede ocupar estas "dirty pages" en /etc/sysctl.d/90-override.conf (o el fichero de configuración inicial que use cada uno) mediante
vm.dirty_background_ratio = 5 # Memoria total que se puede llenar hasta copiar en el dispositivo destino
vm.dirty_ratio = 10 # Memoria total que se puede llenar con las "páginas sucias"
En mi caso he intentado superar el problema dando diferentes valores (5-10, 10-20, 20-40... a esta configuración sin resultado (si se quiere mirar algo más sobre esto, mirar aquí).
Ahora que he podido reinstalar el sistema de nuevo, en este caso desde el formato netinst, con root como siempre y sin abrir sudo a nadie, todo funciona correctamente.

Como todo lo demás es igual, ¿quién era el culpable? Así que no nos interesa sudo. Si fuera así instalaríamos Ubuntu, y no es el caso.

Error en gnome-boxes bajo Wayland

He encontrado un problema en la ejecución de una máquina virtual en gnome-boxes en Fedora 25 utilizando Wayland. Más o menos resulta que tras la ejecución de gnome-boxes en terminal (si lo ejecutamos pinchando en el icono no se pueden leer los errores), al lanzar la máquina (en este caso Windows XP, para probar un programa), el sistema operativo comienza a cargarse y ahí se queda horas o días.

Podemos ver un error crítico en el terminal:

gnome-boxes:2361 Gtk-CRITICAL:gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed

Debe ser un bug que viene de atrás, desde Fedora 22, y que está indicado aquí.
Tenemos dos soluciones:

La primera, recurrir a virt-manager, con el que la máquina virtual funciona como se esperaba,

o volver a X11 en gnome y boxes funciona adecuadamente (errores no críticos más o menos),

A Wayland aun le falta un pequeño empujón.

Sistema no arranca... a la primera. ¿kaslr disable o algo más?

Las cosas son así. Mi ordenador de trabajo no arranca al primer intento desde hace bastante tiempo, y suele arrancar después de un reset —a veces más de uno—, detectando la BIOS y siguiendo el patron natural de arranque. Por supuesto, se debe a que tiene 10 años, un disco de arranque WD raptor a 10.000rpm, una joya en su momento pero ahora con un sector erróneo y con avisos de muerte continuos, todo debido a falta de presupuesto. Por ello no me extraño al tener que resetear el equipo los lunes —solo lo apago los viernes, al terminar la semana de trabajo—. Sin embargo la semana pasada apareción un nuevo mensaje, de manera muy fugaz, apareciedo unos milisegundos antes de quedar la pantalla en negro

kasrl disable

Este mensaje se debe a un bug conocido en Fedora desde la actualización del kernel a 4.7.2-200.fc24. kasrl de refiere a la localización en memoria del kernel —Kernel Address-space layout randomization KASLR—. Una localización aleatoria dificulta el ataque sobre el kernel.

En mi caso dudo que que mi problema esté en este bug, ya que depende de que esté admitido la hibernación, que no es el caso; además, con uno o más resets arranca, así que lo mío sigue siendo "achaques de edad".

Fedora 20: solución para los errores en la instalación/actualización de paquetes de los últimos días

Desde hace dos días estaba teniendo problemas en las actualizaciones de los paquetes, obteniendo avisos como este:

...
Actualizando  : 32:bind-libs-lite-9.9.4-11.P2.fc20.x86_64               30/82
warning: %post(bind-libs-lite-32:9.9.4-11.P2.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package 32:bind-libs-lite-9.9.4-11.P2.fc20.x86_64
...

y como ese otros 41. Como ejemplo, un terminal (actualizo siempre en terminal con un simple su -c 'yum -y update')

Como saben todos los usuarios de Fedora, a veces aparecen errores en las actualizaciones, debidos en general a que uno de los paquetes necesarios no ha sido actualizado aun o por alguna dependencia no cubierta; en general, estos problemas se solucionan en uno o dos días, así que no le había puesto importancia. Sin embargo, como hoy era ya el tercer día con el mismo error, he realizado una búsqueda en la red, para ver que se comentaba sobre este error, y me he encontrado con la solución.
"This issue was resolved by selinux-policy-3.12.1-117.fc20 an update to SELinux policy."
Es decir, es un pequeño error en selinux-policy-3.12.1-116.fc20, y este error genera un fallo en los scripts de instalación y actualización en Fedora, de tal manera que no se puede actualizar tampoco selinux-policy y el error se mantiene en un bucle.
Para solucionarlo, en esa página nos indican que primero tenemos que desactivar SELinux

# setenforce 0 # como administrador o con su -c o sudo

borrar los caches de yum

# yum clean expire-cache

actualizar a selinux (paquetes corregidos sin bug)

# yum update selinux-policy\*

activar de nuevo SELinux

# setenforce 1

Y listo. Ya podemos actualizar correctamente. si alguna instalación ha fallado estos días, instalar esos paquetes mediante

yum reinstall paquete-en-cuestión

Errores en amule

La técnica ed2k sigue presentando dificultades para un uso correcto, y no solo las presiones legales o los bloqueos de las compañías que suministran conexión. En concreto, como ya he señalado hace unos meses, amule tiene una tendencia a cortarse de forma aleatoria y persistente. Sin ir más lejos, de ejemplo un botón ...

Cada una de esas líneas se corresponde a un cuelgue de amule y su reinicio automatizado con el script con el que llamo al programa y que automáticamente controla que esté funcionando (véase aquí). Si no he contado mal, son 17 cortes en unas 32 horas tras la última actualización y reinicio del sistema. En ocasiones falla delante de mis narices, cosa que sé por que de repente su ventana aparece delante de mi cuando estoy trabajando en otras cosas, pero la mayor parte de las veces falla el solito, sin presión de otras actividades. El mayor problema es que estos errores no pueden ser enviados automáticamente a un sistema de control como bugzilla y por ello amule tiene estos fallos. A ver si con Fedora 20 hay una actualización de amule y se corrige, al menos en parte, estos errores, bichos, "bugs" o como los queramos llamar.

Error al actualizar smart

Después de manipular una tarjeta SD para recuperar fotos perdidas, al manejar Discos (antes Palimpsest) para montar y desmontar la tarjeta me di cuenta que mi disco de sistema en uno de los ordenadores de trabajo mostraba un sector erróneo. Como es un disco bueno (Raptor 10.000 rpm) pero antiguo (7 años aproximadamente), quise hacerle una prueba smart. La ventana indicativa de smart aparecía vacía (por no decir que tambien dice en la parte superior que el chequeo smart no se ha actualizado en ese disco en 43 años).

Al ordenar la actualización de las pruebas smart, aparece un error

Por lo visto es un error que se describe en las listas de errores -bugs- de Fedora y Ubuntu.
Aunque parece que ya han descrito un parche, prefiero que lo incluyan oficialmente. Como es un ordenador de trabajo, pero que no contiene datos valiosos que no estén actualizados en mi ordenador personal, lo dejaremos con su sector erróneo hasta que falle definitivamente.
Curiosamente, no aparece en todos los discos, ya que en el mismo ordenador, no muestra ningún error al examinar el disco home (otro WD, en este caso Caviar Green) y se actualiza rápidamente.

Si no fuera el disco de sistema, lo probaría en otro ordenador, y si sigue dando el mismo error, podría probar otra distribución o algún CDLive de prueba. Por otro lado, como el tiempo pasa y ese disco ya tiene unos añitos, y teniendo en cuenta que ese ordenador no guarda nada importante que no esté en mis copias de seguridad, podemos esperar tranquilamente a que "muera" plácidamente. Funciona (por ahora), así que no lo toques.

Bug de nouveau en kernel 3.6.2-4 - segunda parte

Segunda vez; al actualizar a 3.6.2-4, pensando que podría ser una solución, mismo fallo, seguramente por algún error en nouveau. Arranque aparentemente norma, y tras la aparición del escritorio gráfico, el ratón se comporta de forma errática y cae el sistema gráfico. En una pantalla de texto aparece repetidamente

[ 193.685566] [drm] nouveau 0000:01:00.0: Failed to idle channel 1.
[ 197.674451] [drm] nouveau 0000:01:00.0: PFIFO - playlist update failed
[ 200.665865] [drm] nouveau 0000:01:00.0: Failed to idle channel 2.
[ 204.654740] [drm] nouveau 0000:01:00.0: PFIFO - playlist update failed
[ 225.531669] [drm] nouveau 0000:01:00.0: Failed to idle channel 1.
[ 229.520608] [drm] nouveau 0000:01:00.0: PFIFO - playlist update failed
[ 232.511956] [drm] nouveau 0000:01:00.0: Failed to idle channel 2.
[ 236.500836] [drm] nouveau 0000:01:00.0: PFIFO - playlist update failed

...

A ver como sigue el asunto.

Fallo tras actualización a kernel 3.6.1-1

al comenzar hoy con el ordenador tenía un aviso de actualizaciones. Como de costumbre, anulo el PackageKit y a través de terminal ejecuto

yum update

Y veo que ya está la actualización al kernel 3.6.1-1 y a Firefox 16.0.1. como siempre, en Fedora las actualizaciones a toda velocidad. Perfecto. Actualizo y, al reiniciar, el ratón se comporta de forma extraña, con el disco duro rotando a alta velocidad y sin parar, hasta que finalmente salta un pantallazo en negro con aparición de errores. No los he podido ver todos, ya que el monitor oscilaba y desaparecía y aparecía

Como es natural, he enviado un aviso a bugzilla, pero por lo que veo ya es un aviso repetido, así que no he sido el único. Como se puede ver, el kernel está instalado,

pero para que todo funcione arranco con el 3.5.4-2

Es un pequeño precio que pagamos para poder disponer de la distribución más actualizada.

Fallo en el arranque: kernel 3.5.4-1

En estos momentos trabajo diariamente con 4 ordenadores en los que tengo instalado Fedora 17. Por alguna circunstancia extraña, desde la actualización del kernel a 3.5.4-1 he tenido un error en el arranque del único ordenador en el que tengo instalada la versión de 32 bits. Al intentar arrancar surge un mensaje de error como este

y en el se queda. Por suerte, arranca si elijo la versión anterior, 3.5.3-1. La verdad es que estoy tan ocupado que no me ha dado tiempo ni de buscar este error en la red ni de enviar el mensaje de error a Fedora. Sin emabargo, desde la actualización a 3.5.4-2 todo vuelve a funcionar, así que no me voy a preocupar más. Alguien con el mismo error y con más precupación por los demás ha enviado el mensaje adecuado. Gracias, a quien haya sido.

Bugs en parejas (ACTUALIZADA)

Desde la vuelta de vacaciones me he encontrado con dos bugs recurrentes en mi ordenador. El primero, 

en el Firefox 15. Al cerrar algunas pestañas -no todas- recibo un mensaje de error

"TypeError: can't access dead object"

y Firefox no responde más y me obliga a matar el proceso

$ pkill firefox

y volver a cargar el navegador. Como podéis ver aquí, aquí y aquí, es un bug conocido, pero aun no resuelto definitivamente (en estos momentos).
Esto es solo una molestia, pero tengo un segundo mucho más importante. Cuando muevo gran cantidad de material multimedia (vídeos, fundamentalmente) entre los discos duros del ordenador o desde ellos a un dispositivo externo me aparece un pantallazo negro con un mensaje que empieza así

Cannot open font file TRUE

[14739.075842] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[...] IP: [] ext4_ext_remove_space+0xa34/0xdf0
[...] Oops: 0000 [#1] SMP 
[...] CPU 2 
 

 y se prolonga muchas líneas.
La primera línea es un mensaje conocido que puede ser corregido fácilmente (véase aquí).
Sin embargo la segunda es un casi un kernel panic. Si bien es cierto que podemos recuperar la pantalla gráfica mediante Ctrl+Alt+F7, el ordenador no se puede manejar y hay que terminar con las teclas mágicas AltGr+Imp pant+R+E+I+S+U+O. Es un bug conocido (como éste, por ejemplo). Aunque las condiciones en que se me manifiesta a mi no son estrictamente iguales, espero que sea ese mismo y se haya corregido en el kernel 3.5.3. Lo comprobaré. De todas maneras he enviado un comentario a Red Hat Bugzilla.

ACTUALIZACIÓN: tras la actualización del kernel a 3.5.3 no se produce el "kernel panic" y el movimiento o eliminación de ficheros grandes se produce sin fallo.

Debian 6 en Aspire. Capítulo 2

Esta noche pasada he realizado un segundo intento, esta vez en un lápiz USB de 8GB, por si el hecho de no instalar el GRUB se debía a una limitación de tamaño. He pedido la instalación sencilla, muy parecida a la de Ubuntu. El resultado ha sido el mismo que con el de 4GB. Después de dos horas de bajar paquetes (1149) y configurarlos aparece un mensaje de error de que no ha podido instalar GRUB en el disco (en este caso lápiz USB) y no se puede tampoco instalar un arranque LILO. Por más que se intenta solucionar el problema a diferentes niveles de instalación, acabamos siempre en ese mensaje y hay que interrumpir la instalación (última línea). Es un bug del paquete de instalación, ya que si se hace sin pedir la réplica de red, sí termina con el arranque. El problema es que el sistema instalado en esas condiciones es muy limitado, sin control de administración, sin paquete gráfico de instalación y sin control de Origen de Software, lo que exige que aprendamos más sobre Debian (estamos mal acostumbrados a la facilidad de Ubuntu). El siguiente intento será hacer esa misma instalación sobre el mismo lápiz (así quemé el HyperX, de tanto actualizar las PortablesApps) desde el CD 1 de Debian. Para ello usaré una grabadora LG IDE que tengo suelta por ahí a través de un cable Conceptronics que me permite usarla a través de uno de los puertos USB del Aspire. Esperando tercer capítulo.
Si todo sigue fallando, ya he recibido el número 71 de Linux Magazine, y viene un DVD con Trisquel 4.5, así que esa es otra posibilidad.