Solucionando problemas en Chakra

Con la última, ya enésima, re-instalación de mi sistema operativo GNU/Linux favorito me he topado con algunos problemillas, tanto ya conocidos como de nueva aparición. Los hay que son meras incomodidades, con las que se puede convivir sin más, mientras que otros te pueden dar al traste con la experiencia de uso del equipo. Sean de una clase o de otra, todas han encontrado solución con algo de paciencia y dedicación. Estas son las pequeñas cosas que, dependiendo de tu estado de ánimo y tu predisposición al aprendizaje en cada momento pueden hacer que te alejes de GNU/Linux si no dispones de tiempo o ganas. Cuando no es el caso, ocurre lo contrario y… habemus tutorial.

Partimos de un sistema Chakra GNU/Linux Curie recién instalado en mi archiconocido equipo doméstico de sobremesa. Tras los pasos de rigor en toda instalación, me dirijo a mi propio tutorial de puesta a punto e instalo todo lo necesario para mi desempeño informático diario. Cuando ya esta todo listo, comienza la resolución de problemas, que paso a desglosar punto por punto.

La impresora HP Laserjet 1018 no imprime
Hace unos meses que tuve que prescindir de mi vetusta Epson Stylus Color 680, pues la impresión dejaba ya mucho que desear (líneas por todas partes, letras y fotografías mal alineadas…), algo lógico al tratarse de un modelo con 14 años a sus espaldas. Recuperé para su uso en casa una HP Laserjet 1018, impresora láser monocromo, que solía utilizar en el negocio de hostelería de mi familia política y que últimamente no tenía ya apenas utilidad (sí, lo habéis adivinado, la crisis estafa haciendo estragos).

Ya sabía, por experiencia, que este tipo de impresora precisa de un “plugin” propietario de HP para funcionar en GNU/Linux, algo que se instala automáticamente en distros más amigables, como Ubuntu. También sabía que este “plugin” da problemas en Arch y derivadas, siendo la alternativa más simple la instalación de los controladores foo2zjs, disponibles en CCR para Chakra y en AUR para Arch, Manjaro y demás. Por desgracia, los turbulentos momentos por los que atraviesa Chakra tienen la desagradable consecuencia de que CCR no sea un prioridad, sobre todo cuando hablamos de paquetes mantenidos por usuarios que son, a la vez, desarrolladores importantes de la distribución, caso del que nos ocupa. La instalación desde CCR, como podéis suponer por lo ya comentado, falló estrepitosamente.

Dado que dicho desarrollador, responsable de la paquetería del repositorio [core], probablemente tendría cosas más importantes de las que ocuparse en este momento, decidí arreglar yo mismo el desaguisado, empleando para ello otro de mis tutoriales de cosecha propia: el de importación de paquetes de AUR a CCR. Eso sí, dichos paquetes se quedarían en mi equipo sin ser subidos, algo que no es posible hacer cuando ya existe el mismo paquete, para evitar la duplicidad de los programas.

La operación tampoco tuvo éxito, algún tipo de incompatibilidad impedía la instalación del paquete en mi sistema, de manera que hube de acudir a los creadores del controlador, quienes, curiosamente, en su página desaconsejan la instalación de los paquetes pre-compilados para la gran mayoría de distribuciones. Siguiendo las instrucciones que allí se dan conseguí instalar el controlador foo2zjs. Pero… Tras intentar instalar la impresora con el módulo correspondiente de KDE y con la interfaz web de CUPS, me encontré con que, efectivamente se instalaba, pero no imprimía. El mensaje de error “Filter failed” (“falló el filtro”) era lo único que obtenía.

Llegó entonces el turno de Duck Duck Go, logrando hallar, tras varios intentos, la raíz del problema en la madre de todas las wikis: la de Arch. Se trataba de un problema de permisos en el puerto USB, subsanado completamente gracias a la información allí encontrada. Uno, que ha sido usuario de Arch y de Chakra durante la mayor parte de su tiempo en GNU/Linux, siempre estará en deuda con esta wiki y su inconmensurable aportación al software libre. Gracias, Arch.

Mejorando el “scrolling” en Firefox
Lo mencionaba como uno de las diferencias más notables entre Windows y GNU/Linux en mi artículo de pseudo-despedida. Lo corroboraba el comentario de otro sufridor de AMD/ATI en GNU/Linux, INDX (Juan Martínez). Pero en lo que ambos estábamos equivocados era en atribuir el problema a los deficientes controladores gráficos de dicha empresa para GNU/Linux. O no… En mi actual instalación de Chakra uso los controladores propietarios Catalyst, por si alguien se lo estaba preguntando.

Pues bien, me atrevo a afirmar, por fin, que he equiparado la rapidez del “scrolling” de la rueda del ratón en Windows y en Chakra, con dos sencillos pasos:

1 – En el módulo de Configuración del sistema de KDE –> Dispositivos de entrada –> Ratón, pestaña Avanzado, apartado “La rueda del ratón desplaza”. Ahí ponemos el valor máximo, que son 12 líneas.

2 – En Firefox, abrimos “about:config” y buscamos la expresión “mousewheel.min_line_scroll_amount”, sustituyendo el valor asignado (creo que era 5), por un valor mucho mayor, sobre 50 ó 60, dependiendo de los gustos de cada cual.

Salimos y volvemos a entrar en Firefox y… voilá, el “scroll” es muchísimo más rápido, a la altura del de Windows. Ignoro el motivo, pero en la versión de Firefox para el sistema de Microsoft, el valor asignado a la expresión vista arriba es 5. Sin embargo, el “scrolling” va perfecto con ese valor en Windows. Misterios insondables, o tal vez, Juan y yo no íbamos tan desencaminados y el controlador gráfico tiene algo que ver… Si algún lector puede arrojar luz sobre el asunto, se lo agradecería. En el siguiente vídeo – mis disculpas por la pésima calidad – se ve lo que quiero decir:

Por cierto, la elección de la web de un conocido periódico para la demostración obedece únicamente a razones de “carga” de la misma, pues contiene gran cantidad de material en Flash y vídeos que suelen hacer más lenta la navegación.

Actualización (26/11/14): gracias al comentario del usuario Aguzth en otro artículo, sabemos que se puede mejorar aún más el “scrolling” cambiando el valor del parámetro “mousewheel.acceleration.start” de -1 a 0.

Acabando con las congelaciones de Plasma
Otro de mis caballos de batalla, que incluso un día me condujo a llegar tarde a recoger a mi hijo, como contaba en su momento, y finalmente a la decisión de dejar nuevamente de usar Chakra en favor de Ubuntu. En esta nueva instalación, el problema se seguía reproduciendo e incluso diría que era más frecuente su aparición: de buenas a primeras, sin estar haciendo nada especial, la barra de tareas y el espacio de trabajo de Plasma quedaban congelados. Podía abrir una sesión en terminal con CTRL+Fn, podía incluso cambiar de ventana con ALT+TAB, pero todo lo demás no funcionaba.

En aquel fatídico día en que el reloj de KDE me llevó a engaño, como suele ser habitual en mí, el cabreo me impedía pensar e investigar, y mi único objetivo era dejar atrás los errores y arramplar con todo lo que tuviese que ver con la distro y el escritorio en cuestión. Si hubiera contado hasta diez e indagado un poco, se me habría presentado la ocasión de acabar con el molesto problema, cuyo origen estaba en el plasmoide de NetworkManager. Llegué a esta conclusión tras encontrar varios hilos en foros diversos de varias distribuciones (openSUSE, Kubuntu, Arch, Debian) con errores similares que no encontraban solución. Alguien, en uno de dichos hilos, proponía a los plasmoides como fuente del problema y daba como remedio un ejercicio concreto: desactivarlos todos e ir activándolos uno por uno hasta dar con el que provocaba el comportamiento errático en KDE.

Y a la primera fue la vencida. Tras sustituir NetworkManager por Wicd, siguiendo las instrucciones de la wiki de Chakra, se acabaron las congelaciones de KDE de una vez por todas. Por fin puedo fiarme del reloj…

KDE lento al copiar archivos grandes a pendrive
Este problema no me lo había encontrado anteriormente, pues tenía costumbre de hacer “streaming” desde el equipo de sobremesa al portátil para ver los episodios de mis series favoritas en el salón. Recientemente cambié de proveedor de Internet, y el Livebox de Orange provocaba molestos cortes durante el “streaming”, de modo que tuve que optar por pasar los ficheros a mi pendrive y de ahí llevarlos al portátil.

En Windows, todo hay que decirlo, cero problemas. Fue al intentar hacer la copia de archivos de casi 4 Gb de tamaño a mi pendrive en Chakra cuando noté que todo el escritorio se enlentecía (el ratón se movía como a saltos) y el uso del procesador se disparaba a casi el 100%. A la vez que esto ocurría, la tasa de transferencia decaía sin parar hasta hacerse inviable la copia (menos de 100 Kb por segundo). En los foros de Arch aportaban una solución que me sirvió una vez, pero no las sucesivas. Finalmente, con la calma que da disponer de una partición de Windows para hacer la copia (cualquiera se pone a buscar la solución a las tantas de la noche mientras la señora se impacienta en el salón…) y poder así investigar con tranquilidad en otro momento, encontré una causa y la forma de subsanarlo en el foro de PCLinuxOS. Deshabilitando el modo “USB Legacy” en la BIOS dije adiós al problema. Lo malo es que al deshabilitar dicho modo me quedé sin la posibilidad de usar el teclado antes de iniciar el sistema, lo cual se traduce en que no se puede entrar en la BIOS ni elegir nada en Grub. Por si a alguien le ocurre, se soluciona quitando la batería de la placa base durante un minuto más o menos, con el equipo desconectado de la corriente para resetear la BIOS. Si no sois muy duchos en esto de toquetear la BIOS, tened cuidado de no equivocaros en la elección.

Aparte del fastidio que supone no poder usar el teclado hasta haber entrado en el sistema, noté que el ahorro de energía del monitor no se activaba. Ni idea de qué tiene que ver esto con el USB Legacy, pero cuando reseteé la BIOS volvió a funcionar.

Total que, puestos a elegir, decidí seguir con la investigación.Y hete aquí que la sapiencia y el espíritu comunitario de Gregorio Espadas me dieron por fin la ansiada solución, en un artículo de su blog. Bastaba añadir al primer paso que yo describía (el mencionado en la wiki de Arch), un segundo (editando un fichero de configuración con parámetros del kernel). Mano de santo, oigan. No solo se estabilizó la velocidad de transferencia de principio a fin en torno a los 7 Mb por segundo, sino que desapareció completamente la lentitud y los “lags” de respuesta del ratón. Por segunda vez, gracias Arch. Y, por supuesto, gracias maestro Espadas.

Firefox no tematizado al abrir desde gmail-plasmoid
Si bien todo lo anteriormente relatado puede ser útil a usuarios de cualquier distribución con KDE, sospecho que esta última solución solamente se aplica a Chakra. Hace mucho que utilizo el plasmoide de Gmail de KDE para la notificación y apertura de correos electrónicos. Dentro de la configuración del plasmoide se puede elegir la acción a realizar cuando se hace clic con el ratón sobre él, que en mi caso se trata de abrir el navegador Firefox con la bandeja de entrada de mi cuenta, ya que no uso clientes de correo. Siempre me ocurría que, si no estaba abierto el navegador, al abrirlo a través del plasmoide aparecía sin el tema oxygen-gtk, con un horrible “look” a lo Windows 95. No era un problema molesto, bastaba abrir normalmente Firefox y luego hacer clic en el plasmoide para que la pestaña con la bandeja de entrada tuviera la apariencia normal.

La solución, hallada investigando por mi cuenta con los enlaces de KDE, pasa por sustituir la orden de apertura del navegador en la configuración del plasmoide: en lugar de “firefox %u”, utilizar la expresión “xdg-open %u”. De este modo, el plasmoide abre el navegador por defecto que hayamos indicado en las preferencias de KDE, y lo abre tematizado, como debe ser.

Resumiendo, que es gerundio
Para quienes no deseen tomarse la molestia de leer el tocho previo, hago un breve resumen de cada problema y su solución propuesta:

Problema: HP Laserjet 1018 no imprime, mensaje “Filter failed”.
Solución: instalar los controladores foo2zjs y dar permisos al puerto USB.

Problema: “scrolling” lento en Firefox.
Solución: ampliar las líneas que desplaza la rueda del ratón en KDE y en el módulo de configuración de Firefox (about:config).

Problema: KDE se congela.
Solución: desinstalar el plasmoide NetworkManager y usar Wicd.

Problema: KDE lento al copiar archivos a pendrive o USB externo.
Solución:  el maestro Gregorio Espadas la cuenta aquí.

Problema: Firefox no tematizado si se abre desde gmail-plasmoid.
Solución: usar la expresión “xdg-open %u” en lugar de “firefox %u”.

¿Qué he aprendido con todo esto? Que cuando algo falla en GNU/Linux tiene arreglo. Lo que no puede ser, y me ha pasado cientos de veces ya, es pretender que se arregle rápido, a lo loco, sin investigar ni documentarse, sin leer o preocuparse por preguntar. Las prisas no son buenas consejeras, y este es un ejemplo más. Mi recomendación, que cobra especial relevancia en el caso de que se use una distribución “rolling-release”, es disponer de algún sistema estable en el equipo, donde todo funcione, para pasar el apuro que pueda surgir. Luego, con calma y ganas de aprender, todo – o casi todo – se puede solucionar. Que dicho sistema estable sea un Windows, un Mac o un Debian Stable, ya dependerá de cada cual.

Espero que este artículo pueda servir de ayuda a quien aquí llegue buscando arreglo a su problema. Un saludo para todos.

Anuncios

19 comentarios en “Solucionando problemas en Chakra”

  1. Muchas gracias Enrique por los tips. Siempre vienen bien. Me alegra tu vuelta a mi distro preferida. Un consejillo si me lo aceptas, ahora que tienes tu chakra a punto no lo toques, evita el distrohopping a toda costa, disfruta de ella, dejala estar bastante tiempo. Chakra lleva conmigo 3 años y te aseguro que ningún problema. Yo es que amo esta distro y encima (yo que soy un simple profesor de filosofía) la próxima versión de chakra se llamará DESCARTES. Olé ahí, que buen gusto, una distro con el nombre de ese gran pensador y científico. ¡como te quiero chakra¡¡¡

    Me gusta

    1. Gracias a ti por comentar, tu experiencia con Chakra demuestra que es una distribución muy estable pese a su carácter de "semi-rolling". En mi caso, cada vez que me he ido he vuelto a, lo más tardar, un par de meses. Y siempre han sido reacciones un tanto pueriles, no me importa reconocerlo, del tipo "ea, ahora me enfado y ya no te ajunto" :)Precisamente por eso he dedicado un artículo a la resolución de problemas. Fíjate qué sencillo era acabar con el problema de las congelaciones del escritorio, se tarda menos que en instalar otra distro. Un saludo.

      Me gusta

  2. Sobre el tema de desactivar "USB Legacy" y quedarse sin poder usar el teclado al arrancar el ordenador, la solución (mía) pasa por usar un adaptador USB/PS2 y conectar el teclado a este último puerto (siempre que la placa base del equipo todavía incluya puertos PS2). De esta manera se puede usar el teclado sin problemas.

    Me gusta

    1. Exacto, gracias por el aporte. De hecho tengo uno de esos adaptadores, pero no sé por qué pensaba que mi placa base ya no traía conector PS2… Y aunque sí que lo trae, de todos modos, con la solución aportada por Gregorio Espadas ya está arreglado el asunto.

      Me gusta

  3. Hola Enrique que bueno que estés de vuelta, hace poco tuve un problema de lentitud al escribir en los discos duros como por ejemplo cuando actualizaba el sistema, es parecido al problema del USB. Lo solucione al cambiar el scheduler del kernel por deadline. Se logra agregando "elevator=deadline" al archivo /etc/default/grub. Quizá podría ayudar con el problema de USB. Este scheduler lo usa por defecto ubuntu.

    Me gusta

    1. Gracias HydrosIII, he probado el parámetro que indicas y noto alguna diferencia: una pequeña mejoría en la velocidad de transferencia, 8 Mb/s en lugar de 7 (lejos aún de los 15-16 de Windows) y el hecho de que la copia parece terminar antes. Explico mejor lo último, cuando Dolphin te notifica de que ha finalizado la copia, aún continúa parpadeando el led del pendrive, es decir, se siguen copiando datos. Con el parámetro "elevator=deadline", esto ocurre durante apenas 5 segundos, mientras que sin él, podían transcurrir fácilmente 15 ó 20. Esa ha sido mi experiencia, positiva pues, muchas gracias por el aporte.

      Me gusta

    2. Que bueno que te haya servido la respuesta. Respecto al USB yo he tenido buena suerte en linux, incluso me ha tocado ver como a un amigo se le eternizaba la copia de archivos a un pendrive en windows. Pero creo que no tengo con que comparar por que ya es raro que use una computadora con windows. Se me ocurren dos cosas para probar por que el USB copia archivos tan lento, una es copiar los archivos al usb desde la terminal, inclusive montándolo manualmente para ver si KDE tiene algo que ver. La segunda es que formates el USB a ext4 o algún otro formato nativo de linux, ya que en realidad el USB sólo usa el sistema de archivos FAT, un sistema de archivos obsoleto que sólo se usa por cuestiones de compatibilidad y que es terriblemente lento en cualquier sistema. La desventaja es que sólo podrá usarlo en sistemas linux, pero esto puede ser una ventaja si sólo tienes linux en tus computadores.

      Me gusta

    3. Este pendrive en cuestión lo tengo formateado en NTFS, tal vez sea ése el problema. De todos modos, con la velocidad que alcanza me copia un episodio de una serie en HD en unos cinco minutos. Me basta y me sobra 🙂

      Me gusta

  4. Pregunta indirectamente relacionada: Como le digo al Kmix de chakra que siempre que reinicie quiero el audio analógico? Porque tengo enchufado los tres (el común, el hdmi y el óptico) pero quiero el analógico global, el óptico para VLC (eso lo hace solito) y el HDMI pal video solo.Si reinicio vuelve al hdmi hasta que le digo que cambie.

    Me gusta

  5. Hola Enrique, mi nombre es Nicolás. Hace algunos pocos años que uso Linux. Ya probé Ubuntu, Linux Mint. Me resultó bastante bien ElementaryOs por un par de años.
    Hace unas pocas semanas me decidí a probar Manjaro. Si bien me cuesta adaptarme y dejar de lado el entorno Debian/Ubuntu, estoy dispuesto a darle una oportunidad a Arch Linux.

    El problema es que no logro solucionar la lentitud para transferir/abrir archivos grandes en un Pendrive o Disco Externo.
    Tu post hace referencia a una pagina de Gregorio Espadas, pero el enlace está caído. Por favor, podrías subir la solución? Muchas gracias!!!

    Me gusta

  6. Por desgracia no la recuerdo. Podrías probar con la primera parte de la solución: editar el archivo /etc/tmpfiles.d/local.conf y añadir 3 líneas:

    w /sys/kernel/mm/transparent_hugepage/enabled – – – – madvise
    w /sys/kernel/mm/transparent_hugepage/defrag – – – – madvise
    w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag – – – – 0

    Está sacado de la wiki de Arch. Tal vez sea suficiente con eso. La segunda parte de la solución estaba en el blog antiguo de Gregorio Espadas y cometí el error de solo mencionarla sin copiar cuál era. Puedes probar también esto que menciona HydrosIII más arriba:

    Comentario de HydrosIII

    Me gusta

  7. http://wayback.archive.org/web/20140816190324/http://gespadas.com/copia-lenta

    La página en cuestión ya no existe, pero en archive.org todavía guardaban una copia (lo malo es que sólo de la página, no de los 37 comentarios que mencionan en el encabezado). Por si acaso, además del enlace de arriba, ahí va el contenido. A mí me ha servido su solución. Muchas gracias a todos por vuestro tiempo y por ayudar a gente como yo, que controla lo justito de linux.
    —————
    ¿Copia lenta de archivos a memorias USB?
    Saturday 6 de April de 2013, 7:50 am Gregorio Espadas 37 Comments

    Algo que me encanta de ArchLinux es que cada vez que me enfrento a un problema, siempre encuentro información al respecto en la wiki y/o en los foros; desde el primer día en que empecé a utilizar esta maravillosa distro, todos los días he aprendido algo nuevo… y esta ocasión no es la excepción.

    El problema: Pobre desempeño al copiar o mover archivos (en particular los “pesados”, pero no es exclusivo) a una memoria USB o pendrive, en especial al usar KDE (de nuevo, el Desktop Environment tampoco es exclusivo).

    La solución: En la wiki se menciona un procedimiento, pero editando el archivo /etc/rc.local, el cual sabemos ya no existe con la llegada de systemd, así que tuve que “modernizarlo” basándome en un par de guías. El resultado a continuación.
    Paso 0

    No usen sudo para crear/editar los archivos de los pasos siguiente, mejor entren al usuario root con el comando su -:

    [gespadas@localhost ~]$ su –
    Contraseña: ******
    [root@localhost ~]#

    Ahora si, pueden seguir leyendo.
    Paso 1

    Vamos a crear el archivo /etc/tmpfiles.d/disable-hugepage.conf (realmente puede llamarse como gusten). Para ello usaré:

    vim /etc/tmpfiles.d/disable-hugepage.conf

    ¿No les gusta vim? ¡Muy mal! Ok ok, pueden usar el editor que deseen 😉

    Ahí, el contenido del archivo será el siguiente:

    w /sys/kernel/mm/transparent_hugepage/enabled – – – – madvise
    w /sys/kernel/mm/transparent_hugepage/defrag – – – – madvise
    w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag – – – – 0

    Las primeras dos líneas están escribiendo el valor madvise al archivo indicado (algo como hacer un echo madvise > /sys/…/archivo), y la última línea hace lo mismo, pero escribiendo el valor 0.

    No quiero profundizar en lo que significa lo anterior (¡lean las referencias que pongo!), pero brevemente les comento que estamos estableciendo durante el booteo (por eso usamos tmpfiles) los parámetros transparent hugepages y hugepage defragmentation del kernel.
    Paso 2

    Adicionalmente, editen el archivo /etc/sysctl.conf (ese si existe, su función es la de establecer parámetros del kernel en tiempo de ejecúción):

    vim /etc/sysctl.conf

    Y al final pongan lo siguiente:

    kernel.shmmax=134217728
    vm.dirty_background_bytes = 4194304
    vm.dirty_bytes = 4194304

    ¿Por qué esos números? 134,217,728 bytes = 128 MB y 4,194,304 bytes = 4 MB.

    ¿Y por qué esos parámetros? Ayudan a reducir el efecto freeze en KDE.

    ¿Les da miedo editar un archivo que se mete directamente con el kernel? ¡Deberían! Es por eso que una solución más elegante, más acorde a la filosofía de systemd, es crear un archivo .conf dentro de la carpeta /etc/sysctl.d/ (similar a lo que hicimos en el paso 1). Por ejemplo, el archivo podría llamarse /etc/sysctl.d/disable-freeze.conf, cuyo contenido serían las tres líneas antes descritas.
    Paso Extra

    Si el desempeño mejoró, pero no lo suficiente, repitan el paso 1, pero usando el valor never en vez de madvise. ¡Atención! Hay efectos colaterales, y el más molesto es que la hibernación del sistema ya no funcionará.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s