zram: Decompression failed!

Con un ordenador y un sistema operativo nuevo toca encontrar y pulir detalles todo el tiempo. En esta ocasión lo que estaba viendo es que, cuando la máquina estaba muy cargada de CPU, se me morían procesos de vez en cuando. Tras experimentarlo varias veces en días diferentes, tras haber reiniciado el ordenador entre medias y notar esa aparente correlación entre la carga de CPU y los fallos de los programas, planteé dos hipótesis rápidas:

  • Que la máquina nueva está defectuosa y da problemas cuando se calienta mucho (carga de CPU elevada). Estamos en noviembre en Madrid, pero es cierto que yo torturo mis ordenadores cosa mala. Esta hipótesis se podría validar con una carga de CPU media y un secador de pelo, o advirtiendo si las incidencias suben o baja en función de la temperatura ambiental.
  • Memoria defectuosa, tal vez vinculada también a la temperatura. Para comprobar esta hipótesis lo más evidente sería utilizar una herramienta como memtest86, pero me llevé la gran sorpresa de que memtest86 no funciona en ordenadores con arranque UEFI, que es el caso de mi nuevo portátil.

Estaba dando vueltas al problema cuando se me ocurrió examinar los logs del sistema operativo y me encontré los siguientes mensajes de error:

[42028.302788] zram: Decompression failed! err=-22, page=1014500
[42054.078557] zram: Decompression failed! err=-22, page=723903
[42059.341537] zram: Decompression failed! err=-22, page=882298
[42059.341559] zram: Decompression failed! err=-22, page=882298
[42059.341564] Read-error on swap-device (252:2:7058384)
[42060.219105] zram: Decompression failed! err=-22, page=882298
[42060.219124] zram: Decompression failed! err=-22, page=882298
[42060.219128] Read-error on swap-device (252:2:7058384)
[42227.794573] zram: Decompression failed! err=-22, page=683032
[42624.876873] zram: Decompression failed! err=-22, page=922205
[42624.876898] zram: Decompression failed! err=-22, page=922205
[42624.876902] Read-error on swap-device (252:2:7377640)
[42626.831143] zram: Decompression failed! err=-22, page=662025
[42626.831160] zram: Decompression failed! err=-22, page=662025
[42626.831164] Read-error on swap-device (252:3:5296200)
[42630.433498] zram: Decompression failed! err=-22, page=905764
[42630.433517] zram: Decompression failed! err=-22, page=905764
[42630.433521] Read-error on swap-device (252:2:7246112)
[42989.405417] zram: Decompression failed! err=-22, page=877548
[42999.463318] zram: Decompression failed! err=-22, page=629447

Vaya, ¡parece que tenemos un ganador!

Leer más…

Live patching "libpam.so" in SmartOS platform

A few days ago a serious security bug was discovered in Solaris and Solaris derivatives like Illumos. Details:

Briefly, an unauthenticated network attacker can trivially take over your system.

I use SmartOS heavily, an Illumos distribution. SmartOS is a Hypervisor and upgrading it is usually quite trivial, but at this moment I can not afford any kind of downtime. Bad timing.

What to do?

Leer más…

Instalación manual de Kubuntu 20.04 con LUKS y ZFS

Recientemente he estado experimentando con las versiones 20.04 de Ubuntu y Kubuntu y con la versión actual de Tumbleweed, la distribución rolling release de OpenSUSE. Algunos resultados:

  • Kubuntu y OpenSUSE utilizan KDE, mi entorno preferido de escritorio. Ubuntu emplea Gnome, entorno que suelo probar de vez en cuando y cada vez me parece peor (para mi gusto y mis necesidades).

  • Ubuntu y Kubuntu soportan ambos ZFS de forma nativa. Desde que utilicé ZFS en Solaris en 2005, no quiero usar nada más. Los otros sistemas de ficheros son de juguete.

    Además, mi máquina actual emplea ZFS sobre Linux y lo exprimo de forma exhaustiva: snapshots diarios, replicación, copias de seguridad rápidas, clones... No, no quiero usar otra cosa.

  • Kubuntu tiene un soporte de tres años para los paquetes de software propios, mientras que Ubuntu, su base, ofrece cinco años de soporte.

    Esto ya lo he sufrido en mi Sistema Operativo actual, Kubuntu 16.04. Afortunadamente, la base Ubuntu de Kubuntu sí tiene cinco años de soporte.

  • El instalador de Ubuntu incluye un instalador ZFS experimental. El instalador de Kubuntu no.

  • Si haces una instalación ZFS de Ubuntu, no tienes la opción de cifrado. El cifrado solo está disponible para Sistemas de ficheros más tradicionales. Y esto a pesar de que las versiones recientes de ZFS tienen cifrado nativo y que también se podría usar LUKS (que es mi solución hasta el momento).

Descarté OpenSUSE rápidamente porque no tiene un soporte evidente de ZFS, aunque en casa hay otro ordenador con Tumbleweed y estamos contentos con la experiencia. Además, no quiero que todos los ordenadores de casa utilicen la misma rolling release, porque una actualización problemática puede ser una catástrofe.

Mi decisión ha sido la siguiente:

Leer más…

Salvapantallas y envío de eventos al sistema "X Window"

Por razones que no vienen al caso necesitaba dejar mi portátil funcionando, pero que no saltase el salvapantallas. Yo utilizo KDE y este permite realizar acciones diferentes cuando llevas el ratón a las esquinas del monitor. En mi Kubuntu 20.04, cada esquina puede hacer una de quince acciones diferentes, incluyendo "no hacer nada" y "activar el salvapantallas". Pero no hay ninguna acción que sea "inhibir la activación del salvapantallas".

Obviamente, si no quería que saltase el salvapantallas ese día, una opción evidente era desactivarlo por completo, pero me incomodaba que no hubiese una accción simple de inhibición temporal.

Tirando de Internet veo que aparentemente existen varios comandos para interactuar con el entorno gráfico y concretamente con el salvapantallas. Algunas de ellas eran loginctl o xdg-screensaver, pero ninguna funcionaba correctamente en mi sistema. Por ejemplo, xdg-screensaver reset no impedía que saltase el salvapantallas, pero sí impedía que se apagase el monitor.

Incluso intenté ver cómo programas como mplayer interactúan con el entorno gráfico para evitar que la pantalla se bloquee mientras estás viendo una película. Asomarse a ese abismo me dio repelús. "No quieres ir por ahí", me dije.

Nada de esto me servía.

Leer más…

Usar la memoria RAM para montar sistemas de archivos

A veces es muy conveniente montar un sistema de archivos en RAM. Algunos motivos comunes:

  • Estamos usando un entorno live cd o similar y necesitamos una zona de lectura y escritura.
  • Queremos que los cambios en un sistema de archivos sean temporales, que se puedan deshacer con facilidad. Un ejemplo de esto sería unionFS o mergeFS.
  • Queremos una zona de trabajo no persistente de alta velocidad. Por ejemplo, para alojar los ficheros intermedios creados durante un proceso de compilación. Son ficheros de usar y tirar que no necesitan ser persistentes, pero cuyo rendimiento de acceso debería ser lo más elevado posible.
  • Podemos necesitar almacenar datos en un sistema de archivos, pero no queremos que esos datos se almacenen de forma persistente en ningún sitio, que no dejen rastro ni siquiera accidental. Por ejemplo, por contener claves criptográficas.
  • Necesitamos espacio temporal y tenemos RAM más que suficiente para albergar ese contenido.

En todos estos casos es muy importante que no nos importe que el sistema de archivos desaparezca si se reinicia el ordenador, ya que se almacena en RAM.

Veamos algunas formas de utilizar RAM para montar un sistema de archivos no persistente en entornos Linux:

Leer más…

Cómo ver la temperatura del hardware en una máquina Solaris (o derivados)

Para ver las temperaturas hardware en máquinas con Sistema Operativo Solaris o derivados (Illumos o, en mi caso, SmartOS), podemos hacer lo siguiente:

[root@xXx ~]# /usr/lib/fm/fmd/fmtopo -V "*sensor=temp"
TIME                 UUID
Aug 15 15:30:59 aa2bfd40-5c98-637b-8781-9c452912b4c6

hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=0?sensor=temp
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=0?sensor=temp
  group: authority                      version: 1   stability: Private/Private
    product-id        string    System-Product-Name
    chassis-id        string    System-Serial-Number
    server-id         string    xXx
  group: facility                       version: 1   stability: Private/Private
    sensor-class      string    threshold
    type              uint32    0x1 (TEMP)
    units             uint32    0x1 (DEGREES_C)
    reading           double    73.000000

hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=1?sensor=temp
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=1?sensor=temp
  group: authority                      version: 1   stability: Private/Private
    product-id        string    System-Product-Name
    chassis-id        string    System-Serial-Number
    server-id         string    xXx
  group: facility                       version: 1   stability: Private/Private
    sensor-class      string    threshold
    type              uint32    0x1 (TEMP)
    units             uint32    0x1 (DEGREES_C)
    reading           double    75.000000

hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=2?sensor=temp
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=2?sensor=temp
  group: authority                      version: 1   stability: Private/Private
    product-id        string    System-Product-Name
    chassis-id        string    System-Serial-Number
    server-id         string    xXx
  group: facility                       version: 1   stability: Private/Private
    sensor-class      string    threshold
    type              uint32    0x1 (TEMP)
    units             uint32    0x1 (DEGREES_C)
    reading           double    72.000000

hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=3?sensor=temp
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0/core=3?sensor=temp
  group: authority                      version: 1   stability: Private/Private
    product-id        string    System-Product-Name
    chassis-id        string    System-Serial-Number
    server-id         string    xXx
  group: facility                       version: 1   stability: Private/Private
    sensor-class      string    threshold
    type              uint32    0x1 (TEMP)
    units             uint32    0x1 (DEGREES_C)
    reading           double    73.000000

hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0?sensor=temp
  group: protocol                       version: 1   stability: Private/Private
    resource          fmri      hc://:product-id=System-Product-Name:server-id=xXx:chassis-id=System-Serial-Number/motherboard=0/chip=0?sensor=temp
  group: authority                      version: 1   stability: Private/Private
    product-id        string    System-Product-Name
    chassis-id        string    System-Serial-Number
    server-id         string    xXx
  group: facility                       version: 1   stability: Private/Private
    sensor-class      string    threshold
    type              uint32    0x1 (TEMP)
    units             uint32    0x1 (DEGREES_C)
    reading           double    76.000000

Leer más…

DNSSEC: Migración a ECDSAP256SHA256 en algunos de mis dominios

Tras "Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1 me quedé con el resquemor de migrar mis dominios DNS protegidos con DNSSEC al algoritmo RSASHA256 y no al molón ECDSAP256SHA256. Mi miedo en aquel momento era la compatibilidad [1].

[1] La zona raíz del DNS y el propio dominio regional .es utilizan RSASHA256 para las firmas DNSSEC.

Pero dentro de jcea.es tengo algunos dominios de uso interno y otro con un único "consumidor". Comprobando los resolvers "consumidores" de esos dominios, confirmo que son compatibles con el algoritmo ECDSAP256SHA256 en DNSSEC. ¡Podría migrarlos sin arriesgar la compatibilidad del dominio jcea.es!

Los pasos son similares a los documentados en "Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1, así que no voy a repetir los comandos precisos, me centraré en una descripción de alto nivel:

Leer más…

"Key Rollover" y reconfiguración de mis DNSSEC para eliminar SHA-1

Mi configuración actual DNSSEC utiliza SHA-1, que es un algoritmo de hash al que se le han ido encontrando vulnerabilidades. Lo he mantenido porque un ataque a mi DNS parece poco rentable y porque lo consideraba el más compatible [1], pero la puntilla ha sido un nuevo ataque en enero de 2020. La situación es ya insostenible y mantener SHA-1 resulta injustificable.

[1] (1, 2)

Si durante la verificación DNSSEC un resolver encuentra algoritmos desconocidos, simplemente se comportará como si ese registro DNS no existiese.

En particular, si el registro de anclaje DS que activa DNSSEC en un subdominio no es reconocido, el resolver considerará que el registro no existe y, por tanto, el dominio no tiene DNSSEC.

Incluyo algunos enlaces relevantes en la bibliografía del final.

Las claves públicas DNSSEC actuales de mi dominio jcea.es son:

jcea@jcea:~$ dig DNSKEY jcea.es

; <<>> DiG 9.16.1-Ubuntu <<>> DNSKEY jcea.es
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30207
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;jcea.es.                       IN      DNSKEY

;; ANSWER SECTION:
jcea.es.                86400   IN      DNSKEY  256 3 7 AwEAAdvqYNIq+kT+BeN+EZLr2oygteIWy1McKv9pt3PEXnSmoIUT+puP p6fVbqf5bbPQxp7FD6k2d5U8VpF7c1clcvlqhihgZK59jF1sWe2vM51k QW+ZeyAY5hcWF/DRij7jUa3QcWBJLnOSseV8VEOFfD53FSiIdGpDdVbf OH2Mwi1l
jcea.es.                86400   IN      DNSKEY  257 3 7 AwEAAbBRJkUetAndznEpQm8SI1UFxwy+/ZWyj/CK0MT13Cjx0Yd/Kmah WfFC9G9cpJU3aPw/5w8TOC0Cpa9BluYfBboKu60i1OXlgDvQevevk8Av foqLm213nttALCFfeCTd5iBxJohNQUjreopxcV+FgCG1TKCZQqbDUh5L DaCMDeeHPZJKzIp+Jysif9etSwLnsShUem75X9wv0DLc6i6fdKDsz61j vitl420eDET98LCxRraIgPPjW4yYDoUIEeagtd5VSbgbDXLKVK0nAHlv G4p19cTtZz+Ct928l072FIZ4w3XIDYB7TkWZ5AU/+pXIHfglXwurLtUo gDuHWD2mcgs=

;; Query time: 96 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: jue jul 16 15:41:19 CEST 2020
;; MSG SIZE  rcvd: 460

Ambas claves, la KSK y la ZSK, utilizan el algoritmo 7 que, según el RFC8624, es RSASHA1-NSEC3-SHA1. Está marcado como NOT RECOMMENDED. Toca cambiar.

Leer más…

Cuidado al activar "userobj_accounting" en ZFS

Tras escribir Actualización de características en un sistema de ficheros ZFS (20200528) y decidir que todas mis máquinas con ZFS eran estables y no necesitaban la seguridad de poder volver a una versión previa del Sistema Operativo, me puse a actualizar mis ZPOOLs ZFS con todas las características opcionales disponibles.

La actualización fue simple, rápida e indolora salvo en uno de mis servidores. En ese servidor la operación se eternizó, con una carga de CPU muy elevada, a pesar de que la actividad de disco era relativamente baja.

De todas las características opcionales activadas, la única potencialmente costosa es userobj_accounting, porque requiere repasar los metadatos de todos los archivos y directorios en el ZPOOL.

La extrema carga de CPU en ese servidor es evidente:

top - 02:11:43 up 16 min,  1 user,  load average: 69.54, 61.05, 34.18
Tasks: 298 total,  66 running, 171 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 99.5 sy,  0.0 ni,  0.0 id,  0.3 wa,  0.0 hi,  0.2 si,  0.0 st
KiB Mem :  1994684 total,   240660 free,  1568512 used,   185512 buff/cache
KiB Swap:        0 total,        0 free,        0 used.   279708 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
18438 root      20   0       0      0      0 R   3.6  0.0   0:00.74 arc_prune
18603 root      20   0       0      0      0 R   3.6  0.0   0:00.15 arc_prune
18630 root      20   0       0      0      0 R   3.3  0.0   0:18.67 arc_prune
18461 root      20   0       0      0      0 R   3.3  0.0   0:00.63 arc_prune
18483 root      20   0       0      0      0 R   3.3  0.0   0:00.58 arc_prune
18507 root      20   0       0      0      0 R   3.3  0.0   0:00.42 arc_prune
18522 root      20   0       0      0      0 R   3.3  0.0   0:00.37 arc_prune
18528 root      20   0       0      0      0 R   3.3  0.0   0:00.36 arc_prune
18540 root      20   0       0      0      0 R   3.3  0.0   0:00.31 arc_prune
18548 root      20   0       0      0      0 R   3.3  0.0   0:00.28 arc_prune
18552 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18553 root      20   0       0      0      0 R   3.3  0.0   0:00.26 arc_prune
18560 root      20   0       0      0      0 R   3.3  0.0   0:00.25 arc_prune
18563 root      20   0       0      0      0 R   3.3  0.0   0:00.24 arc_prune
18581 root      20   0       0      0      0 R   3.3  0.0   0:00.16 arc_prune
18589 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18596 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune
18599 root      20   0       0      0      0 R   3.3  0.0   0:00.15 arc_prune

Aquí vemos que la carga de CPU es muy elevada, casi 70, con más de un 99% del tiempo consumido en el Sistema Operativo por hilos ejecutando arc_prune. Buscando ese nombre en internet, aparece un enlace interesante: arc_prune: high load and soft lockups #6223.

Leer más…

Comparación de algoritmos de compresión ZRAM en Raspberry PI

Advertencia

En este artículo solo me interesa utilizar el algoritmo de compresión con mayor reducción. En otras situaciones habrá que tener en cuenta también el impacto en consumo de CPU, pero esto no es un factor en mi caso de uso.

Ten en cuenta que en tu caso puedes valorar otras cosas. Depende de tus necesidades concretas.

En Cómo y por qué utilizar ZRAM como "espacio de intercambio" o SWAP comparo el nivel de compresión de varios algoritmos en mi portátil, con mi perfil de uso del portátil.

Como explico allí, uno de los entornos donde ZRAM es más interesante es en una Raspberry PI, porque por un lado no queremos quemar la microSD con las grabaciones del espacio de intercambio y, por otro, el tamaño de la RAM disponible en una Raspberry PI es limitado y no se puede ampliar.

Las comparativas del nivel de compresión que extraje de mi portátil son útiles, pero prefiero hacer las pruebas también en mi Raspberry PI, fundamentalmente porque el perfil de uso es muy diferente y los resultados de la compresión serán distintos.

La configuración de dispositivos ZRAM es similar a lo explicado en Cómo y por qué utilizar ZRAM como "espacio de intercambio" o SWAP, así que no voy a repetirla aquí. Lo más importante es ver qué algoritmos de compresión tenemos disponibles y probarlos todos. Para ello, una vez que ya hemos creado algún dispositivo ZRAM, podemos preguntarle qué algoritmos de compresión soporta:

root@osmcpi:~# cat /sys/block/zram0/comp_algorithm
lzo lzo-rle lz4 zstd [deflate]

En esta versión del Sistema Operativo tenemos cinco algoritmos de compresión disponibles para ZRAM. Los probamos todos con mi caso de uso y vemos el resultado tras achuchar un poco la Raspberry PI:

Leer más…