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.

Nautilus. Problemas... ¿con vlc?

Desde hace un tiempo —largo, no me acuerdo cuando empezó— estoy teniendo problemas con nautilus. El sistema —Fedora 25, pero también con 24 y 23...— se inicia, llamo a nautilus, trabajo en lo que sea y, tarde o temprano, nautilus se bloquea y hay que recurrir al teminal y matarlo

killall nautilus

Debido a ello normalmente llamo a nautilus desde el terminal, para leer los errores y comprender que pasa. En general los errores son del tipo

Stream with high frequencies VQ coding
libpng warning: iCCP: known incorrect sRGB profile

que asocio a un plugin de conversión de imágenes,

[00007f5f38d31c08] core decoder error: failed to create audio output
[000055be0e896ee8] pulse audio output error: digital pass-through stream connection failure: No soportado
[000055be0e896ee8] core audio output error: module not functional
[00007f5f38d57de8] core decoder error: failed to create audio output

que asumo que es algún sonido con codec no soportado,

pero cuando se bloquea todo los errores suelen ser

VLC media player 3.0.0-git Vetinari (revision 2.2.0-git-10582-g9eb9eb0bd2)
[00005596eb6311c8] core libvlc: Ejecutar vlc con la interfaz predeterminada. Use «cvlc» para usar vlc sin interfaz.
Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
QObject::~QObject: Timers cannot be stopped from another thread

que deberíamos asociar a VLC. El problema está en que muchos bloqueos se hacen sin que haya llamado a VLC o a cualquier vídeo.

Lo llevo con resignación. Una pequeña cruz de cada día

Actualización a Fedora 22: fedup

Como había dicho ayer, he actualizado mis ordenadores principales mediante fedup.

http://kuboosoft.blogspot.com

Más rápido, más productivo, menos tiempo perdido. Para actualizar mi ordenador de trabajo utilicé las técnicas que ya había utilizado en las versiones anteriores. Sin embargo, como ya habíamos indicado, la mayor parte de los comandos, si el sistema está actualizado, no son necesarios, así que el ordenador de casa, que además es el más potente, decidí actualizarlo de una forma mucho más sencilla. En primer lugar actualicé Fedora 21:

su -c 'dnf -y update'


luego instale fedup

su -c 'dnf install fedup'


y finalmente di la orden de actualización

su -


fedup --network 22

Listo. Descargó 2526 paquetes, con algo más de 2GB. En algún caso no encontraba paquetes similares a los buscados y generó algunos errores, pero la actualización funcionó adecuadamente. Ese ordenador estaba con KDE, y la nueva apariencia de ese escritorio no me gustó, así que instalé inmediatamente gnome y algunos añadidos imprescindibles

su -c 'dnf groupinstall gnome'

su -c 'dnf install gnome-shell-extension-common dconf-editor gnome-tweak-tool'

Como me pasa siempre con gnome en ese ordenador, nautilus se congelaba. Esta vez guardé los errores, en concreto

(nautilus:3226): Gtk-WARNING **: Failed to register client: GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register client
Initializing nautilus-dropbox 2.10.0

que por lo visto es un bug conocido.

La solución, después de bucear por la red (aquí), fue la eliminación completa de nautilus

su -c 'killall nautilus'

su -c 'dnf remove --purge nautilus'

y su instalación de nuevo

su -c 'dnf install nautilus'

Funciona. Por cierto, un nautilus más minimalista que nunca. Por tener, ya no tiene ni opciones y hay que buscarlas en dconf-editor

 

Luego solo hizo falta actualizar las extensiones de gnome en el navegador y activarlas en las tweak-tools y listo. En una hora los equipos trabajando.

Algunas "herencias" molestas a través de FedUp

Hasta hoy había actualizado tres de los 4 ordenadores con los que trabajo habitualmente con FedUp. Sin embargo, la actualización mantiene ciertas "herencias" cuya actualización da lugar a algunos problemas de compatibilidad, aunque no lo puedo probar. El principal problema aparece en el uso de nautilus, que se corta y después no aparece de forma gráfica al picar el icono. En uno de los ordenadores, que tiene un gnome limpio, no aparece; en el segundo, con gnome, más la presencia de nemo desde hace tiempo, nautilus falla aleatoriamente. En el tercer caso, con gnome+kde y con nemo, el error aparece solo en gnome al usar nautilus y nunca en kde.

Aunque no estoy seguro, creo que se debe a que la presencia de nemo genera ahora la instalación de parte (o todo) el escritorio cinamon, y se debe general alguna "incompatibilidad" con gnome shell. He reinstalado de limpio (Fedora 20 DVD live 64bits) el segundo ordenador, gnome + nemo, y funciona muy fluido, y hasta diría que más rápido, sin inconsistencias ni la desaparición de nautilus. Esto me llva a pensar en instalar también de nuevo en el tercer caso, ya que aunque me ha adaptado al uso de KDE, y reconozco que es un escritorio completamente funcional y válido en máquinas potentes, realmente no me gusta.
Como estoy algo "atado" por el trabajo, probaré primero en el portátil, y luego, cuando tenga más tiempo, instalaré la máquina principal.

Escritorio remoto en Linux. TeamViewer, ¿para qué?

Mi ordenador personal, de casa, es el corazón de mi actividad informática. Es una máquina comprada y ajustada para mi, mucho más potente de las que tengo en el trabajo y que funciona todo el día (y noche, estilo, 24 7). Además, la copia completa de mi trabajo y ocio está en él. Por ello estoy siempre interesado en conectarme con él desde mis diferentes puestos de trabajo. Sin embargo, nunca he logrado hacer funcionar correctamente un escritorio remoto gráfico. Con ssh consigo conectarme en terminal y hago copias de seguridad, actualizo cuando descubro alguna actualización importante y puedo ejecutar scripts.

Con nautilus/nemo puedo conectarme con mi ordenador y hacer intercambio de ficheros.

Simplemente lo que necesito además es un escritorio gráfico que me permita en momentos determinados ejecutar una acción determinada en un programa gráfico. Como nunca he logrado que me funciones las versiones libres (x11vnc...) lo he intentado con TeanViewer.
Es muy fácil instalarlo. En la página web se descarga el binario adecuado, que en mi caso (Fedora 18) es el rpm. Luego simplemente

su -c 'yum -y install fichero.rpm'

y listo. Simplemente al arrancarlo (en WINE, eso sí) te da una ID numérica y das una palabra clave para poder conectarte a ese ordenador. Luego lo instalas en el/los otros y al ejecutarlo ya se puede conectar al otro ordenador mediante la ID y palabra (flecha de la izquierda). En el caso de haberse registrado, se puede uno conectar directamente a los ordenadores reconocidos (flecha de la derecha).

Y luego ¿que podemos hacer? Pues poca cosa, al menos en mi caso. Por supuesto, se conecta muy fácilmente

pero como ya sabemos, por mis gustos personales mi escritorio está limpio, vacío de todo. En teoría, al activar en Acciones "Enviar combinaciones de clave" (marcado en rojo), el escritorio remoto debería recibir atajos de teclado, pero en mi caso no ha sido así.

He probado activando en el servidor y en el cliente, en uno y no en el otro, en el otro pero no en el uno, lo he intentado en red local, con otro ordenador, con un portátil, y nada. He intentado que funcionara dejando el panel superior a la vista, pero las ordenes del ratón no se ejecutaban (y además dejaban inutilizado el panel, que luego tenis que activar manualmente al usar el ordenador). La única forma de que funcione es dejar el programa que queremos activar las funciones a la vista, y en el escritorio activo, ya que al no recibir los atajos de teclado, tampoco se puede cambiar de escritorio/área de trabajo. Además, aun en ese caso, la respuesta al ratón es aleatoria e irregular.
Lo que si funciona muy bien es el intercambio de ficheros,

pero eso ya lo tenía solucionado, así que, al menos para mi, no me sirve. O me equivoco en algo (y no he visto en la red más explicaciones)o para los usuarios de Linux, o al menos de Fedora, no cubre nada que no podamos hacer con otras aplicaciones que tenemos en el sistema sin añadir nada.

Fedora 18: Nemo y PySolFC

Adaptado ya a Fedora 18 en gnome shell, puedo decir lo que me gusta y lo que no me gusta. En primer lugar, Fedora sigue tan bien como de costumbre y es la mejor distribución, desde mi punto de vista, que he probado. Me gusta en particular la nueva forma de esconder la sesión después de unos minutos sin inactividad. El mantener el fondo en la pantalla de bloqueo, en vez de recurrir al fondo básico supone un avance estético agradable. Las extensiones backslide (cambio de fondo) y hide top bar (oculta el panel superior) me parecen magníficas (un tanto para gnome) para ajustar el escritorio a mi gusto.
Sin embargo, el nuevo nautilus se me hace muy incómodo. Siempre he usado la distribución en árbol, y no me gusta tener siempre el panel izquierdo en lugares, así que no me ha quedado más remedio que poner nemo. El problema radica en que gran parte de las funciones de gnome se dirigen a través de nautilus. Un ejemplo muy claro es el paquete nautilus-open-terminal, que permite abrir un terminal directamente en un directorio simplemente con un toque en el botón derecho del ratón. Eso me obliga, bien a tener un nautilus abierto, o teclear más de lo necesario en el terminal. Como este ejemplo iré descubriendo más, como scripts de conversión que están escritas para nautilus y otros. Todo es costumbre, y será cuestión de adaptarse, pero me está costando mucho "este" nautilus. Otra cosa que me gustaría que mejorara gnome son sus solitarios. El paquete kpat de kde es mucho mejor que los solitarios que se instalan con gnome. Buscando alternativas para kpat, encontré PySolFC, al que llegué desde la página de juegos de Fedora (Fedora Games Spin). Y, ¿por qué el interés en los solitarios? La mayor parte del tiempo que estoy en el ordenador trabajo sobre números y datos; los genero, los muevo, los transformo, los analizo. En ocasiones tanto número satura, y lo mejor es desconectar durante unos minutos. Nada mejor que unos solitarios o algo similar. En concreto a mi me gusta freecell y spider. Me sigue gustando más kpat, pero hay que reconocer que para un solo intento en spider he logrado algo muy interesante, 1 spider a cuatro barajas en un solo intento. ¿Qué no? pues miren.

Fedora 18 en el equipo principal

Finalmente he tenido tiempo para poner Fedora 18 en mi equipo principal. Este equipo no tenía nada más que gnome, asi que lo más sencillo ha sido, tras hacer una copia de seguridad con rsync, utilizar FedUp. Tras bajar 2093 paquetes, más otros 936 de dependencias y de avisar que el repositorio de Dropbox no está disponible, se actualiza por si mismo tras reiniciar. No lleva mucho tiempo -o quizás lleve mucho, según se mire- y luego se arranca en Fedora 18 directamente. Como actualiza lo anterior, lo único necesario es cambiar el repositorio de Dropbox,

$ su -
   contraseña
# gedit /etc/yum.repos.d/dropbox.repo

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/17/
gpgkey=http://linux.dropbox.com/fedora/rpm-public-key.asc

ya que dropbox aun no tiene arreglado el repositorio para Fedora 18 (véase aquí).

Tras eso solo nos queda instalar gnome-tweak-tools

# yum -y install gnome-tweak-tool

# yum -y install dconf-editor (si es que no lo tenemos ya)

y retocar las extensiones de gnome shell, muchas de las cuales no estarán actualizadas para gnome 3.6. Entre las más interesantes que podemos  añadir/actualizar están
- Backslide: que nos permite cambiar el fondo de pantalla cada 5 minutos
- Hide Dash: que oculta el dash izquierdo
- Hide top bar: que nos permite ocultar el panel superior, que se muestra al tocar la tecla Super
- No Topleft Hot Corner: anula que se active al tocar la esquina izquierda la visión de las ventanas, aplicaciones y dash.

Esto permite tener un escritorio limpio, con un fondo que cambia según nuestros gustos cada 5 minutos, como por ejemplo,

A ellas añadiría, al menos,
- Trash- nos muestra la papelera en el panel superior
- Monitor Status Indicator, que nos permite configurar la pantalla en un acceso en el panel  superior
- Removable Drive Menu- nos da acceso a los dispositivos externos pra desmontarlos directamente

Un último cambio, para aquellos que no les guste el nuevo y minimalista nautilus

pueden instalar nemo, que es un fork del anterior nautilus (yum install nemo).

Como podemos ver, mantenemos la posibilidad de usar la distribución en árbol y también conectar a un ordenador desde el menú de archivo.

Y con ello, calculando entre 2 y 4 horas, según la red y equipo disponible, tenemos Fedora 18 listo para trabajar. Para los equipos que estén sobrecargados de escritorios, creo que sería más adecuado instalar de nuevo usando Anaconda, y eliminar cinnamon y kde, como me pasa a mi en el último ordenador que me falta por actualizar.

Nos queda probar DNF, el futuro sustitutivo de yum, pero eso lo dejamos para la siguiente, por que por lo que parece, aun presenta un bug.

Fedora, cpulimit y discos NTFS

Debido a mis problemas con los discos NTFS decidí seguir los consejos de hckorootx (véase comentarios aquí). Esto nos lleva a algunos problemas. El primero, cpulimit no esta en los repositorios estándar de Fedora, así que nos queda instalarlo desde un paquete rpm (32 bits o 64 bits), o bien introducir el repositorio sphere. Por ejemplo, la forma más fácil es como administrador
$ su -
     palabrita de administrador
# gedit

en ese documento pegamos el texto que podemos extraer de esos enlaces

[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1

y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.

Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente

# yum install cpulimit

Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría

cpulimit --path=/ruta/ejecutable --limit=N

lo que nos lleva a como copiamos:

- Si usamos cp en terminal, el comando es cp, claro

- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync

El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:

Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema

¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.