19 agosto 2017

Fedora Gnome, KDE, KDE Connect y MConnect

Desde hace unas semanas estoy probando KDE Plasma. Instalé KDE Neon y vi que el escritorio era más fuído que hace años, cuando probé KDE, por lo que me he animado a instalar mi distribución preferida con este escritorio.

Desde hace años soy usuario de Fedora; no voy a entrar en la dinámica de si una distribución es mejor que otra: para gustos ya están los colores, y cada uno debe amoldarse a la distribución con la que esté más agusto.

De hecho Fedora es mi distro principal, con Gnome, pero tengo instaladas otras que también uso.

La instalación, como siempre es fácil y rápida (sobre SSD, jeje).

Lo primero que voy a hacer es emparejar el teléfono android con el PC, mediante KDE Connect.

Lo primero de todo es instalar en el teléfono la aplicación KDE Connet que se encuentra en el Google Play (también está disponible en F-Droid, etc...)

Aplicación para el teléfono

Cuando edito las preferencias de KDE Connect y le doy a actualizar para que busque mi teléfono (el cual hay que tener encendido y conectado a la misma wifi que el PC), en principio no me lo detecta. Las opciones, como se ve en la primera imagen, son accesibles desde el grupo de notificaciones: icono triángular, que nos muestra los iconos ocultos, abajo a la derecha; seleccionamos KDE Connect con el botón derecho...

¿¿Motivo??  Pues que en el caso de Fedora, hay que activar el servicio KDE dentro del Firewall (cortafuegos), ya que por defecto, dicho servicio no está activado.


Al cortafuegos (firewall) podemos acceder muy fácil desde el botón de inicio, simplemente comenzando a escribir "cortafuegos" o navegando por el menú hasta llegar a la Aplicaciones de Administración.

Una vez en él, por defecto os aparece la Configuración "en tiempo de ejecución", por lo que los cambios que hagáis se perderán cuando cerréis sesión.  Debéis cambiar a Configuración Permante, como véis en la imagen, y una vez allí, como ya estáis en Zonas y en Servicios, bajáis y buscáis el servicio KDE Connect y lo activáis.

Después reiniciáis el servicio (podéis reiniciar el PC completamente) y ya os aparecerá vuestro dispositivo, podéis emparejarlo con el teléfono... y ya os podréis mover por él con la estructura similar a cualquier árbol de directorios.




Sencillo, ¿no?









Escritorio Gnome
Existe un extensión para Gnome, que dota a este escritorio de la misma funcionalidad que KDE Connect a Plasma. La extensión se llama MConnect, y podéis descargarla desde la web de las extensiones para Gnome.

De hecho se apoya en en KDE Connect, por lo tanto, para usarla en entornos Gnome deberéis
  1. instalar ambos: kde-connect (que suele estar en todos los repositorios)
  2. activar la extensión comentada antes
Una vez hecho esto, en Gnome nos aparecerá una nueva opción, tal y como podéis ver en la imagen anterior.

La primera vez que vayáis a emparejar vuestro teléfono hacerlo con la "Mobile Settings". Esta opción os arranca la misma ventana explicada en la parte superior del artículo.

Seleccionáis vuestro dispositivo y emparejáis (acordaros que si no aparece posiblemente haya que activar el servicio 'kde-connect' dentro de la configuración permanente del cortafuegos.

Una vez hecho esto, el dispositivo siempre estará disponible: con que encendáis una vez la pantalla ya quedan operativas las opciones típicas que véis en la imagen inferior: enviar sms, localizador de vuestro móvil (es como si os hiciéseis una llamada, para que suene y localizarlo), moveros por las carpetas del mismo y compartir contenido.

Como veis, gracias a esta extensión podemos acceder fácilmente a nuestro dispositivo, tanto desde el escritorio Plasma como desde Gnome.

05 agosto 2017

Crear y administrar USB Multiboot, sin programas dedicados

Hace varias semanas, en la web de Lignux.com, los amigos Alex y Jinkros publicaron 2 post que, por mi parte, considero muy buenos.

Se trataba cómo crear un USB Multiboot, para arrancar diversas distribuciones GNU/Linux, y usando únicamente Grub2, es decir, sin hacer uso de programas dedicados que, como sabéis, los han muy buenos (multisystem, Yumi,...)

Jinkros describía el proceso de creación del USB en cuestión: formateo, transferir el GRUB2 para permitir arranque tantos en modo BIOS como en UEFI, esctructura de carpetas, copiar las ISO de las distribuciones elegidas y finalmente adaptar el archivo grub.cfg para que todas ellas fueran instalables.

Alex, por su parte, añadía una vuelta de tuerca, y describía cómo hacer lo mismo, pero primero generando lo que podríamos llamar un USB Virtual, es decir, generar una imagen de disco y hacer todo el proceso anterior sobre ella para, una vez comprobado que todo funciona, volcarlo al USB físico.

¿¿Ventaja de hacerlo como dice Alex??: pues que las pruebas podemos hacerlas sin tener que estar reiniciando el PC constantemente.

Como digo, los artículos son insuperables, por lo que no voy a repetir los mismos pasos. Considero de obligada lectura los mismos:

  1. Particionar imagen de disco, para pruebas
  2. Proceso de creación manual del USB multiboot
En este sencillo post voy a indicar cómo administro y gestiono el llamado USB Virtual (imagen de disco para hacer pruebas), y cómo, después de comprobar que todo funciona correctamente, lo transfiero al USB físico.

Después de haber seguido los pasos anteriores es importante saber que:
  • la imagen de disco (imagen_prueba.img) que hemos creado tiene todo:
    • está formateada en Fat32
    • tiene las particiones que necesita, y los archivos ya copiados
  • para hacer uso de ella en cualquier Sistema (yo tengo varios), y poder editarla, sólo es necesario hacer lo siguiente: 
    • crear el dispositivo de bucle (loop) para el sistema en el que estamos en dicho momento
    • entrar en "parted" y activar la primera partición como arranque
    • montar el dispositivo, para hacerlo accesible a editarlo, etc...
Pasos:

sudo losetup /dev/loop0 /media/Datos/virtualUSB/imagen_prueba.img
sudo parted /dev/loop0
 > (parted) set 1 boot on

Antes de salir de "parted" podemos comprobar que todo ha quedado correcto: para ello ponemos las unidades en 'mib' y luego listamos las particiones con 'p'.

En la imagen podéis ver que yo he creado una imagen de disco de 16 GB.


Si queremos acceder a nuestro USB Virtual, por ejemplo para añadir/borrar alguna ISO, simplemente tenemos que montar la partición activa. Una forma rápida es:

$ udisksctl mount --block-device /dev/loop0p1  (no se necesita privilegios root)

Ahora ya sabemos dónde está montado y vemos el UUID de la citada partición.

Con el explorador de archivos correspondiente podemos acceder a dicha ruta y realizar las modificaciones que consideremos pertinentes.

Siempre vamos a poder probar nuestro USB Virtual mediante QEMU.

En mi caso (estoy en un PC sin UEFI) voy a probar el arranque BIOS:

$ qemu-system-x86_64 \
   -k es \
   -vga std \
   -m 2048 \
   -hda /media/Datos/virtualUSB/imagen_prueba.img

Cada uno usar vuestras rutas

El resultado es el que tenéis en la primera imagen que acompaña el post.

A continuación os paso el contenido de mi archivo grub.cfg:

set imgdevpath='/dev/disk/by-uuid/9526-CA15'

insmod png
insmod part_msdos
insmod fat
insmod ntfs
insmod ext2
insmod tga
insmod gfxterm
insmod lspci
insmod vbe
insmod chain
insmod biosdisk
insmod font

set root='hd0,msdos1'
set timeout=30
set default=0

if loadfont /boot/grub/fonts/unicode.pf2 ; then
    set gfxmode=640x480
    insmod gfxterm
    terminal_output gfxterm

    if [ "${grub_platform}" == "efi" ]; then
        insmod efi_gop
            insmod efi_uga
    fi
  
    if [ "${grub_platform}" == "pc" ]; then
            insmod vbe
            insmod vga
    fi
fi

# Dentro de /boot creo una carpeta nueva:  /splash  y en ella meto el archivo de background
background_image -m stretch /boot/splash/fondo.png

if background_image /boot/splash/fondo.png ; then
    # Texto de las opciones de menú (black = transparente en caso de existir fondo)
    set color_normal=white/black
    # Texto de la opción seleccionada del menú
    set color_highlight=yellow/cyan
    else
        set menu_color_normal=white/black
        set menu_color_highlight=green/white
        set color_normal=white/magenta
        set color_highlight=green/white
fi

menuentry '=== Instalaciones disponibles -CloroPC- ===' {
    echo
}

menuentry 'Manjaro-gnome-17.0.2' --class dvd {
    set isofile='/boot/isos/manjaro-gnome-17.0.2-stable-x86_64.iso'
    set dri="nonfree"
    search --no-floppy -f --set=root $isofile
    loopback loop $isofile
    linux  (loop)/boot/vmlinuz-x86_64  img_dev=$imgdevpath img_loop=$isofile driver=$dri
    initrd  (loop)/boot/intel_ucode.img (loop)/boot/initramfs-x86_64.img
}

menuentry 'Debian-9.1.0' --class dvd {
    set isofile='/boot/isos/debian-9.1.0-amd64-DVD-1.iso'
    loopback loop $isofile
    linux (loop)/install.amd/vmlinuz vga=788 --- quiet
    initrd (loop)/install.amd/gtk/initrd.gz
}

menuentry 'Ubuntu-17.04-gnome' {
    set isofile='/boot/isos/ubuntu-gnome-17.04-desktop-amd64.iso'
    loopback loop $isofile
    linux (loop)/casper/vmlinuz.efi boot=casper iso-scan/filename=$isofile
    initrd (loop)/casper/initrd.lz
}

menuentry 'KDE Neon User Edition ' {
    set isofile='/boot/isos/neon-useredition-20170706-1018-amd64.iso'
    loopback loop $isofile
    linux (loop)/casper/vmlinuz.efi  boot=casper iso-scan/filename=$isofile quiet splash ---
    initrd (loop)/casper/initrd.lz
}

menuentry 'Fedora-Workstation-26' {
    set isofile='/boot/isos/Fedora-Workstation-Live-x86_64-26-1.5.iso'
    loopback loop $isofile
    linux (loop)/isolinux/vmlinuz root=live:CDLABEL=Fedora-WS-Live-26-1-5 iso-scan/filename=$isofile rd.live.image quiet
    initrd (loop)/isolinux/initrd.img
}

menuentry 'Fedora-MATE-26' {
    set isofile='/boot/isos/Fedora-MATE_Compiz-Live-x86_64-26-1.5.iso'
    loopback loop $isofile
    linux (loop)/isolinux/vmlinuz root=live:CDLABEL=Fedora-MATE-Live-26-1-5 iso-scan/filename=$isofile rd.live.image quiet
    initrd (loop)/isolinux/initrd.img
}

menuentry 'openSUSE Tumbleweed (netinstall)' {
    set isofile='/boot/isos/openSUSE-Tumbleweed-NET-x86_64-Snapshot20170801-Media.iso'
    loopback loop $isofile
    set gfxpayload=keep
    linux (loop)/boot/x86_64/loader/linux splash=silent iso-scan/filename=$isofile
    initrd (loop)/boot/x86_64/loader/initrd
}

menuentry '================================================' {
    echo

}

menuentry 'Reiniciar equipo' {
    reboot
}

menuentry 'Apagar equipo' {
    halt
}


Una vez que veáis que todo funciona correctamente, la forma más rápida de transferir dicha imagen de disco a un USB físico (mismo tamaño o superior) es haciendo uso del comando "dd".

Este comando es 'silencioso' es decir, si lo usamos "a pelo" no sabréis con certeza cuándo ha terminado, salvo que vuestra llave usb tenga lucecitas... Personalmente, para copias de gran tamaño, lo hago pasar por la tubería 'PV', para ver una barra de avance del proceso.

PV puede que no lo tengáis insatalado, pero es fácil. Suele estar en todos los repositorios, así que, dependiendo de vuestra distro:
     $ sudo pacman -S pv ......... Manjaro y otras derivadas de Arch
     $ sudo dnf -y install pv ...... Fedora y derivadas
     $ sudo zypper in pv ........... openSuse y derivadas
     $ sudo apt install pv .......... Debian, Ubuntu y derivadas

Luego sólo nos queda transferir la imagen al USB. Para ello, siempre me cambio a 'root' (evito problemas de acceso) y hago lo siguiente:

# dd if=/dev/loop0 |pv|dd of=/dev/sdc bs=4M


En la imagen veis el grado de avance que lleva el proceso de copia...

Un saludo y espero le saquéis utilidad igual que la que le estoy sacando yo.

Problemas que me encontré:
  • La instalación de GRUB2 hacia el USB virtual la hice desde Manjaro, ya que desde otros sistemas me daba problemas de geometría y otras cosas y no perdí tiempo buscando los motivos exactos.
  • La imagen de fondo preferí separarla en una carpeta aparte, redimensionarla a mi resolución (1360x768) y convertirla a 'png'.



04 junio 2017

Drivers NVIDIA en Fedora 26 usando repositorios RPM Fusión (2 pasos)

Hoy vamos a hacer algo parecido al post anterior, pero esta vez usando las compilaciones de los drivers Nvidia que residen en los repos RPMFusión.

La filosofía es la misma:
  • instalar los driver Nvidia y...
  • ...bloquear la ejecución de Nouveau
En teoría, este método se encarga automáticamente de bloquear "nouveau" y añadirlo a la 'lista negra' para evitar conflictos y, además, teniendo instalado todo lo necesario, crea automáticamente los nuevos módulos necesarios cada vez que actualizamos el kernel.

Para probarlo, he descargado nuevamente la versión alpha de Fedora 26, en su versión "net install" (que sólo son 449 mb y me ahorro un tiempo precioso post-instalación, ya que me descarga lo último).

La versión del kernel con la que ha quedado es la compilación 4.11.3-300

Pasos:
 
1.- Habilitar repositorios RPMFusion de nuestra distribución. Puedes hacerlo de forma gráfica, entrando en el sitio de RPMFusion, Enable repos... y seleccionando primero los free y luego los nonfree.....







.... o también puedes hacerlo desde la consola, copiando el siguiente comando:

sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm 
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

2.- Instalar paquetes necesarios: Cualquier tarjeta con GPU GeForce de los últimos 6 años estará contemplada sin problemas con los drivers que residen en RPM Fusion, por lo tanto instalaremos todo lo que nos hace falta:

sudo dnf install xorg-x11-drv-nvidia akmod-nvidia dkms gcc acpid kernel-headers "kernel-devel-uname-r == $(uname -r)"

Muchos paquetes ya los tendremos instalados, no os preocupéis.

Y la magia ya está hecha.  Reiniciamos el equipo para ver si es cierto. Aviso, el primer arranque es un pelín más lento, no ponerse nerviosos.

sudo reboot

Comprobación 1ª - arranca el nuevo driver

Después de arrancar, veo que, efectivamente, está usando el driver Nvidia.

He abierto, el archivo /etc/sysconfig/grub para ver si es cierto que me ha añadido la exclusión de 'nouveau' y, efectivamente ha creado la blacklist correspondiente y me ha añadido la instrucción necesaria:
La imagen anterior es sólo de ejemplo, para fijarse que me ha añadido lo que tengo sombreado. Cada uno podéis tener en vuestro .../grub instrucciones un poco diferentes.

Comprobación 2ª - Actualizo el kernel, para ver si se generan automáticamente los módulos necesarios para que Nvidia siga funcionando.

Veo que en Kernel Fedora Koji tengo una compilación superior para F26, concretamente la 4.11.3-301, así que me bajo los archivos que corresponden a mi arquitectura y los instalo.

Después de la instalación actualizo de nuevo el Grub2 y reinicio completamente con el nuevo Kernel.

Igual que en el paso anterior, tarda un poco más la primera vez pero por lo menos no me sale la temida pantalla negra (que hubiera indicado que no ha podido cargarme el entorno gráfico).


Como diría Don Limpio:  el algodón no engaña !! 

Nota editado 28.05.2018
En la versión Fedora 28, uno de los cambios introducidos es una mejora en la localización de drivers NVIDIA , y lo único que hay que hacer es entrar en el Centro de Software y activar, arriba del todo, el repositorio de software de terceros, con lo que ya se podrán instalar, entre otros, los drivers Nvidia correspondientes a tu tarjeta.


Saludos.

31 mayo 2017

Driver privativo NVIDIA en Fedora 26, con Kernel 4.12 rc3. Instalación manual

Hoy, en Kernel - Fedora Koji, han liberado la 3ª versión candidata del Kernel 4.12... y como no puedo estar quieto, he ido a por ella, tal y como comenté en un post anterior.


... Y he "roto" el arranque GDM, con este nuevo Kernel y los drivers privativos de Nvidia, así que toca arreglarlo.

Para los primeros pasos tenéis que arrancar con el kernel anterior de vuestro Grub2 y que sí funcionaba.

Los drivers privativos Nvidia entran en conflicto con el driver Nouveau, que viene por defecto en Fedora, por lo tanto, el proceso pasa por:
  1. Impedir la carga del driver nouveau, añadiéndolo a una "lista negra"
  2. Desinstalarlo completamente
  3. Actualizar el Grub2
  4. Generar un nuevo "initramfs", que no tenga referencias a Nouveau
  5. Y por último, instalar el driver privativo NVIDIA.
Personalmente, siempre me lo descargo de su web oficial, en formato *.run, para luego ejecutar la instalación con este archivo.

1.- Identificar vuestro modelo de tarjeta gráfica

     $ sudo lspci -v | less  (comando extenso, que lista todo; desplazarse hasta llegar a la sección de la VGA)

     $ sudo lspci | grep VGA  (comando corto, y filtrando sólo la gráfica)
 
Ya no hay duda: tengo una gráfica GeForce modelo GT 610, es decir, serie 600

2.- Localizar el último driver  (desplegar 'Mostrar todos los sistemas operativo, si es necesario)
3.- Buscar y descargar el archivo con extensión *.run.  A la hora de escribir este post, el último driver para mi modelo es la 375.66, de 4 de mayo...

http://es.download.nvidia.com/XFree86/Linux-x86_64/375.66/NVIDIA-Linux-x86_64-375.66.run

4.- Dar permisos de ejecución al archivo descargado:
     $ sudo chmod +x NVIDIA-Linux*.run
(si prefieres entorno gráfico, botón derecho del ratón sobre el archivo descargado, propiedades y, en permisos, activas permitir ejecutar como un programa)

5.- Actualiza tu sistema y asegura que tienes todo lo necesario:
     $ sudo dnf -y update 
     $ sudo dnf install kernel-devel hernel-headers gcc dkms acpid

6.- Deshabilita "Nouveau"
     $ sudo echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
     (si el archivo blacklist.conf no existe, se creará)

7.- Edita (sirve cualquier editor) /etc/sysconfig/grub, busca la línea que comienza por GRUB_CMD_LINUX= y al final del todo (y que quede dentro de las comillas), añade lo siguiente:

     rd.driver.blacklist=nouveau

     $ sudo leafpad /etc/sysconfig/grub  (si no tienes este editor y te gusta, instálalo con dnf install leafpad)

En mi caso, éste sería mi archivo, con el añadido.

8.- Actualizar el Grub y remover el driver nouveau.

     $ sudo grub2-mkconfig -o /boot/grub2/grub.cfg  (para BIOS MBR.  En UEFI, el comando de actualización es distinto, pero como no puedo probar si el proceso funciona exactamente igual, no lo pongo para no confundir)
     $ sudo dnf remove xorg-x11-drv-nouveau

9.- Ahora toca generar un nuevo "initramfs"
Por si la "cagamos" (en mi caso es muy habitual), hago una copia de seguridad del initramfs actual y genero uno nuevo:
     $ sudo mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r)-nouveau.img
     $ dracut /boot/initramfs-$(uname -r).img $(uname -r)

10.- Ahora toca instalar, pero para ello debemos parar completamente el entorno gráfico y hacer todo en modo texto. Hay varias formas:
  • En algunas web usan systemctl para cambiar por defecto en modo de arranque y configurarlo en el denominado 'runlevel 3', que no tiene entorno gráfico.
  • En otras, simplemente abren una de las terminales (Ctrl+Alt+F3, por ejemplo) y una vez logeados allí, deshabilitan GDM y lo paran; cuando terminan, vuelven a habilitarlo y lo inician de nuevo.
Yo he probado las 2 y me funciona bien. De todas formas, voy a dar sólo las instrucciones del primer paso, ya que así me aseguro de que no queda ningún rastro de nouveau y que xorg no está cargado.
     $ sudo systemctl set-default multi-user.target
     $ sudo reboot   (a partir de ahora ya no tendrás entorno gráfico, así que imprime las instrucciones siguientes)

Una vez iniciado el equipo nos podemos logear como root directamente, y así nos ahorramos el estar poniendo el 'sudo'

Nos vamos manualmente a la carpeta donde habíamos descargado el binario de NVIDIA y lo ejecutamos. Si en dicha carpeta no tenéis otros binarios de NVIDIA que se "solapen" podéis usar comodines para no teclear el nombre completo del archivo:

     # cd /media/Datos
     # ./NVIDIA-Linux*.run

Vamos contestando a todo que sí. Cuando nos pregunte si queremos que DKMS intente generar nuevos módulos cuando actualicemos el Kernel, le decimos que SI. Si por cualquier causa nos da error, podemos probar indicándole que NO, que si no recuerdo mal es la opción por defecto.

Cuando todo termine (espero que "correctly"), debemos cambiar de nuevo el modo por defecto del arranque, para que nos vuelva a arrancar en el entorno gráfico... Es lo que se llama 'runlevel 5':

     $ sudo systemctl set-default graphical.target
     $ sudo reboot

Y si todo ha ido bien, tenéis que tener correctamente instalado el driver y la utilidad de Nvidia-Settings:


NOTA: Mi experiencia y uso con Nouveau, para lo que necesito, es perfecta, por lo que en mi caso, usar el driver privativo es un mero capricho ya que no juego ni hago uso intensivo de mi gráfica.... pero para gustos los colores..!!!  :-)

Actualizar de Fedora 25 a Fedora 26, sin reinstalar

Aprovechando que hoy es fiesta en Castilla-La Mancha (España), he decidido que hoy tocaba bricolaje informático, así que me he puesto a actualizar el equipo fijo que tengo, para pasar de Fedora 25 a Fedora 26, utilizando las instrucciones que dan en la propia wiki de Fedora.

Ubuntu tiene su apt update-manager -d, que sirve para actualizar de versión sin reinstalar; este proceso en Fedora es similar, conceptualmente hablando.

El proceso es bastante sencillo y limpio, pero aviso que la actualización es lenta... (claro que si tienes discos SSD será bastante más rápido).

Se resume en poco pasos:

- Tener actualizados todos los paquetes.
- Instalar el plugin system upgrade, para DNF, que se encargará de administrar el proceso de actualización.
- Descargar los paquetes correspondientes a la release a la que queremos actualizar...
- Resetear de nuevo el equipo usando system-upgrade, con lo que se arrancará de nuevo el equipo, con nuestro Grub habitual (no detectaremos ningún cambio), y comenzará el proceso de actualización con todos los paquetes descargados en el paso anterior.

System-upgrade hará varias cosas:
  • Inhabilitará repositorios que considere oportuno, para evitar conflictos
  • Habilitará los nuevos que toquen, y nos pedirá permiso para importar sus claves de firma
  • Descargará todos los paquetes de la nueva distribución
  • Y actualizará todo.
 Instrucciones (seguir en orden):


$ sudo dnf upgrade --refresh
$ sudo dnf install dnf-plugin-system-upgrade
$ sudo dnf system-upgrade download --refresh --releasever=26
$ sudo dnf system-upgrade reboot 


Al terminar la descarga,  nos pedirá que reiniciemos usando el siguiente comando


dnf system-upgrade reboot

Así que, como somos muy obedientes, hacemos caso...



El equipo arrancará y comenzarán a instalarse todos los paquetes.

Este proceso a mí me ha tardado más de 1 hora, así que tener a mano el café, el zumo de naranja y el pan para ir haciéndoos una tostada de tomate con aceite que, a parte de ser muy sano, servirá para aguantar la espera.


El "miedo" que yo tenía era si me iba a configurar correctamente la tarjeta NVIDIA que ya tenía configurada en Fedora 25 con los drivers privativos. Mi sorpresa ha sido mayúscula cuando he visto que todo ha quedado perfecto y a la primera, sin necesidad de intervenir de nuevo en la actualización. En su día dejé instalado 'akmod-nvidia', para que las nuevas actualizaciones del kernel me fueran generando automáticamente los módulos necesarios.

Este equipo, como podéis ver, es un core duo, por lo tanto, su BIOS todavía era MBR (no tiene UEFI).
8 GB de RAM y un par de discos duros mecánicos (HDD), con una NVIDIA de 2 GB que me lleva años funcionando perfectamente. De hecho, el ordenador me lo hice hará casi 10 años, con una placa ASUS P5K SE/EPU y todo gobernado con una fuente de alimentación de 630W que, a fecha de hoy, sigue funcionando perfectamente.

En el supuesto de que algo de lo que use me haya dejado de funcionar... pues ya lo solucionaré cuando se me presente el caso, mientras tanto... me he ahorrado la descarga y el tener que hacer un USB de arranque para reinstalar.

Saludos y sin miedo que, siempre que vuestras fotos y archivos personales (que en el fondo es lo importante para un usuario doméstico) los tengáis a salvo en nube o en otra partición, lo peor que puede pasar es que tengáis que reinstalar desde cero, pero, como os digo, no ha sido mi caso.

Último consejo:   

$ sudo dnf -y update
 

18 mayo 2017

Actualizar al último Kernel disponible en Fedora

Esta entrada es para "valientes":
  • ¿eres osado?
  • ¿tienes vértigos?
  • ¿te atreves con el último kernel, aunque no esté publicado aun en el repo oficial de la distro?
Pues vamos a ello.

Según podemos leer en Fedora Magazine, dentro de los paquetes Koji podemos navegar hasta la última construcción preparada del kernel que finalmente aterrizará en Fedora.

Es bastante estable, pero todavía no son definitivos y, por tanto, no están en los repos oficiales.

No obstante, si te atreves...



Desde este enlace accedes a las construcciones. Lo colocas por la última fecha de modificación y vas navegando a través del kernel hasta que llegues a tu arquitectura.
Yo me bajo siempre los siguientes paquetes: kernel, kernel-core, el devel, los headers y los 2 archivos de modules:


Una vez descargados, con la consola es muy fácil su instalación (ojo, cada uno vuestra ruta):

sudo dnf -y install /media/Datos/*.rpm  (yo tengo separada la carpeta de descarga en una ruta independiente, que es común a todas las distros que uso)

Y en el siguiente arranque estaréis con la última versión empaquetada por Koji.

A disfrutar :-)

23 abril 2017

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.

16 abril 2017

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



13 abril 2017

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!!

08 abril 2017

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.


02 abril 2017

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.

Último post

Preparando un espacio de trabajo

            Ahora que tengo tiempo, retomo el blog. Por comodidad (y por capricho) he elegido la siguiente configuración: He optado por un ...