Luz nocturna en Debian 9

Las distribuciones Linux que ya han implantado la versión 3.24 del escritorio Gnome, ya se están beneficiando de una de las novedades de esta nueva versión, que es la incorporación de la opción de Luz Nocturna, dentro de las opciones de configuración de la pantalla.

Sin embargo, la próxima versión estable de Debian, tal y como apuntan en determinados foros, es muy posible que todavía no opte por incorporar esta versión de Gnome. La actualización de Julio/Agosto de 2018 de Debian, la 9.5, además de incorporar correcciones para las vulnerabilidades del kernel, ya trae la 3.28 de Gnome y, por tanto, ya puede habilitarse Luz Nocturna desde el propio panel de configuración de la pantalla.

Para los que no hayan actualizado y sigan con la versión 9.0, en los repositorios tenemos una aplicación que permite configurar y habilitar una opción similar, y que es muy recomendable para reducir la fatiga visual que supone pasar horas y horas frente a la pantalla.

La utilidad de llama RedShift, y su instalación es muy sencilla: o bien a través de Synaptic o desde la consola, con un simple comando:

$ sudo apt install redshift redshift-gtk

 Para su correcto funcionamiento debemos asegurarnos de tener activado los "Servicios de ubicación", dentro del apartado de Privacidad del panel de configuración de Gnome.

Una vez hecho esto, la utilidad podemos ejecutarla desde buscándola como cualquier otra aplicación, desde el dash (pulsando la tecla Super, es decir, la que tiene por defecto la banderita de windows).

Veréis que en área de iconos os aparecerá el correspondiente a RedShift, y que nos permite una configuración muy simple.

Si vuestro área de indicadores de aplicaciones está en la parte inferior izquierda (que es por donde por defecto se sitúan en Gnome), podéis instalar una extensión de gnome-shell llamada Topicons Plus, que los sube arriba a la derecha los indicadores, y a mi, personalmente, me gusta bastante.


De esta forma, dependiendo de la hora, se ajustará la temperatura del color y, en serio, que vuestros ojos lo agradecerán.

Extensiones Gnome Shell, en Fedora, con Firefox

Los usuarios de Fedora que usamos el entorno Gnome estamos acostumbrados a añadir extensiones que nos permiten personalizar dicho entorno, y adaptarlo a nuestros gustos.

Todas estas extensiones se encuentran aquí.

Muchos habréis notado que hace un montón de semanas, la administración de extensiones que hacíamos directamente desde la web (con los típicos botones ON/OFF) no funcionaba. Esto era debido a un cambio que obliga a:

1. añadir el complemento de GNOME Shell Integration
2. añadir el conector nativo llamado chorme-gnome-shell

El  primero es fácil, porque la propia página de Gnome Shell Extensions nos lo indica y nos da la posibilidad de instalarlo.

Simplemente debemos pulsar en "Click here to install browser extension" y se nos instalará. Si por cualquier motivo no fuera así, simplemente entramos en https://addons.mozilla.org/en-US/firefox/, buscamos el citado complemento y lo instalamos.

Para añadir el conector nativo, nos damos una vuelta por la 'wiki' de Gnome, donde tenemos las instrucciones para todas las distribuciones principales. En el caso de Fedora, el conector se encuentra en los repos Copr, por lo tanto:

$ sudo dnf copr enable region51/chrome-gnome-shell

$ sudo dnf install chrome-gnome-shell 

Y con estos 2 sencillos pasos volvemos a poder administrar nuestras extensiones desde Fedora, usando Firefox.

EDIT: 09.09.2017 Desde hace tiempo, en Fedora 26, ya se encuentra en sus repositorios el paquete "chrome-gnome-shell", por lo que no es necesario instalar el repositorio 'region51'; éste sólo es necesario en versiones previas a la 26

openSUSE Tumbleweed - ¿actualizar con 'up' o con 'dup'?

Soy un maniático respecto a tener el sistema actualizado, lo reconozco, y a veces en mi equipo de escritorio (donde tenía una gráfica NVIDIA) esta manía me ha llevado de cabeza al actualizar demasiado pronto, por ejemplo, el Kernel. La ventaja de la comunidad es que los "desaguisados" se arreglan rápido...

En el caso de openSUSE podemos actualizar el sistema, desde la terminal, con 2 comandos:

• $ sudo zypper up
• $ sudo zypper dup

La diferencia fundamental entre ambos es que 'dup' te hace una actualización completa de todos los paquetes de la distribución, por lo que en el proceso se pueden tomar paquetes de cualquiera de los repositorios activos, siempre los más actualizados... Y en algunos casos se puede romper el sistema, al incorporar una versión demasiado nueva de algún paquete que sea usada por algún programa que todavía no esté preparado para la misma.

Uno de mis sitios de referencia, cuando hablamos de openSUSE, es el portal de victorhckinthefreeworld, el cual sigo asiduamente para estar al tanto de esta distro, y tengo que decir que he aprendido mucho de esta distribución y le he perdido el miedo gracias a dicho portal (desde aquí mis felicitaciones).

Hace unos meses, en dicho portal, estuvieron debatiendo el tema de cuál era la mejor forma de tener actualizada esta distribución (artículo completo aquí).

Al parecer, zypper up es bastante conservador y no deja limpia la casa entera (suele dejarse por el camino paquetes huérfanos y dependencias obsoletas que, aunque en principio no deben plantear mayor problema, ocupan espacio).

Por el contrario, zypper dup resuelve mejor las dependencias y actualiza todos los paquetes de la distribución, con el peligro que comentaba más arriba, de 'romper' algún programa por tener alguna dependencia demasiado moderna, traída desde otro repositorio.

Se comenta en este artículo que una buena opción es aprovecharse de la calidad del comando zypper dup, pero no permitiéndole el cambio de proveedor a los paquetes, con lo que teóricamente se elimina el potencial peligro de desestabilizar el sistema instalando algunos programas, librerías o dependencias muy nuevas y que todavía no puedan ser usadas por la totalidad de programas que hacen uso de ellas.

Esto se conseguiría con el siguiente comando:

$ sudo zypper dup --no-allow-vendor-change

Veamos un ejemplo real:

Hoy, este comando me dice que me va a instalar un paquete nuevo.

Pero, ¿y si hubiera utilizado cualquiera de los 2 primeros comandos que puse antes?. ¿Me hubiera dicho lo mismo?

zypper up me dice que hay un paquete nuevo, pero que no me lo va a actualizar. Entiendo que es porque el citado paquete está en otro repositorio con la misma prioridad que el oficial.

Por el contrario, si ejecuto zypper dup, el mensaje que recibo es distinto:

En la imagen de la izquierda veis que zypper dup me haría varias cosas:

• instalar un paquete
• cambiar el proveedor de otro
• actualizar este útlimo

En la  imagen que realicé, cuando puse el comando entero, veíamos que sólo nos iba a instalar el paquete llamado gmplayer. ¿Por qué? Pues porque le habíamos puesto el parámetro de "no permitir el cambio de proveedor", por lo tanto, el vlc-codec-gstreamer no se iba a actualizar.

Mi conclusión (personal, cada uno que actúe según su responsabilidad) es que, en este caso concreto, y dado que es un tema muy controlado y que el sistema me está indicando lo que va a hacer, yo sí voy a permitir el cambio de proveedor de dicho codec (se supone que packman suele tener mejor y más actualizado el soporte para todo el tema multimedia), pero luego seguiré actualizando con zypper dup --no-allow-vendor-change, ya que los meses que llevo usándolo no me ha dado ningún problema, y según dicen los expertos (yo no lo soy, soy un simple aficionado), 'dup' resuelve y limpia la dependencias de una forma más efectiva que 'up'.

Y por último sólo añadir, como apunta Viktorhck en su artículo, que el que quiera usar este comando y ahorrarse el tecleo de 'tantas letras', puede crearse un "alias", y si dicho alias quiere hacerlo permanente podemos editar el archivo .bashrc, que está en nuestro home (acordaros de habilitar los archivos ocultos, para poder verlo), y añadirle al final del todo la instrucción:

De esta forma, desde la consola, sólo tendremos que teclear:

$ ponaldia 

Espero que este artículo elimine vuestros miedos y os anime a experimentar, arreglar, romper,... que en el fondo es como más se aprende.

Edito hoy, con fecha 13.07.2017, para comentar una novedad. Con las nuevas actualizaciones de determinadas librerías en openSUSE, ya no es necesario este debate. Dado que no puedo mejorar el excelente artículo de Viktorhck, os dejo enlace al mismo... Resumen: zypper dup ya he mejorado en el sentido que se le exigía, por lo tanto podemos usarlo sin riesgo a romper dependencias.

¿Arranque lento en Linux? Revisa tu archivo fstab

Tengo un disco SSD de 250GB, con lo que el arranque de cualquiera de las distribuciones que tengo es rapidísimo (entre 5 y 10 segundos, y no exagero).

Desde hacía unas semanas había notado que el arranque de Ubuntu era muy lento para mis costumbres: alrededor de 1 minuto desde que lo seleccionaba en el Grub hasta que me pedía el usuario/contraseña.

Así que hoy me he puesto a investigar.

He llegado a la conclusión de que debía ser "algo" de lo que se carga antes de iniciar completamente el sistema.

He revisado el archivo /etc/fstab que es donde se definen las particiones y los montajes correspondientes, y ha aparecido la petaca.

Lo primero de todo ha sido revisar cómo tengo las particiones y qué es lo que tengo en cada una de ellas, ya que no me acordaba. 

El comando lsblk -fm me da la información que estaba buscando, y de una forma muy esquemática y agrupada

Como puede verse en la imagen, tengo 2 discos duros: /dev/sda y /dev/sdb

El primero (/dev/sda) es el rápido, el ssd, donde tengo instalados los sistemas operativos. Las distintas particiones si identifican como veis en la imagen.

El otro disco (/dev/sdb) lo uso de forma común para todas las distros, montando automáticamente las particiones creadas, y accesibles desde todos los sistemas, ahorrando espacio y teniendo todo a mano.

Podemos ver el denominado UUID (identificador único universal) para cada partición. Este dato es el que suele usar el sistema operativo por defecto en la instalación, ya que, según dicen los expertos es más 'robusto' referirse a las particiones por este identificador que por otros (por ejemplo /dev/sdx, o a través de sus etiquetas -label-...).

Cuando lo he revisado, he visto que en mi /etc/fstab tenía 2 referencias distintas a la "swap", con 2 uuid distintos, pero si miráis en la primera imagen sólo tengo una partición "swap", lo que estaba originando que el arranque se demorara mucho por estar intentando montar una partición que no existía.

Recordé entonces que hace varias semanas, cuando todavía tenía la 16.10 de ubuntu, redimensioné algunas particiones (entre ellas la swap) para reducirlas y hacer hueco a la última distribución que instalé, y por dicho motivo, la nueva "swap" tenía una UUID diferente.

Estas situaciones pueden también generarse por la instalación de nuevas distribuciones, a través de USB, ya que algunas veces, el sistema cambia el orden de /dev/sdX (siendo 'X' la letra que identifica a uno u otro disco).

Dado que la beta 17.04 de Ubuntu la instalé a través de update-manager -d, se conoce que el sistema no borró el /etc/fstab antiguo y lo único que hizo fue añadir la nueva swap, pero dejó la referencia de la vieja, que es la que no encontraba.

Por comodidad de identificación para mí, dado que una partición primaria estática identificada como  /dev/sda2 siempre va a ser /dev/sda2, y una /dev/sda5 (donde actualmente tengo montada la partición de intercambio) siempre va a ser una /dev/sda5, he eliminado la fila con la UUID errónea y he cambiado las referencias al UUID por la numeración de la partición primaria correspondiente.

En la imagen veis que he comentado la fila marcada en azul, y he añadido la misma fila (remarcada en rojo), pero llamando al dispositivo por su nombre de partición....

... E voilá;  el sistema vuelve a arrancar en 6 segundos!!

Eliminado Kernels antiguos en Fedora

Como ya he juntado varios Kernel en el grub de Fedora, y he comprobado que el último me funciona bien, vamos a eliminar manualmente uno de ellos, el más antiguo.

Primero, como siempre, vemos el kernel con el que hemos arrancado.

Estoy probando la versión alpha de Fedora 26, y el último kernel que tengo es la RC5 del 4.11


Ahora vamos a ver  los kernel que tengo instalados. Hay varias formas de hacerlo:

$ rpm -qa kernel  (un comando simple y reducido)

$ rpm -qa | grep -i kernel   (comando extendido, que muestra los core, devel, modules y headers asociados) 

Ahora, lo único que debemos hacer es utilizar "dnf remove" para eliminar el que queramos, por ejemplo el RC3, y así quedarme sólo con los 2 últimos:

Ya véis que es sencillo.

Cuando realicemos esto en la versión definitiva estable, creo que con eliminar el archivo kernel-core correspondiente al que vayamos a eliminar, se eliminan también los módulos y cabeceras asociados. Si no fuera así, simplemente habría que eliminarlos de la misma forma, usando 'dnf remove'.

Por defecto la distro guarda hasta 3 kernel diferentes, y cuando llega uno nuevo, el proceso en el propio proceso del "update" se elimina el más antiguo.

Así podemos depurar nuestro grub de una forma manual.

Decir también que cuando ejecutamos el comando extendido, si eliminamos el kernel-core, el propio dnf eliminará también los modules asociados (kernel normal, devel, etc...). Si alguno de ellos no lo elimina automáticamente, podéis eliminarlo luego manualmente, de la misma forma.


Por último, refrescamos nuestro GRUB.

Dependiendo de la BIOS  que tengáis (MBR o UEFI) la instrucción varía un poco

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg    (bios mbr antiguas)

$ sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg  (para UEFI)

Nota: imagino que será por ser alpha; cuando eliminé el kernel rc3, vi que no me borró automáticamente los archivos correspondientes dentro de la ruta /boot, por lo que antes de hacer la captura siguiente los borré yo manualmente.

Ahora ya tenemos una entrada menos en el grub, y sólo refleja las que hemos dejado de Fedora, junto al resto de sistemas operativos que cada uno tengáis.



Un saludo y espero os sea útil.

Eliminar Kernel antiguos en Debian, Ubuntu y derivados

Los usuarios de cualquier distro sabemos que con las diversas actualizaciones pueden acumularse imágenes del kernel en nuestro arranque, y que mucha veces nos ocupan espacio innecesario.

En Ubuntu, para limpiar entradas antiguas lo tenemos fácil:

1. Vemos qué versión estamos usando
2. Listamos las cabeceras (headers) que tenemos instaladas, para eliminar los antiguos que ya no nos interesan
3. Lo mismo hacemos con las imágenes del kernel (image), para ver cuántas tenemos instaladas
4. Después de cada paso, vamos eliminado los antiguos

Manos a la obra:

uname -r

En mi caso me devuelve lo siguiente:




Ya sabemos el kernel que estamos usando. IMPORTANTE: No borrar éste.

Ahora veamos cuántos 'kernel (linux-image) y cabeceras (linux-headers)' distintos tenemos:

dpkg --get-selections | grep -E "linux-image|linux-headers"

En la imagen de la derecha veis que tengo varios kernel y varias cabeceras, de las veces que voy actualizando.

Voy a dejar únicamente las correspondientes a la rama 4.18 (estoy editando este post antiguo en Agosto-18 y ya vamos por la 5ª revisión del kernel 4.18).

sudo apt remove --purge linux-headers-4.15 linux-headers-4.17


Ponemos 'S' y pulsamos 'INTRO'.... y ya está.

Lo mismo haremos con las imágenes del kernel


sudo apt remove --purge linux-image-unsigned-4.17

Como veis, esta acción seleccionará todos los "image" de kernel 4.17:

Igual que antes, pulsamos 'S' e Intro.... y el kernel se eliminará, liberando espacio.

Conviene siempre que tengáis las 2 últimas (cabeceras e imágen), por si una falla, para que podáis arrancar con la anterior.