Linux Sin Humo (Publicaciones sobre kernel)

Plan Táctico y Estratégico de la Memoria en Linux

sebelk — Mon, 01 Dec 2025 05:00:32 GMT

La mitología en torno a la memoria en Linux ha producido una serie de relatos:

En un extremo: Linux puede funcionar con muy poca memoria RAM.
Del otro lado: Linux consume mucha memoria.
Y que una partición SWAP debe tener entre 1 a 2 veces la memoria RAM.

Como vemos algunas historias son más recientes, otros más antiguas, pueden ser parcialmente ciertas y hasta contradictorias entre sí.

Este artículo tiene como propósitos:

Explicar de manera sencilla el funcionamiento de la memoria en Linux, desmitificando también algunos conceptos.
Enumerar y describir tácticas para que el uso de la memoria proporcione la mejor usabilidad y experiencia del usuario.
Ofrecer alternativas para que cada uno elija la mejor opción de acuerdo a sus necesidades.

Definiciones

Vamos a repasar algunos conceptos básicos que de manera más o menos frecuente usamos, usaremos metáforas en el camino. Ninguna metáfora es perfecta, sin embargo ellas nos ayudan a entender la realidad.

Memoria Virtual

La memoria virtual es el mecanismo por el cual cada proceso recibe un espacio de direcciones propio, independiente y protegido. El hardware traduce direcciones virtuales a físicas según tablas de páginas. Esto permite aislamiento, sobreasignación, mapeos de archivos y demanda dinámica de páginas, más allá de la cantidad de RAM disponible.

Linux trata de usar la mayor cantidad de memoria posible, para poder ejecutar las aplicaciones y acceder a los archivos de la manera más rápida posible. De manera que si la memoria libre es baja no es necesariamente un indicativo de un problema.

Page

Una página es la unidad mínima de memoria, de tamaño fijo (típicamente 4 KB), que el kernel y el hardware de gestión de memoria del procesador utilizan para organizar el espacio de direcciones y realizar el mapeo entre direcciones virtuales y físicas.

Page table

Es una estructura de datos jerárquica administrada por el kernel y usada por el hardware para traducir direcciones virtuales a direcciones físicas, con información de permisos y estado de cada página.

Page Fault

Un page fault ocurre cuando un proceso accede a una dirección válida de su espacio de memoria pero la página correspondiente no está preparada para ese acceso. Puede deberse a que la página aún no fue cargada, a que debe asignarse, o a que debe traerse desde disco. Si la página no está en RAM, el kernel debe cargarla, lo que puede ser lento; si ya estaba en RAM, el costo es menor.

Page cache

Es la caché de páginas de archivos gestionada por el kernel, usada para acelerar lecturas y escrituras almacenando en RAM los datos y metadatos de archivos y directorios, reduciendo accesos al disco.

Tipos de memoria

File Memory

Es la memoria relacionada con el Page Cache.

Anonymous Memory

Es la memoria que un proceso usa y que no está respaldada por un archivo: heap (asignada dinámicamente), stack (llamadas a funciones y almacenamiento de variables locales), COW (parte de la memoria cuando se crea un proceso hijo) y mapeos con MAP_ANONYMOUS. Su único respaldo posible es la swap. La memoria anónima se crea y utiliza en RAM. Si el kernel necesita expulsarla de RAM, su único destino posible es la swap, porque no tiene un archivo desde el cual reconstruirse. Pero su existencia normal no depende de la swap.

Memory Pressure

Memory pressure es estado en el que las páginas libres caen por debajo de umbrales críticos, obligando al kernel a iniciar mecanismos de liberación de memoria.

En términos prácticos cuando la presión es alta pueden surgir ciertos síntomas:

Sitios web / servidores HTTP: La latencia aumenta porque los workers deben esperar a que el kernel libere páginas. Además, puede haber más CPU gastada en recuperar memoria, lo que degrada aún más los tiempos de respuesta.
Sistemas de escritorio: El sistema pierde fluidez porque el scheduler empieza a verse afectado por stalls debidos a las operaciones para liberar memoria y, si hay swap, el sistema puede entrar en swap thrashing. Esto produce lag del mouse, ventanas que tardan en responder, escritorios congelados por segundos, etc.
Acceso remoto (SSH, RDP, VNC): Al haber presión, las operaciones de usuario-espacio tardan más en ejecutarse, y los daemons pueden quedar brevemente estancados esperando memoria. Esto causa retrasos notables en la interacción remota.

¿Y qué sucede si la presión de memoria puede llegar a ser tan alta que el kernel ya no logra conseguir memoria ni siquiera después de intentar liberarla?

Thrashing

El thrashing ocurre cuando la memoria RAM no alcanza para mantener las páginas que los procesos usan todo el tiempo. El kernel empieza a sacar páginas de memoria para hacer lugar a otras nuevas, pero enseguida vuelve a necesitarlas. Esto genera un bucle de fallos de página y de recarga constante desde el disco.

Con swap: las páginas anónimas van y vienen entre RAM y swap, lo que dispara el uso de disco y vuelve el sistema extremadamente lento.
Sin swap: las páginas anónimas no tienen adónde ir y el kernel termina activando el OOM killer.
Incluso sin swap: puede haber thrashing si las páginas vienen de archivos (page cache), ya que el kernel debe recargarlas una y otra vez.

OOM (Out-Of-Memory) 💀 🔥

Out-Of-Memory es una situación en la cual el kernel agotó todos los mecanismos para liberar memoria:

Liberar páginas del caché.
Sacar páginas anónimas de swap.
Compactar memoria.
Liberar memoria mediante kswapd.
Aplicación de políticas de cgroups (muy común al usar contenedores).

OOMKiller

El OOM-killer es el mecanismo que usa el kernel cuando ya no puede asignar más memoria, incluso después de intentar liberar todas las páginas que es posible descartar o mover fuera de la RAM. En esa situación crítica, el kernel calcula un puntaje para cada proceso (oom_score) y finaliza al que resulte más conveniente para recuperar memoria rápidamente y permitir que el sistema siga funcionando. Este comportamiento puede influenciarse ajustando oom_score_adj, que hace que un proceso sea más o menos propenso a ser elegido.

oom_score

Como ya se mencionó a cada proceso se le asigna un puntaje de acuerdo a distintos factores, cuanto más alto es, más susceptible es a ser terminado por OOMKiller.

Y también, como dijimos mediante oom_score_adj podemos influir en el score de un proceso:

En versiones más recientes de las distribuciones existe el comando choom que permite ver y/o ajustar dicho valor.

Swap

Los usuarios ocasionales de Linux y aun muchos sysadmins tienen una idea negativa sobre "la swap". Simplificaciones extremas y conceptos anticuados la han convertido en le gran villana de la historia del sistema operativo.

Si comparamos a la memoria con un escritorio, sin swap podría lucir así:

Photo by Ashim D’Silva on Unsplash

Así que primero vamos a decir lo que no es:

No es la memoria virtual sino que forma parte de la técnica que realiza el sistema operativo para administrar la memoria.
No es un espacio de reserva ni un último recurso. Es un espacio complementario sirve para liberar RAM.
No funciona como último recurso, pero el sistema operativo puede mover hacia la swap las páginas de memoria no usadas recientemente.
No es algo que el sistema operativo pueda alegremente prescindir aun cuando la cantidad de memoria RAM física sea grande. Quienes parecen haber inventado la pólvora, nos cuentan que es posible técnicamente que Linux funcione sin swap. Si bien es cierto, al carecer de swap, el kernel no tiene manera de mover páginas de memoria anónimas hacia el área de swap y liberar así RAM para procesos que la necesitan urgentemente.

Nuestro escritorio con swap:

Photo by Alexandru Acea (edited by me) on Unsplash

¿Los cajones de un escritorio los usamos cuando lo tenemos abarrotado de cosas? No, los usamos para guardar cosas que no son de alta prioridad. Aunque es cierto, si luego queremos usar esa tijera o aquel destornillador en algún momento requerirá un poco más de trabajo, tendremos que abrir el cajón, buscarlo, extraerlo, etc.

Ah, y la swap también sirve para hibernar, aunque honestamente no se cuanta gente mantiene esa práctica.

Tuning

Ahora veremos diferentes tácticas que podemos usar para optimizar el uso de la memoria.

cgroupv2

cgroup es un mecanismo para organizar los procesos de manera jerárquica y distribuir los recursos del sistema a lo largo de la jerarquía en una manera controlada y configurada.

Un cgroup se compone de un núcleo que es responsable primariamente en organizar de manera jerárquica los procesos y controladores que comúnmente distribuyen un tipo específico de recurso del sistema a lo largo de la jerarquía.

En la versión 2 de cgroup un proceso no puede pertenecer a diferentes grupos para diferentes controladores. Si el proceso se uno al grupo alfa, todos los controladores para alfa tomarán control de ese proceso.

Supongamos que los procesos de un cgroup (y todos los grupos hijos) usan poca memoria, podríamos decirle al kernel que libere memoria de otros cgroups. Esto es precisamente lo que hace el parámetro memory.low.

Otro parámetro interesante para monitorear es memory.pressure, la primera línea tiene el tiempo físico de una o más tareas demoradas debido a la falta de memoria. La segunda sería lo mismo pero para todas las tareas del grupo, full es lo mismo pero para todas las tareas del grupo, Entonces si miramos el archivo /sys/fs/cgroup/user.slice/memory.pressure:

some avg10=0.00 avg60=0.13 avg300=0.12 total=1690238
full avg10=0.00 avg60=0.10 avg300=0.09 total=1394199

Significa que, dentro del grupo de control user.slice, en los últimos 10 segundos no hubo tareas afectadas por presión de memoria. Sin embargo, en el último minuto las tareas estuvieron bloqueadas un 0,13% del tiempo y un 0,12% en los últimos cinco minutos. El valor total indica que estas situaciones acumulan aproximadamente 1,7 segundos de espera. La segunda línea muestra las mismas métricas, pero aplicadas a los casos en que todas las tareas del grupo estuvieron simultáneamente afectadas por presión de memoria (full en lugar de some).

Es decir:

some → indica si un retraso afectó al menos una tarea.
full → indica si el retraso afectó a todo el cgroup simultáneamente.

zram

zram es por así decirlo, una manera cool de usar swap gracias a un módulo del kernel.

Photo by chuttersnap on Unsplash

En lugar de gastar espacio en un disco (sea rígido o sólido) usamos dispositivos de bloque en la propia RAM. Los bloques swapeados se guardan comprimidos. Esto discos virtuales son rápidos y ahorran memoria.

Una de las pocas desventajas que tiene esta metodología es la incapacidad para poder hibernar el sistema operativo, al no estar presente la partición en un almacenamiento de tipo persistente.

Sistemas de archivos

El journal de ext4 puede ser lento, xfs puede ser una mejor alternativa o mejor aun btrfs.

EarlyOOM

El oom-killer del kernel solamente se dispara en situaciones extremas y le puede llevar mucho tiempo hasta que puede enviar SIGKILL a los procesos que sean necesarios para poder liberar memoria. Durante ese tiempo probablemente el usuario no pueda interactuar con el sistema operativo.

EarlyOOM trabaja en espacio de usuario y por lo tanto se puede anticipar y ser mucho más rápido.

El comportamiento predeterminado en Fedora es que si hay menos del 10% de RAM y/o SWAP libre, earlyoom envía una señal de terminación a todos los procesos con oom_score más alto. Si la RAM como SWAP libre bajan por debajo del 5%, earlyroom enviará una señal para matar todos los procesos con oom_score más elevado.

La idea es recuperar la usabilidad (especialmente en un entorno de escritorio) lo antes posible.

El problema es que EarlyOOM no soporta al momento la medición de la memory pressure como indicativo para tomar decisiones.

nohang

Este servicio es mucho más configurable y aporta una mejor solución que EarlyOOM.

Algunas funcionalidades son:

Se puede elegir la acción que realizará en una situación OOM.
Ofrece varios criterios para elegir los procesos a finalizar.
Soporta zram
Puede usar memory pressure para tomar una acción.
El archivo de configuración es medianamente sencillo

Sin embargo, este proyecto en la actualidad tiene poca actividad comparado por ejemplo con EarlyOOM

zswap

Con zswap no reemplazamos el espacio swap en el disco sino que usamos un caché comprimido en la RAM. Este método ahorra I/O, obteniendo entonces mejor rendimiento y alargando la vida útil de discos flash o sólidos. La única desventaja es usar algo de tiempo del procesador para realizar la compresión.

Photo by Pineapple Supply Co. on Unsplash

Mediante el caché se logra una diferenciación entre páginas más usadas (zswap) y menos usadas (swap).

systemd-oomd

El servicio systemd-oomd es un proyecto en el que comenzó en Facebook para integrarlo con systemd. En un principio estaba pensado para manejo de memoria a gran escala, y bastante más complejo de configurar. Sin embargo ha sido adoptado desde Fedora 34 reemplazando a EarlyOOM. En las distribuciones que usan versiones recientes de systemd, está disponible, aunque no todas lo habilitan de manera predeterminada.

Resumen

Swap no es la villana de la película
Si existe la opción de migrar a otros sistema de archivos aunque con características un tanto experimental, elegir btrfs. Una opción más moderada es xfs.
El tuning de cgroupv2 puede traer grandes beneficios, no obstante existen proyectos y distribuciones que no lo usan.
EarlyOOM es una solución rápida y aplicable a una amplia gama de sistemas Linux, aunque no siempre es la más exacta ni más elegante.
El servicio nohang (o no hang-desktop) es una opción más madura aunque algo más compleja que EarlyOOM, pero que sin embargo ha caído en cierta inactividad.
El servicio systemd-oomd inicialmente incorporado por Facebook es seguramente la opción más adecuada para escenarios más complejos y de manejo de memoria a gran escala. También es utilizado actualmente en sistemas de escritorio.
Sin embargo, muchas distribuciones o sabores de distribuciones prefieren usar el mecanismo clásico de OOMKiller.
A veces se sugiere el ajuste de parámetros del kernel mediante sysctl.
Si se desea ahorrar espacio en disco se puede reemplazar la swap por zram, sacrificando la opción de hibernar el sistema.
La opción zswap es más sofisticada, aunque dependemos del uso de swap en disco.

Photo by sk on Unsplash

Fuentes consultadas

Qué son los cgroups y para qué sirven

sebelk — Fri, 25 Oct 2024 22:46:07 GMT

En el post anterior vimos los namespaces, que sirven para aislar diferentes aspectos del sistema, como los procesos, la red y los puntos de montaje, creando entornos independientes para cada grupo de procesos. En este post, exploraremos los cgroups, que permiten controlar cuánto de los recursos del sistema, como CPU, memoria y disco, puede usar cada grupo de procesos. Ambas tecnologías se complementan: los namespaces proporcionan el aislamiento necesario, mientras que los cgroups gestionan y limitan los recursos que esos entornos aislados pueden consumir.

¿Qué son los cgroups?

Los cgroups (control groups) son una funcionalidad del kernel Linux que permite agrupar procesos y controlar de manera granular los recursos del sistema que consumen, como CPU, memoria, I/O, y otros. Se incorporaron en 2008 en el kernel de Linux 2.6.24, los cgroups permiten a los administradores de sistemas gestionar el uso de recursos por grupos de procesos de forma eficiente, garantizando una distribución justa y controlada.

Los cgroups crean una jerarquía de control donde es posible asignar límites a recursos específicos para un conjunto de procesos, de manera que el sistema operativo pueda monitorear, limitar, priorizar o aislar estos procesos según sea necesario. Esta capacidad es clave para garantizar que los sistemas multitarea, servidores, y contenedores funcionen de manera eficiente.

¿Para qué sirven los cgroups?

Los cgroups sirven para:

Limitar el uso de recursos
Priorizar procesos
Aislar procesos
Monitorear el consumo de recursos
Controlar procesos en contenedores (Docker, podman,etc.)

Un pantallazo de los cgroups

Dentro del propio directorio /proc podemos encontrar información sobre los cgroups:

❯ cat /proc/cgroups 
#subsys_name    hierarchy       num_cgroups     enabled
cpuset  0       241     1
cpu     0       241     1
cpuacct 0       241     1
blkio   0       241     1
memory  0       241     1
devices 0       241     1
freezer 0       241     1
net_cls 0       241     1
perf_event      0       241     1
net_prio        0       241     1
hugetlb 0       241     1
pids    0       241     1
rdma    0       241     1
misc    0       241     1

Este archivo muestra 4 columnas

Campo	Significado
subsys_name	Componente del kernel que controlar un recurso específico un aspecto del sistema.
hierarchy	La columna `hierarchy` indica el ID de jerarquía asignado a cada subsistema. En este caso, todas las jerarquías tienen el valor 0, lo que indica que todos los subsistemas listados están utilizando una jerarquía unificada, común en sistemas que usan cgroups v2. En cgroups v2, todos los controladores utilizan una única jerarquía para gestionar los recursos de manera más eficiente, a diferencia de cgroups v1, donde cada subsistema podía tener su propia jerarquía.
num_cgroups	Muestra el número de cgroups activos o instancias creadas bajo cada controlador. Estos cgroups pueden pertenecer a procesos que están ejecutándose actualmente en el sistema, como servicios, contenedores, o procesos individuales.
enabled	Esta columna muestra si el subsistema está habilitado o no. El valor 1 indica que el controlador está habilitado y activo, mientras que un valor de 0 indicaría que está deshabilitado.

Evolución de los cgroups:

cgroups v1: En la versión original, cada tipo de recurso (CPU, memoria, etc.) tenía su propia jerarquía de control, lo que permitía una gestión separada pero a veces compleja. Aunque era útil, la administración independiente de subsistemas podía resultar difícil de manejar en entornos complejos.
cgroups v2 (2016): Para mejorar la gestión de recursos, se introdujo cgroups v2 en el kernel de Linux 4.x, que unificó los diferentes controladores bajo una jerarquía única. Esta versión simplificó el control de recursos y mejoró la eficiencia, permitiendo que todos los subsistemas trabajaran de manera más coordinada y con configuraciones más claras.

Cómo crear un cgroup y limitar el uso de CPU en cgroups v2

En este ejemplo, limitaremos el uso de CPU de un proceso utilizando cgroups v2 en un entorno moderno.

Paso 1: Crear un directorio para el cgroup

En cgroups v2, se gestiona todo bajo una jerarquía unificada. Primero, crea un nuevo directorio en /sys/fs/cgroup:

sudo mkdir /sys/fs/cgroup/mi_cgroup

Paso 2: Establecer un límite de CPU

En cgroups v2, puedes establecer límites en el uso de CPU mediante el archivo cpu.max. Este archivo recibe dos valores: el primero es el límite de uso de CPU en microsegundos por cada período de 100 milisegundos, y el segundo es la duración del período en microsegundos.

Para limitar el uso de CPU al 50%, puedes hacer lo siguiente:

echo "50000 100000" | sudo tee /sys/fs/cgroup/mi_cgroup/cpu.max

Este comando establece que los procesos en este cgroup pueden usar un máximo de 50.000 microsegundos de CPU en un período de 100.000 microsegundos (100 ms), lo que equivale al 50% de un núcleo de CPU.

Paso 3: Añadir un proceso al cgroup

Para añadir un proceso existente al cgroup, escribe su PID (ID del proceso) en el archivo cgroup.procs de ese cgroup. Supongamos que el PID del proceso es 78435:

echo 78435| sudo tee /sys/fs/cgroup/mi_cgroup/cgroup.procs

Esto moverá el proceso con PID 78435 al cgroup mi_cgroup, aplicando las restricciones de CPU configuradas.

En cgroups v1, los recursos se gestionan usando archivos como cpu.shares para establecer prioridades relativas de CPU, y tasks para asignar procesos a un cgroup. En cambio, en cgroups v2, el control de CPU se realiza a través de cpu.max, donde se puede establecer un límite absoluto en el uso de CPU (como un porcentaje). Además, en v1 cada subsistema tiene su propio directorio (como cpu/, memory/), mientras que en v2 todo se gestiona dentro de una única jerarquía unificada bajo /sys/fs/cgroup/.

Conclusión

Hoy en día, los cgroups son una herramienta crítica en la gestión moderna de servidores. RHEL8 usa de manera predeterminada la versión 1, pero es posible usar la versión 2, dependiendo del software que utilicemos. En definitiva, los cgroups son fundamentales para la operación de tecnologías como contenedores (Docker, Podman), orquestadores como Kubernetes, y cualquier sistema que necesite control granular de recursos. La capacidad de aislar, priorizar y monitorear el uso de recursos en servidores es clave para garantizar la estabilidad y el rendimiento en entornos de alta demanda.

Fuentes y más información

Como Compilar un kernel Linux en 10 pasos

sebelk — Fri, 16 Oct 2020 17:55:01 GMT

Autor: Sergio Belkin. Este obra está bajo una licencia de Creative Commons Reconocimiento-CompartirIgual 4.0 Internacional.

Advertencia

El kernel que viene con las distribuciones es suficiente para la mayoría de los casos. Usar un kernel compilado a mano puede dejar el sistema inusable sino se realiza correctamente. No debería usarse en sistemas en producción salvo que se sepa exactamente qué, por qué y para qué se hace. Hay distribuciones que limitan o no proveen el soporte en sistemas Linux con kernels compilados a mano. Siempre es recomendable hacer un backup tanto del directorio /boot como del directorio /lib/modules.

Motivación

Si no has leído la Advertencia por favor no sigas. Leela detenidamente y seguimos. ¿Ya está? ¡OK! ¿Por qué compilar un kernel hoy en 2020? Un razón es que al compilar se puede aprender que funcionalidades proporciona el kernel, deshabilitar funciones que sabemos no vamos a usar, probar nuevas características ausentes en la versión del kernel de la distribución y también para entender más cómo trabaja el sistema operativo. Este how-to ha sido probado tanto en Debian 10 como en CentOS 8. En una máquina con 2GB y un único procesador llevaría menos de una hora hacerlo (obviamente cuantos más sean los módulos o componentes agregados más va a tardar). Recordar que se puede compilar como un ususuario común y luego pedir privilegios de root para instalar. Basta de palabras y manos a la obra.

1. Instalar los pre-requisitos

yum groupinstall "Development Tools" && yum install ncurses-devel zlib-devel binutils-devel elfutils-libelf-devel libkcapi-hmaccalc openssl-devel

En Debian, deberíamos instalar:

apt -y install build-essential libncurses-dev

2. Bajar las fuentes del kernel

Recomendable bajar o la rama Longterm o bien la Stable, por ejemplo:

curl -L -O https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.8.15.tar.xz

3. Desempaquetar las fuentes

tar avxf linux-5.8.15.tar.xz

4. Entrar en el directorio de las fuentes

cd linux-5.8.15

5. Tomar como referencia el kernel que estamos usando

cp /boot/config-$(uname -r) .config

6. Tomar como base los módulos del kernel que están en uso actualmente 😉 😉

make localmodconfig

(Le damos Enter hasta que termine)

7. Configuramos nuestro kernel a medida

make menuconfig

Esta parte es la más importante. Podemos dejar todo como está pero probablemente haya algo que no estamos usando que no se va a compilar y necesitaremos después. Entonces es importante recorrer algunas secciones para revisar si falta algo, en especial lo que tiene que ver con Netfilter, File Systems, etc . Por ejemplo: tomar los recaudos suficientes si el sistema está virtualizado o si usa containers.

Una vez hecho los ajustes necesarios, guardamos y salimos.

8. Compilamos el kernel

make

9. Instalamos los módulos del kernel con privilegios de root

sudo make modules_install

10. Instalamos el kernel con privilegios de root

sudo make install

¡Listo! Podemos reiniciar y comenzar a usar el kernel compilado por nosotros mismos.

Instalar Linux desde un archivo ISO

sebelk — Sat, 05 Dec 2015 15:02:38 GMT

En el artículo anterior habíamos visto el potencial de la shell de GRUB 2. Allí habíamos visto que podíamos arrancar directamente desde una imagen ISO sin necesidad de tener que grabarlo en un disco óptico ni copiarlo a una unidad USB.

Ahora bien, ¿podríamos además instalar un sistema operativo utilizando ese método? La respuesta es sí. En este caso puntual veremos como instalar Fedora 23.

Aquí, tendremos que tener en cuenta los dos software involucrados principalmente para poder realizar esta tarea. Estos programas son GRUB 2 (naturalmente) y dracut.

Recordemos que en el momento del arranque se utiliza un sistema de archivos temporal en memoria hasta que se pueda realizar el montaje del definitivo sistema de archivos raiz.

dracut es tanto una infraestructura de initramfs manejada por eventos como así también una herramienta que se usa para crear una imagen de disco en memoria. El comando dracut copiar herramientas y archivos de un sistema instalado y lo combina con el framework dracut.

Estos archivos se pueden ver en fedora en el directorio /usr/lib/dracut/modules.d:


[sergio@hope ~]$ ls /usr/lib/dracut/modules.d
00bash               30convertfs  90dm                      90qemu-net    95fstab-sys     95zfcp            99base
00systemd            40network    90dmraid                  91crypt-gpg   95iscsi         95zfcp_rules      99fs-lib
00systemd-bootchart  45ifcfg      90dmsquash-live           91crypt-loop  95nbd           95znet            99img-lib
01systemd-initrd     45url-lib    90kernel-modules          95cifs        95nfs           97biosdevname     99kdumpbase
02systemd-networkd   50drm        90kernel-network-modules  95dasd        95resume        98dracut-systemd  99shutdown
03modsign            50plymouth   90livenet                 95dasd_mod    95rootfs-block  98ecryptfs        99uefi-lib
03rescue             80cms        90lvm                     95dasd_rules  95ssh-client    98pollcdrom
04watchdog           90bcache     90mdraid                  95debug       95terminfo      98selinux
05busybox            90btrfs      90multipath               95fcoe        95udev-rules    98syslog
10i18n               90crypt      90qemu                    95fcoe-uefi   95virtfs        98usrmount

Por lo tanto aquí la clave es pasar los parámetros del kernel y opciones para dracut correctas. Y para agregar la entrada al menú de grub utilizamos el archivo /etc/grub.d/40_custom.

 exec tail -n +3 $0
 # This file provides an easy way to add custom menu entries. Simply type the
 # menu entries you want to add after this comment. Be careful not to change
 # the ‘exec tail’ line above.

menuentry “Live Fedora 23″ –class fedora {
 set isofile=”/Fedora-Live-KDE-x86_64-23-10.iso”
 loopback loop (hd0,gpt8)$isofile
 linuxefi (loop)/isolinux/vmlinuz0 iso-scan/filename=${isofile} root=live:CDLABEL=Fedora-Live-KDE-x86_64-23-10 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
 initrdefi (loop)/isolinux/initrd0.img
 }

Aquí los comandos y opciones claves son respectivamente loopback e iso-scan.

El comando loopback sirve para especificar la ruta a un archivo ISO para que sea tomado como un dispositivo de bloques. Mientras tanto el parámetro iso-scan sirve para montar el dispositivo de loopback y pasarle los parámetros de kernel y dracut apropiadas.

¿Cómo sabemos las opciones y parámetros correctos? Las podemos averiguar montando el archivo ISO e inspeccionando el archivo isolinux.cfg:


[root@hope sergio]# mount -o loop /usr/Fedora-Live-KDE-x86_64-23-10.iso /media
mount: /dev/loop0 está protegido contra escritura; se monta como sólo lectura
[root@hope sergio]# grep -m1 append  /media/isolinux/isolinux.cfg 
  append initrd=initrd0.img root=live:CDLABEL=Fedora-Live-KDE-x86_64-23-10 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0

Sencillamente debemos copiar lo que está a continuación de append initrd=initrd0.img.

Además, se pueden apreciar los comandos linuxefi e initrdefi que son equivalente de manera respectiva a las ordenes linux e initrd al utilizar un sistema con UEFI.

Finalmente, debemos ejecutar el comando para generar el nuevo archivo de GRUB 2:

[root@hope sergio]# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Reiniciamos, elegimos la opción Live Fedora 23 y luego podremos instalar el sistema operativo.

La partición importa

La partición en la que está ubicado el archivo ISO importa. Existe un bug en el módulo de python para la configuración de almacenamiento del sistema llamado blivet que impide la instalación del sistema operativo si la ISO está en alguna partición marcada en el editor de particiones, más allá de que esta se formatee o no. Como solución provisoria, se puede emplear una partición sin que el instalador la tenga en cuenta. De hecho, hice eso mismo. Luego, posterior a la instalación usé dicha partición para el directorio /usr, usando rysnc, editando el archivo /etc/fstab y borrando el /usr original.

Conclusión

Una vez más, podemos apreciar el potencial de GRUB 2 y como podemos prescindir de otros medios para instalar sistemas operativos. De hecho, dado el gran tamaño de los discos en la actualidad, podríamos tener una partición específicamente para tener ISOS.

¿Proceso ininterrumpible?

sebelk — Sat, 24 Aug 2013 22:16:35 GMT

Todo aquel que tenga un conocimiento decente de Linux sabrá que un proceso cuando está en estado “D” significa que está “durmiendo ininterrumpidamente”.

Bueno, les comento que no es tan así, sino me creen miren:

[root@mpinode02 Distros]# time find / -mmin +10 > /dev/null & [1] 15592

[root@mpinode02 Distros]# ps -C find -ostat,comm,wchan STAT COMMAND WCHAN D find sleep_on_buffer

[root@mpinode02 Distros]# kill 15592

[root@mpinode02 Distros]# ps -C find -ostat,comm,wchan STAT COMMAND WCHAN D find sleep_on_buffer [1]+ Terminado time find / -mmin +10 > /dev/null

Como ven un proceso en estado “D” sí se puede matar. Evidentemente hay algo más detrás, seguramente volveremos a tocar este tema.

No abre el DVD

sebelk — Sat, 22 Jun 2013 23:09:28 GMT

Si al insertar un DVD el reproductor multimedia no lo abre, se puede deber a un problema mucho más sencillo de lo que parece. Probablemente no se deba que el disco no se pueda reproducir, sino que la aplicación está buscando el archivo /dev/dvd y no lo encuentra.

Lo que tenemos que hacer es crear un archivo en el directorio /etc/udev/rules.d con el siguiente contenido:

KERNEL==”sr0″, SYMLINK+=”dvd”
Luego hay que recargar las reglas del servicio udev:

udevadm control –reload

Y listo.

Estaciones Virtuales Inalámbricas

sebelk — Mon, 30 Apr 2012 14:40:40 GMT

Estaciones Virtuales inalámbricas por Sergio Belkin se encuentra bajo una Licencia Creative Commons Atribución-CompartirDerivadasIgual 2.5 Argentina.

A veces es necesario simular una gran cantidad de estaciones (es decir clientes o “supplicants”) ante un Access Point para obtener una estimación de las capacidades del equipo y/o firmware. Seguramente existe algún que otro software con licencia restrictiva que nos permita hacer eso. Pero ¿se podrá hacer eso con una sola notebook con Linux? La respuesta es sí.

Veremos como:

Deshabilitamos cifrado por hardware

echo options ath9k nohwcrypt=1 > /etc/modprobe.d/ath9k.conf

udev

`Editamos /lib/udev/rules.d/75-persistent-net-generator.rules`

Queremos que udev no maneje la interfaz wireless wlan0, entonces sacamos de la siguiente regla a wlan0

KERNEL!=”eth*|ath*|ra*|ctc*|lcs*|hsi*”, GOTO=”persistent_net_generator_end”

Editar el archivo /etc/udev/rules.d/70-persistent-net.rules

Tampoco necesitamos la siguiente la regla, así que la borramos:

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”68:a3:c4:33:44:55″, ATTR{dev_id}==”0x0″, ATTR{type}==”1″, KERNEL==”wlan*”, NAME=”wlan0″

Recargar la configuración

systemctl restart udev-trigger.service

Detener servicios que interfieren con la creación de intefaces virtuales

systemctl stop NetworkManager.service

systemctl stop avahi-daemon.service

Terminar procesos de wpa_supplicant

killall wpa_supplicant

Agregamos una interfaz virtual inalámbrica

iw phy phy0 interface add sta0 type station

Le cambiamos la mac address, sino NO va a funcionar

macchanger -r sta0

Activamos la interfaz

ip link set dev sta0 up

Lanzamos el cliente wireless

wpa_supplicant -t -ista0 -c /etc/wpa_supplicant/peap.conf -B -f /var/log/wpa-sta0.log

Arrancamos el cliente dhcp

dhclient -v -cf /etc/wpa_supplicant/dhclient.conf sta0

¡Listo!

Se puede hacer un script (de hecho es lo que hice) para automatizar estos pasos y agregar tantas interfaces virtuales como sea posible.

Reconocimiento: El artículo de Candela Technologies en http://www.candelatech.com/vsta.php fue de suma utilidad.

Advertencia: Esta receta funciona en particular para el módulo ath9k, es probable que sea necesario modificar algo con otros drivers o que directamente no funcione. Asimismo, se utilizó Fedora 16 desde el lado cliente, obviamente deberían realizarse las adapataciones pertinentes de acuerdo a la distribución.

Secretos de ps

sebelk — Sat, 07 May 2011 23:43:39 GMT

Bueno, no es para tanto, pero es un dato útil: a veces es difícil acordarse de memoria todas las columnas de ps, bien, para eso está la opción “–headers”, por ejemplo:

ps aux –headers