Definamos Normal.

El Blog personal de Rafael Rojas

Category: Optimizacion (page 1 of 2)

El innecesario legado de separar /boot

Algo que veo repetido en casi todas las guías de instalación de Arch Linux es la parte del particionado: separar el directorio /boot en otra particion, ¿por que?

Hasta hace poco se lo atribuía a la guía de instalación “oficial” publicada en el sitio de archlinux, pero tal fue mi sorpresa de que incluso ellos actualizaron la guía de instalación y ahora no menciona nada de separar raiz / y /boot.

Y por que separar /boot?

Las razones por las que se necesita (y por que no se necesita) separar /boot son:

El sistema  no puede iniciar si /boot esta dentro de un LVM, necesita estar separado.
Cierto hasta que se implemento GRUB2, los sistemas que inicien desde GRUB0.99 (o grub legacy) tendran que sacar /boot de su arreglo de discos LVM.

Mayor velocidad de arranque si esta formateado con ext2.
Verdad a medias. Si bien es cierto que un filesystem sin journaling es teoricamente mas rapido, con las recientes implementaciones de filesystems (ext4, btrfs) esta diferencia es imperceptible para el usuario de escritorio, sin contar discos duros modernos o SSD.

Seguridad, si el sistema se daña puedo reiniciar mi sistema, montar /boot y reparar cosas.
Valido si usas LVM o LUKS, de cualquier otra forma no tiene caso.

Compartir /boot con otras instalaciones de Linux.
Pues si, /boot puede ser otra partición accesible para 2 diferentes sistemas Linux. Técnicamente se puede, aunque no se ahorrarian mas que un par de MB en espacio y el detalle de que 2 gestores de paquetes toqueteen el mismo directorio no me da espina.

Entonces, ¿esta mal que separe /boot en mi instalacion de mi equipo personal?. No, solo es innecesario en la inmensa mayoria de los casos. Aunque siempre recomiendo hacer pruebas y usar de vez en cuando otros esquemas mas avanzados de particionado. 🙂

Oye Systemd, devuelveme los nombres de mis interfaces de red!

Desde la edición 197 de Systemd, este se encargo de la maravillosa tarea de renombrar nuestras interfaces de red, siguiendo una clara política establecida en FreeDesktop.org que establece los siguientes parametros para nombrar interfaces de red:

With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname’s (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

  • Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  • Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  • Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  • Names incorporating the interfaces’s MAC address (example: enx78e7d1ea46da)
  • Classic, unpredictable kernel-native ethX naming (example: eth0)

Esto es que Udev (ya integrado en systemd) nombrara las interfaces de red bajo la política de:

Primero por el numero de serie establecido en el Firmware/BIOS (eno1)
De no ser posible por el numero del slot de conexión de la interfaz proveído por el Firmware/BIOS (ens1)
Si no, por la localización geográfica del conector (enp2s0)
O incorporando la MAC address al nombre de la interfaz (en mi opinión, el mas útil: enx78e7d1ea46da).
Finalmentepor el nombramiento clásico estándar del kernel (eth0)

Este cambio es meramente opcional si es que actualizas de una versión anterior de systemd, pero si has instalado ArchLinux en los últimos 4 meses, así sera el nombramiento de las interfaces.

Selección_007

Pero, que tal si no quiero batallar con los nombres de las interfaces de red todavia?
Simple: eliminamos la regla de udev que las nombra así, con un comando tan simple como:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

(o borrando directamente el archivo también).

A la hora de reiniciar el sistema el nombre canónico que el kernel le pone a las interfaces de red ha vuelto, solo falta otro ip link show para verificar:

Selección_008

En base a la depreciación de inet-tools, mucha gente no conoce muy bien el uso de ip link, mañana un post al respecto.

PD. Esto aplica para toda distro con systemd 197 o superior (Fedora, OpenSuSe, etc)

prescindir de la imagen fallback de ArchLinux

initgrub

Arch utiliza por default 2 imágenes del kernel /boot/initramfs-linux.img y /boot/initramfs-linux-fallback.img La diferencia entre estas es que la imagen fallback tiene deshabilitado el hook autodetect cuya función es agregar al initramfs la lista de módulos utilizados por el hardware del equipo a través de un escaneo con sysfs.

La imagen fallback tiene este modulo deshabilitado por si bajo alguna actualización del sistema hay algún modulo causando conflicto podamos iniciar con esta imagen, cargar los modulos manualmente y deshabilitar o reparar el modulo conflictivo  Cabe aclarar que ambas imágenes están hechas con la misma versión del kernel.

Mi cuestión es: corro arch sobre una laptop que no tiene cambios de hardware y que no le hago grandes cambios a los módulos del kernel, realmente necesito esta imagen fallback?

Y como honestamente no la necesito pues la puedo deshabilitar.

Editamos el archivo de pre configuraciones del kernel:

vi /etc/mkinitcpio.d/linux.preset

Un interesante archivo con contenido como este:

# mkinitcpio preset file for the 'linux' package
 
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux-ck"
 
PRESETS=('default' 'fallback')
 
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux-ck.img"
#default_options=""
 
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="/boot/initramfs-linux-ck-fallback.img"
fallback_options="-S autodetect"

Editamos los presets quitando ‘fallback’y comentamos las lineas fallback_image y fallback_options quedando asi:

PRESETS=('default')
 
#default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux-ck.img"
#default_options=""
 
#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-linux-ck-fallback.img"
#fallback_options="-S autodetect"

Luego recreamos la imagen del kernel:

mkinitcpio -p linux

EDIT 14-abril

Tambien ahy que eliminiar la vieja imagen fallback manualmente:

rm /boot/initramfs-linux-fallback.img

Actualizamos el grub:

grub-mkconfig -o /boot/grub/grub.cfg

Y listo, ya no hay imagen fallback, si queremos regresar los cambios devovlemos el archivo /etc/mkinitcpio.d/linux.preset a su estado original, recreamos las imagenes de arranque y actualizamos el grub, tambien es interesante que en ese archivo podemos configurar personalizaciones de la imagen de arranque con nuestros propios hooks, pero eso sera otra cosa.

Hacer que el grub recuerde el ultimo sistema operativo que inicio

Hay algunas versiones de Linux que tienen el grub configurado para que este recuerde el ultimo sistema operativo con que se inicio y lo tenga seleccionado como default. Esto es muy útil cuando usas un equipo con múltiples sistemas operativos (Windows y/o Linux) y andas reiniciando entre ellos.

Hay dos opciones que vamos a tomar de la documentación oficial del grub (no la wiki de Arch): GRUB_DEFAULT y GRUB_SAVEDEFAULT:

‘GRUB_DEFAULT’
……………..
If you set this to ‘saved’, then the default menu entry will be that saved by ‘GRUB_SAVEDEFAULT’, grub-set-default, or grub-reboot.

‘GRUB_SAVEDEFAULT’

If this option is set to ‘true’, then, when an entry is selected, save it as a new default entry for use by future runs of GRUB. This is only useful if ‘GRUB_DEFAULT=saved’; it is a separate option because ‘GRUB_DEFAULT=saved’ is useful without this option, in conjunction with grub-set-default or grub-reboot. Unset by default. This option relies on the environment block, which may not be available in all situations (see Environment block).

Ok, para hacer esto en nuestro ArchLinux, o en cualquier distro con grub2 ya que los archivos son estándar, hay que editar el archivo /etc/default/grub y

Editar esta linea asi (el default es cero):

GRUB_DEFAULT=saved

Y descomentar esta otra:

GRUB_SAVEDEFAULT=true

Por ultimo editamos el archivo /etc/grub.d/40_custom y agregamos al final la opción:

savedefault

Al final actualizamos el grub

grub-mkconfig -o /boot/grub/grub.cfg

Y listo.

Si por ejemplo tienen ArchLinux y Windows, reinician el equipo con Windows, y al reiniciar de nuevo Windows sera la opción default hasta que inicien con Arch 😀

Protip: afinar el control de volumen en kmix

Kmix es la herramienta de control de audio de KDE, controla las entradas y salidas de audio y trabaja con pulseaudio para manejar perfectamente los dispositivos de audio.

kmix

Funciona bien, solo hay un detalle: cuando subía o bajaba el audio desde el teclado, kmix daba grandes saltos (del 20%) haciendo que modificar un poco el volumen fuera o muy alto o muy bajo, y eso pues es exasperante….

Pero se puede solucionar

Solo basta editar el archivo kmixrc y agregar una linea:

abrimos el archivo:

vi $HOME/.kde4/share/config/kmixrc

En algunas distros el directorio de configuración de usuario es .kde, en archlinux es .kde4

Y justo debajo de la sección [global] agregar: VolumePercentageStep= con el porcentaje de cambio de volumen, el mio quedo así:

kmix1

El cambio queda del 1.5% y no del 20% como era antes, mucho mejor para mi y mi laptop 😀

Por ultimo solo queda reiniciar kmix para que queden los cambios:

pkill kmix && kmix &

Mi volumen ya no queda como alto-medio-bajo. Saludos!

Benchmark de herramientas para AUR

AUR es el repositorio de usuarios de archlinux donde todos podemos subir un pkgbuild para compilar/instalar/administrar algun paquete de software no soportado oficialmente por la distribucion. El detalle de AUR es que no cuenta con una herramienta oficial para su manejo (asi es, yaourt no es oficial) y los usuarios tenian que ir hasta la pagina de AUR para descargar sus pkgbuilds y tener una administracion a mano.

Despues empezaron a salir muchos scripts, en principio sencillos, que ayudaban al usuario a conectarse al repositorio de AUR y descargar y aplicar estos pkgbuilds, en ingles se llaman AUR Helpers, en español son herramientas para AUR, y eso es lo que es yaourt, packer, aurget y demas.

Hay un monton de herramientas para AUR listadas en la wiki de ArchLinux, muchas muy basicas, otras todavia en desarrollo, unas totalmente abandonadas y todas generalmente hacen mas o menos lo mismo de forma ligeramente diferente. Pero, que pasa si nos ponemos a testear estas herramientas?.

El test, que no esta hecho meramente por procedimiento cientifico, hecho por el usuario monoloco de los foros de ArchLinux nos muestra los resultados de varias pruebas a esta herramienta utilizando el mismo criterio de busqueda y de instalacion: un paquete de python, los resultados:

En orden de velocidad, medida en segundos, de mas rapido a menos rapido

yaourt                 6.365
packer     (A)         6.587
meat       (A)         7.506
pacaur                 7.585
cower      (A)         8.073
spinach                8.786
packer                16.385
aura       (A)        19.426
packer     (A)        19.859
aurget     (A)        20.805
aurora     (A)        21.335
owl        (A)        23.367
owl                   27.197
paktahn               28.349
pbfetch              1:09.67
pbfetch    (A)       1:09.72
PKGBUILDer (A)       1:49.46

El termino (A) indica que la herramienta solamente maneja paquetes de AUR y no de repositorios (no es ayudante de pacman)

En orden de uso de CPU (de menor a mayor)

packer     (A)           0.8%
cower      (A)           1.4%
meat       (A)           1.6%
pacaur     (A)           2.0%
aura       (A)           2.6%
pacaur                   3.2%
spinach                  3.2%
packer                   3.2%
yaourt                   4.6%
aurget     (A)           5.2%
owl                     16.2%
owl        (A)          16.4%
paktahn                 28.2%
aurora     (A)          34.0%
pbfetch    (A)          34.8%
pbfetch                 35.2%
PKGBUILDer (A)          88.8%

Interesante dato a tomar en cuenta si queremos afinar tan a detalle el consumo de recursos de el sistema. hay que aclarar que estos datos son de busqueda de paquetesy tiempo de respuesta, el tiempo de compilacion depende absolutamente de la capacidad de hardware de el equipo.

Si quieren leer la nota original aqui esta el tema en los foros de archlinux.

AUI: post instalacion y configuracion de ArchLinux hecho facil, muy facil

Recientemente me tope con un script de post instalación de ArchLinux bastante interesante, tenia la idea de hacer algo parecido para post instalar mi equipo cada vez que ando haciendo experimentos o probando otras distros y vuelvo a ArchLinux, o para instalar Arch fácilmente en otros equipos.

Cabe aclarar que esto de los scripts de post instalación y configuración de ArchLinux no es algo nuevo, personalmente no me gustaban: preferia hacerlo yo mismo o sentia que los scripts perdian partes importantes de la configuración de un sistema, pero este me gusto por que cubre literalmente todo lo que puedas necesitar para un sistema bien instalado, estable y limpio, por eso sera el único script que recomiende.

NOTA: aunque este script automatize toda la configuracion de ArchLinux a un nivel Ubuntu (y por eso me refiero a un nivel ultrabasico) no recomiendo su uso para usuarios novatos o recien iniciados en ArchLinux, si vas a instalar Arch por primera vez aprende bien, aprende con la guia de instalacion.

Con la premisa de que ya instalaron el sistema base y que estas en la consola de root con el sistema “a pelo” y que hay una conexion de red funcionando, podemos proceder a utilizar este script

¿Que hace AUI?

Uff, la lista es larga:

  • Configura automaticamente el rc.conf
  • Instala repositorios adicionales (opcional)
  • Configura rankmirror y optimiza los mirrors de descarga y pacman
  • Actualiza el sistema
  • Crea y configura un nuevo usuario (y sudo)
  • Instala un ayudante de AUR[yaourt, packer]
  • Instala el sistema base
  • Instala Xorg
  • Instala drivers de video
  • Instala CUPS
  • Instala drivers/firmware adicionales de wireless o bluetooth
  • Asegura el acceso a GIT a traves de un firewall
  • Instala y configura un servidor LAMP
  • Instala un entorno de escritorio [GNOME, KDE, XFCE, LXDE, OpenBox, Cinnamon]
  • Instala herramientas de desarrollo [Vim, Emacs, Eclipse…]
  • Instala Suite de oficina [LibreOffice, GNOME-Office, Latex…]
  • Instala herramientas del sistema [Wine, Virtualbox, Grsync, Htop]
  • Instala aplicaciones de graficos [Inkscape, Gimp, Blender, MComix]
  • Instala aplicaciones de Internet [Firefox, Google-Chrome, Jdownloader…]
  • Instala aplicaciones multimedia [Rhythmbox, Clementine, Codecs…]
  • Instala juegos [HoN, World of Padman, Wesnoth…]
  • Instala fuentes [Liberation, MS-Fonts, Google-webfonts…]

Y mucho mas, todo opcional, todo configurado correctamente y con los demonios necesarios configurados en /etc/rc.conf

¿Y como lo uso?

Simplemente despuesd e haber reiniciado el sistema despues de instalar, en la consola de root: Continue reading

udev hacia systemd-tools y systemd a [core]

Hace unos meses hablaba de systemd, ese sistema de arranque que pretende remplazar a sysvinit y/o a initscripts. Muchas distribuciones como Fedora o Mageia han hecho el cambio completo a systemd, ArchLinux en un futuro hará también ese cambio.

De entrada esta semana se ha incluido systemd al repositorio core, aparte de que systemd y udev se han fusionado en un solo paquete llamado systemd-tools, ahora, este cambio trajo consigo muchas confusiones, que espero poder aclarar algunas:

Systemd-tools no reemplaza a udev, udev esta dentro de un metapaquete llamado systemd-tools, nada mas
No es necesario instalar y configurar todo systemd para tener systemd-tools, ergo systemd-tools no modifica o afecta el gestor de arranque del sistema.
Al actualizar el sistema udev sera sustituido por systemd-tools, si se actualiza el kernel en la misma actualización, la creación de la imagen de arranque alegando que udev no fue encontrado, para eso al final de la actualización regeneramos la imagen de linux con

mkinitcpio -p linux

Acabara la creacion de la imagen de arranque sin problemas.

Systemd (el gestor de arranque) ya se encuentra instalable desde la instalacion en red de ArchLinux, pero este sigue generando conflictos con sysvinit, asi que no se recomienda su seleccion para instalacion:

Esperemos que dentro de los siguientes meses systemd pueda sustituir por completo el gestor de arranque de ArchLinux (y esperemos que se pasen por el grub y pongan de una vez grub2 desde un principio)

Grub2 en ArchLinux

EL GRUB es el gestor de arranque mas utilizado en las distribuciones de GNU/Linux, por su facilidad de uso,e scalabilidad y facilidad de configuracion su uso se extendio hasta casi remplazar a otros gestores de arranque como LILO.

ArchLinux aun maneja por default una version antigua del GRUB, (grub-0.99). Es con este gestor de arranque con el que se instala por default el sistema operativo, dejando un archivo de configuracion global en /boot/grub/menu.lst. No es estrictamente necesario cambiar esta version del grub, que funciona perfectamente en sistemas de un solo sistema operativo, dos o mas. Pero siguiendo el modo bleeding edge de los paquetes de ArchLinux, podemos instalar y configurar el grub2 (Grub 1.99).

Caracteristicas o mejoras del grub2:

  • Soporte para Scripting, declaraciones condicionales y funciones (programabilidad)
  • Carga de modulos de manera dinamica
  • Modo de rescate
  • Menus personalizables
  • Capacidad para menu de arranque grafico y soporte para temas personalizados
  • Capacidad para iniciar de imagenes ISO
  • Nueva estructura de configuracion
  • New configuration file structure
  • Multiplataforma (no solo x86)
  • Identificacion de dispositivos por UUID

Instalacion en ArchLinux
Continue reading

Wicd: un buen reemplazo para NetworkManager

Sucede que había estado teniendo problemas con mi conexión inalámbrica y NetworkManager, administro la conexión inalámbrica de mi trabajo con una clave WPA2-PSK Enterprise de 32 caracteres y filtrado por Mac Address y bajo ninguna fórmula había logrado conectarme a internet usando específicamente NetworkManager, usando Gnome o KDE o cualquier frontend QT/GTK.

El problema es simple: se autentificaba y conectaba a la red, obtenía dirección IP pero simplemente no tenia conexión a internet, no me resolvía el ping ni el traceroute y no podía ni navegar ni conectarme a ningún sitio tanto al Internet como a equipos y servicios de la red interna y el network manager me confirmaba que estaba conectado a la red

Investigando un poco en el tema, y sin posibilidad de cambiar la configuración wireless sin afectar a los otros usuarios, veo que hay bugs reportados sobre network manager teniendo este problema.

Durante los días que utilice Ubuntu también estuve teniendo ese problema de conexión.

La solución sensata? cambiar de gestor de red.
Continue reading

Older posts

© 2017 Definamos Normal.

Theme by Anders NorenUp ↑