Cristian Vicente

Resulta bastante útil tener disponible diversas distribuciones de Linux, herramientas e incluso un instalador de Windows con sólo conectar un equipo a la red. Hoy en día prácticamente cualquier equipo puede arrancar mediante PXE y la única pega es que pueden utilizar un sistema basado en UEFI o en BIOS de toda la vida. Este hecho nos limita las versiones y software que podemos utilizar a la hora de desplegar un servidor que cubra nuestras necesidades.

Syslinux

El primer intento que hice fue utilizando un servidor basado en Dnsmasq + Syslinux y funcionaba muy bien para los equipos con arranque en BIOS, pero para que los que tuviesen UEFI pudieran también arrancar tuve que dar con la versión de syslinux-6.04. Con esta versión podía arrancar los equipos con UEFI.

La configuración del servidor Dnsmasq que convivía con el propio servidor DHCP del router era la siguiente:

# Deshabilita el servidor DNS
port=0

# Se indica el servidor TFTP

dhcp-option=66,»192.168.1.200″

# Habilita la depuración
log-dhcp

# Responderá a las peticiones PXE y actuará de proxy para el otro servidor DHCP
dhcp-range=192.168.1.0,proxy

# Dependiendo de la arquitectura activamos una etiqueta
dhcp-match=x86PC, option:client-arch, 0 #BIOS x86
dhcp-match=BC_EFI, option:client-arch, 7 #EFI x86-64

# Dependiendo de la arquitectura del cliente se carga una imagen diferente
pxe-service=tag:x86PC,X86PC, «Install Linux on x86 legacy BIOS», bios/pxelinux.0
pxe-service=tag:BC_EFI,BC_EFI, «Install Linux on x86-64 UEFI», efi/syslinux.efi,192.168.1.200

# Dependiendo de la etiqueta se da una imagen u otra de arranque
dhcp-boot=tag:x86PC,bios/pxelinux.0 # for Legacy BIOS detected by dhcp-match above
dhcp-boot=tag:BC_EFI,efi/syslinux.efi,192.168.1.200 # for UEFI arch detected by dhcp-match above

# Se habilitar el servidor TFTP incorporado y el directorio donde se almacena todo
enable-tftp
tftp-root=/var/lib/tftpboot

Esto al principio funcionaba para BIOS y UEFI. Parecía que funcionaba bien pero no era así, el soporte de este último en syslinux está todavía poco pulido y no existe alternativa viable para usar Memdisk, una utilidad que nos permite cargar en memoria una ISO para que el equipo en red sea capaz de arrancar con ella. Por lo que el instalador de Windows se nos hacía imposible entre otras cosas.

iPXE

Tras muchas vueltas acabé cambiando el sistema para utilizar Dnsmasq+iPXE que parecía tener mejor proyección. Tuve que leer mucha documentación, muchos foros y realizar muchas pruebas que, debido a la poca posibilidad de depuración de Dnsmasq, se hace tortuoso. Finalmente di con esta configuración que adapté a mi gusto y entorno:

# Deshabilitar servidor DNS
port=0
dhcp-option=66,»192.168.1.204″

# Habilitar depuración de DHCP
log-dhcp

# Habilitar el modo proxy de DHCP
dhcp-range=192.168.1.0,proxy

# Para los equipos que arranquen como iPXE y manda la opción 175
dhcp-match=set:ipxe,175

# Para cada arquitectura se asigna una etiqueta concreta
dhcp-vendorclass=set:bios,PXEClient:Arch:00000
dhcp-vendorclass=set:efi32,PXEClient:Arch:00002
dhcp-vendorclass=set:efi32,PXEClient:Arch:00006
dhcp-vendorclass=set:efi64,PXEClient:Arch:00007
dhcp-vendorclass=set:efi64,PXEClient:Arch:00008
dhcp-vendorclass=set:efi64,PXEClient:Arch:00009

# Para romper el bucle, aquello que llevan la etiqueta ipxe tienen un arranque diferente
tag-if=set:loadbios,tag:!ipxe,tag:bios
tag-if=set:loadefi32,tag:!ipxe,tag:efi32
tag-if=set:loadefi64,tag:!ipxe,tag:efi64

# Para los equipos que siendo de tipo BIOS arrancan con su propio iPXE pero queremos que cojan el nuestro
tag-if=set:loadCombo,tag:ipxe,tag:bios

# Se administra una imagen de arranque particular para cada arquitectura
pxe-service=tag:loadbios,x86PC,»iPXE Network boot (BIOS)»,ipxe/bios/undionly.kpxe
pxe-service=tag:loadCombo,x86PC,»iPXE Network boot (BIOS)»,ipxe/bios/undionly.kpxe
pxe-service=tag:loadefi32,IA32_EFI,»iPXE Network boot (EFI32)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi32,BC_EFI,»iPXE Network boot (EFI32)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi64,X86-64_EFI,»iPXE Network boot (EFI)»,ipxe/efi/ipxe.efi
pxe-service=tag:loadefi64,IA64_EFI,»iPXE Network boot (EFI)»,ipxe/efi/ipxe.efi

# Para los que ya arrancan en iPXE se les pasa el menú
# Para el loadCombo no hace falta porque la imagen undionly lo lleva compilado dentro
dhcp-boot=tag:ipxe,tag:!loadCombo,http://192.168.1.204/bootMenu.ipxe

# Habilitamos servidor TFTP e indicamos su ruta
enable-tftp
tftp-root=/var/lib/tftpboot

Pero para poder hacer funcionar esta configuración en equipos BIOS con su propio iPXE, debemos compilar una versión propia del cargador de arranque «undionly.kpxe», pues no queda más remedio que incrustar el menú de arranque, aunque también nos deja la puerta abierta para añadir ciertas personalizaciones. Para ello debemos bajarnos el fuente:

• git clone git://git.ipxe.org/ipxe.git

Y creamos un fichero «ipxe/src/chain.ipxe» con el siguiente contenido:

#!ipxe

dhcp
chain http://192.168.1.200/bootMenu.ipxe

Procedemos a su compilación:

• make bin/undionly.kpxe EMBED=chain.ipxe

Y copiamos el fichero generado («bin/undionly.kpxe») a su sitio correspondiente dentro del árbol de nuestro servidor TFTP.

A todo esto deberemos tener un servidor web Apache (o similar) que nos pueda ir entregando ciertos fichero como el del «bootMenu.ipxe» que yo he utilizado para cargar un Windows PE:

#!ipxe

kernel wimboot
initrd win10/files/bcd bcd
initrd win10/files/boot.sdi boot.sdi
initrd win10/files/boot.wim boot.wim
boot

La estructura por tanto queda de la siguiente forma dentro de «/var/lib/tftpboot»:

• /apache2
  • bootMenu.ipxe
  • index.html
  • wimboot
  • /win10
    • /files
      • bcd
      • boot.sdi
      • boot.wim
• /ipxe
  • /bios
    • undionly.kpxe
  • /efi
    • ipxe.efi

Pi-Hole es un servidor intermediario de DNS que filtra las petición de aquellas URL’s que contienen publicidad, haciendo la navegación más limpia y rápida. Ideal para aquellos dispositivos donde no tenemos acceso de administración como en un teléfono móvil Android o iPhone, porque no tenemos que instalar nada más adicional en estos terminales.

Su instalación se puede hacer en una simple Raspberry Pi o, como es mi caso, un contenedor LXC en Proxmox. Después de desplegar una imagen básica de Debian desde Turnkey, descargaremos el instalador de Pi-Hole:

• wget -O basic-install.sh https://install.pi-hole.net

Tendremos que realizar una pequeña modificación porque el instalador busca el fichero «/etc/apt/sources.list», cuando nuestro sistema lo tiene en «/etc/apt/sources.list.d/sources.list». Abriremos con «nano basic-install.sh» el instalador, buscaremos (CTRL+W)  el término «APT_SOURCES» y modificaremos su valor para que quede de la siguiente forma:

• APT_SOURCES=»/etc/apt/sources.list.d/sources.list»

Con eso debería bastar pero, en mi caso, al intentar instalar las dependencias el instalador se me cortó y tuve que instalar una de ellas a mano con el siguiente comando:

• apt install php-sqlite3

Una vez instalado, sólo tendremos que cambiar las DNS de nuestros dispositivos a la IP de esta instancia.

Después de haber instalado Proxmox en un HP Gen8, mi intención era la de virtualizar LibreElenc para utilizarlo como centro multimedia y un Windows 10 para poder hacer uso de mi biblioteca de Steam. Tras un poco de modding en la pequeña torre e incorporar una GTX 1050Ti (concretamente la Gigabyte GV-N105TOC-4GL) me quedaba por delante configurar Proxmox para permitir dejar paso directo de la tarjeta gráfica a los sistemas virtualizados.

Configuración de la máquina virtual

Para ello la máquina virtual debía incorporar en su fichero de configuración («/etc/pve/qemu-server/100.conf») las siguientes opciones:

• machine: q35
• hostpci0: 07:00,pcie=1,x-vga=on

La segunda opción depende de cada equipo y es el resultado de haber obtenido lo siguiente tras lanzar el comando «lspci»:

07:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
07:00.1 Audio device: NVIDIA Corporation GP107GL High Definition Audio Controller (rev a1)

Error al arrancar la máquina virtual

Cuando intentemos arrancar la máquina virtual, lo más probable es que nos indique lo siguiente:

vfio: failed to set iommu for container: Operation not permitted

Lo que parece en principio un problema de permisos tiene un trasfondo más complejo que afecta al kernel y que podemos comprobar con el comando «dmesg | grep -e DMAR -e IOMMU» que nos devolverá lo siguiente:

vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.

Recompilación del kernel

La forma de solucionar el problema es recompilando el kernel tras haber incorporado un pequeño parche al mismo.

Actualizaremos el sistema e instalaremos los paquetes que vamos a necesitar:

• apt-get update
• apt-get install git nano screen patch fakeroot build-essential devscripts libncurses5 libncurses5-dev libssl-dev bc flex bison libelf-dev libaudit-dev libgtk2.0-dev libperl-dev libperl-dev asciidoc xmlto gnupg gnupg2 rsync lintian debhelper libibery-dev libdw-dev libnuma-dev libsplang2-dev libiberty-dev libslang2-dev debhelper sphinxdoc-common
• apt-get install lz4 (si utilizamos los fuentes de Ubuntu EOAN de la versión 5.4 del kernel de Proxmox)
• apt-get install pve-headers-5.4.24-1-pve (la versión dependerá del kernel que estemos tratando de compilar)

Descargaremos el código fuente del kernel que vamos a recompilar y de aquel de donde sacaremos el parche:

• cd /usr/src/
• git clone git://git.proxmox.com/git/pve-kernel.git
• git clone git://git.proxmox.com/git/mirror_ubuntu-disco-kernel.git
• mv mirror_ubuntu-disco-kernel ubuntu-disco

Hacemos una copia del parche que necesitamos y lo editamos con nano:

• cp ubuntu-disco/drivers/iommu/intel-iommu.c ubuntu-disco/drivers/iommu/intel-iommu_new.c
• nano ubuntu-disco/drivers/iommu/intel-iommu_new.c

En el editor de nano buscaremos con el comando «CTRL+W» el siguiente tecto:

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Contact your platform vendor.\n»);
return -EPERM;
}

Y lo cambiaremos a lo siguiente (se elimina el «return» y se añade al texto algo que nos haga saber más tarde que se está aplicando nuestro parche) :

if (device_is_rmrr_locked(dev)) {
dev_warn(dev, «Device was ineligible for IOMMU domain attach due to platform RMRR requirement. Parcheado.\n»);
}

De los dos ficheros generaremos un diff:

• diff -u /usr/src/ubuntu-disco/drivers/iommu/intel-iommu.c /usr/src/ubuntu-disco/drivers/iommu/intel-iommu_new.c > remove_rmrr_check.patch

Habrá que adaptar la cabecera de ese diff generado, quedando de forma similar a este (se cambian las rutas de los ficheros y sus nombres):

— a/drivers/iommu/intel-iommu.c 2019-07-17 15:44:26.908520624 +0200
+++ b/drivers/iommu/intel-iommu.c 2019-07-17 15:48:09.380083344 +0200

Moveremos el diff al lugar donde la recompilación lo buscará:

• cd /usr/src/pve-kernel/
• mv ../remove_rmrr_check.patch ./patches/kernel/

Modificaremos un script que busca ficheros con nombres problemáticos:

• nano debian/scripts/find-firmware.pl

Y comentaremos una de las primeras líneas para que quede más o menos de esta forma:

#die «strange directory name» if $dir !~ m|^(.*/)?(5.0.\d+\-\d+\-pve)(/+)?$|;

Configuraremos el Makefile:

• nano /usr/src/pve-kernel/Makefile

En él buscaremos «EXTRAVERSION» y lo dejaremos de la siguiente forma:

• EXTRAVERSION=-${KREL}-pve-removermrr

Y finalmente lanzaremos el make:

• make

Si todo ha ido bien, nos habrá generado una serie de ficheros «.deb» que instalaremos de la siguiente forma:

• dpkg -i *.deb

Si nos ha fallado por algún motivo y tenemos que relanzar de nuevo el «make» es posible que no nos deje y tengamos que añadir al fichero «Makefile» la opción «-d» quedando de esta forma:

${LINUX_TOOLS_DEB} ${HDR_DEB}: ${DST_DEB}
${DST_DEB}: ${BUILD_DIR}.prepared
cd ${BUILD_DIR}; dpkg-buildpackage –jobs=auto -b -uc -us -d
lintian ${DST_DEB}
#lintian ${HDR_DEB}
lintian ${LINUX_TOOLS_DEB}

Comprobación de la instalación

Una vez que tengamos el nuevo kernel instaldo mediante los «.deb» anteriores, reiniciaremos la máquina y cuando lancemos nuestra máquina virtual, mediante el comando «dmesg | grep -e DMAR -e IOMMU» obtendremos el mensaje:

vfio-pci 0000:07:00.1: Device is ineligible for IOMMU domain attach due to platform RMRR requirement. Parcheado.

Fuente

Las pautas han sido sacadas de lo que ahora es un pequeño tutorial pero en su día fue un verdadero quebradero de cabeza.

El Dell G7 7790 que he podido configurar incorpora la siguiente configuración hardware:

• 17″ IPS 144Hz Full HD.
• i7 8750H.
• 16 GB de RAM DDR4 ampliado a 32GB.
• Nvidia GTX 2070 Max-Q.
• SSD M.2 NVMe de 512MB cambiado por un SSD M.2 NVMe de 2TB de Intel 660P.
• Batería de 90Wh.

Cambio de RAID a AHCI

Para poder realizar la instalación de alguna distribución Gnu/Linux hay que cambiar, desde la BIOS, las opciones de dispositivos de almacenamiento para que la controladora se comporte como AHCI en vez de como RAID, de lo contrario nuestra distribución no será capaz de detectar los discos duros. Pero si realizamos el cambio sin más y queríamos conservar la partición con Windows 10, este no arrancará. Por lo que tendremos que seguir estos pasos antes:

1. Abrir un cmd como derechos de administrador.
2. Ejecutar el siguiente comando: «bcdedit /set {current} safeboot minimal» o de forma alternativa: «bcdedit /set safeboot minimal».
3. Reiniciar el portátil y entrar en la BIOS.
4. Cambiar el comportamiento de la controladora de dispositivos de almacenamiento de RAID a AHCI.
5. Windows arrancará en modo seguro reconociendo los cambios sobre el hardware.
6. Abrir un cmd como derechos de administrador.
7. Ejecutar el siguiente comando para deshacer lo anteriormente hecho: «bcdedit /deletevalue {current} safeboot» o de forma alternativa: «bcdedit /deletevalue safeboot «.
8. Reiniciar el equipo nuevamente y Windows 10 arrancará como normalmente lo hace.

Instalación de OpenSuse

Para lanzar la instalación de OpenSuse Leap es posible que tengamos que incorporar el parámetro «nomodeset» al kernel, de lo contrario la pantalla simplemente aparecerá en negro.

La instalación la podremos realizar sin ninguna pega. Cabe recordar que habrá que definir la partición EFI sobre la ya existente y no formatearla para que puedan convivir tanto Windows como OpenSuse.

Teclas Fn para el control del brillo

Una vez arranque OpenSuse, probablemente no funcionarán las teclas de brillo. Para solucionarlo sólo tendremos que editar el fichero «/usr/share/X11/xorg.conf.d/10-nvidia-brightness.conf» y añadir lo siguiente:

Section «Device»

Identifier «Device0»

Driver «nvidia»

VendorName «NVIDIA Corporation»

BoardName «GTX 2070»

Option «RegistryDwords» «EnableBrightnessControl=1»

EndSection

Podremos reiniciar y comprobar que ya funcionan las teclas de control de brillo. Cierto es que si nada más iniciar la sesión, hacemos uso de dichas teclas puede que no funcionen y nos toque cerrar sesión y volverla abrir, pero no es algo habitual.

Hibernación al cerrar la tapa

Para hacer funcionar la hibernación cuando cerramos la tapa, tendremos que colocar los siguientes parámetros para el kernel:

splash=silent nomodeset resume=/dev/disk/by-id/nvme-INTEL_SSDREKT8_BTN-part7 quiet nouveau.blacklist=1 acpi_rev_override=1 acpi_osi=Linux nouveau.modeset=0 pcie_aspm=force drm.vblankoffdelay=1 scsi_mod.use_blk_mq=1 nouveau.runpm=0 mem_sleep_default=deep

En OpenSuse lo podemos hacer desde Yast -> Boot Loader -> Parámetros del núcleo en la casilla que pone «Parámetro opcional de la línea de comandos del kernel». Hay que tener en cuenta que el dato «/dev/disk/by-id/nvme-INTEL_SSDREKT8_BTN-part7» es diferente en cada equipo y define la partición donde se aloja la swap.

Undervolt y gestión de rendimiento

Sabido es para este tipo de procesadores que un pequeño «undervolt» mejora con creces la temperatura del mismo y evita que se llegue al throttling. Para conseguirlo hago referencia a una entrada que publiqué no hace mucho.

Y para poder gestionar la actuación de los ventiladores y la frecuencia de la CPU publiqué otra entrada muy interesante para este tipo de portátiles.