miércoles, 14 de febrero de 2024

Solución al error en Autofirma al crear una cuenta directa en tesoro.es en Fedora 38

¡Hola a todos los usuarios de Fedora 38!

Hoy quiero compartir con ustedes una solución a un problema que puede surgir al intentar crear una cuenta directa en el portal tesoro.es utilizando Autofirma. Si te has encontrado con el mensaje de error "Error al recuperar los datos del servidor intermedio" seguido por un error de Java que dice "unable to find valid certification path to requested target", ¡no te preocupes! Aquí te explicaré paso a paso cómo solucionarlo.

Descargar los certificados intermedios

Para empezar, necesitamos descargar los certificados intermedios del servidor utilizando el siguiente comando en la terminal:

openssl s_client -showcerts -connect packagecloud.io:443

Este comando nos mostrará una lista de certificados. Debes copiar cada certificado comprendido entre "BEGIN CERTIFICATE" y "END CERTIFICATE" que se muestra en la terminal. En mi caso, obtuve cuatro certificados.

Guardar los certificados en archivos .crt

Pega cada certificado en un archivo de texto diferente y guárdalos con la extensión .crt. Por ejemplo, puedes nombrarlos como 1.crt, 2.crt, 3.crt y 4.crt.

Importar los certificados en el almacén de confianza de Java

Ahora, vamos a importar cada certificado uno por uno en el almacén de confianza de Java utilizando los siguientes comandos en la terminal:

sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 1.crt -alias "root_cert_1"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 2.crt -alias "root_cert_2"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 3.crt -alias "root_cert_3"
sudo keytool -importcert -keystore /etc/pki/ca-trust/extracted/java/cacerts -storepass changeit -file 4.crt -alias "root_cert_4"

Firmar la operación en Autofirma

Una vez que hayas importado los certificados, vuelve a intentar crear la cuenta directa en tesoro.es utilizando Autofirma. Esta vez, deberías poder firmar la operación sin errores.

¡Y eso es todo! Con estos pasos, deberías poder solucionar el error en Autofirma y completar la creación de tu cuenta directa en tesoro.es sin problemas.

En esta página puedes encontrar más información.

Espero que esta guía te haya sido útil. ¡Si tienes alguna pregunta o comentario, no dudes en dejarlo abajo!

viernes, 17 de noviembre de 2023

Instalación de Grafana, Prometheus y Pi-hole con Ansible

 

Instalación de Grafana, Prometheus y Pi-hole con Ansible en Raspberry Pi

Se describe el proceso para instalar estas aplicaciones en Raspberry Pi:

  uname -r

Devuelve el siguiente resultado sobre la version del SO:

  6.1.0-rpi6-rpi-v8

Para configurar tu red y monitorearla con Grafana, Prometheus y Pi-hole usando Ansible, sigue estos pasos:

  1. Instala ansible:
  2.   pipx install --include-deps ansible
      pipx upgrade --include-injected ansible
  3. Clona el repositorio:
  4.   git clone https://github.com/geerlingguy/internet-pi.git
      cd internet-pi/
      cp example.inventory.ini inventory.ini
      cp example.config.yml config.yml
      nano inventory.ini 
      nano config.yml 
      sudo ansible-playbook main.yml

    Yo he tenido problemas al ejecutar el playbook porque daba el siguiente error al instalar docker-compose:

    
    TASK [Install Docker Compose using Pip.] *************************************************************************
    fatal: [127.0.0.1]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/pip3", "install", "docker-compose"], "msg": "\n:stderr: error: externally-managed-environment\n\n× This environment is externally managed\n╰─> To install Python packages system-wide, try apt install\n    python3-xyz, where xyz is the package you are trying to\n    install.\n    \n    If you wish to install a non-Debian-packaged Python package,\n    create a virtual environment using python3 -m venv path/to/venv.\n    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make\n    sure you have python3-full installed.\n    \n    For more information visit http://rptl.io/venv\n\nnote: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.\nhint: See PEP 668 for the detailed specification.\nDEPRECATION: Loading egg at /usr/local/lib/python3.11/dist-packages/vilib-0.2.0-py3.11.egg is deprecated. pip 24.3 will enforce this behaviour change. A possible replacement is to use pip for package installation.. Discussion can be found at https://github.com/pypa/pip/issues/12330\n"}
      

    Para solucionarlo he intentado instalar docker-compose manualmente, pero tambien da el siguiente error:

     pip install docker-compose

    error: externally-managed-environment
    
    × This environment is externally managed
    ╰─> To install Python packages system-wide, try apt install
        python3-xyz, where xyz is the package you are trying to
        install.
        
        If you wish to install a non-Debian-packaged Python package,
        create a virtual environment using python3 -m venv path/to/venv.
        Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
        sure you have python3-full installed.
        
        For more information visit http://rptl.io/venv
    
    note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
    hint: See PEP 668 for the detailed specification.
      

    Tambien lo intento instalar con:

     pipx install docker-compose
    

    pero tambien da error:

    Fatal error from pip prevented installation. Full pip output in file:
        /.local/pipx/logs/cmd_2023-11-14_22.35.44_pip_errors.log
    
    pip seemed to fail to build package:
        PyYAML6,>=3.10
    
    Some possibly relevant errors from pip install:
        error: subprocess-exited-with-error
        AttributeError: cython_sources
    
    Error installing docker-compose.

    Entonces sigo las instrucciones descritas en este enlace para instalar docker-compose en un entorno virtual

  5. Para instalar Docker Compose manualmente:
  6.  python3 -m venv /ruta/a/tu/entorno_virtual
     source /ruta/a/tu/entorno_virtual/bin/activate
     pip install PyYAML==5.4.1
     pipx install docker-compose

Después de seguir estos pasos, deberías tener instalados Grafana, Prometheus, Pi-hole y Docker Compose para monitorear tu red.

Recuerda ajustar los comandos según tu entorno y las necesidades específicas de tu configuración.

Despues modifica el archivo docker.yml para actualizar el path al comando de instalacion a la nueva ubicacion en el entorno virtual

  nano tasks/docker.yml

El archivo docker.yml contiene pip3 como ejecutable, para que se ejecute pip3 en el entorno virtual, modifica el path del executable:

  - name: Install Docker Compose using Pip.
    ansible.builtin.pip:
    name: docker-compose
    state: present
    executable: /ruta/a/tu/entorno_virtual/bin/pip3

Ahora activamos el entorno virtual y ejecutamos el playbook:

  source ~/python-venv/bin/activate
  ansible-playbook ~/internet-pi/main.yml

miércoles, 11 de octubre de 2023

Cómo instalar Autofirma en Fedora 38

Autofirma es una aplicación gratuita y de código abierto que permite firmar documentos electrónicos con certificados digitales. En este tutorial, veremos cómo instalar Autofirma en Fedora 38.

Paso 1: Descargar Autofirma

La primera etapa es descargar Autofirma desde el sitio web del Ministerio de Asuntos Económicos y Transformación Digital. Una vez descargado, descomprima el archivo en un directorio de su elección.


Paso 2: Instalar Java

Autofirma requiere Java para funcionar. Si no tiene Java instalado, puede instalarlo usando el siguiente comando:

sudo dnf install java-11-openjdk

Paso 3: Asignar el path a Java 11

Por defecto, el path de Java apunta a la última versión instalada. En nuestro caso, esta es la versión 17. Para que Autofirma funcione correctamente, debemos asignar el path a la versión 11.

Para ello, abra el archivo .bashrc con un editor de texto:

nano .bashrc

Añade la siguiente línea al final del archivo:

export PATH=/usr/lib/jvm/java-11-openjdk-11.0.20.0.8-1.fc38.x86_64/bin:$PATH

En el comando anterior, sustituye la ruta al openjdk por la ruta a la version del openjdk que tengas instalada.

Guarda los cambios y cierra el archivo.

Paso 4: Instalar Autofirma

Ahora que hemos asignado el path a Java 11, podemos instalar Autofirma. Para ello, use el siguiente comando:

sudo rpm -i autofirma-1.8.2-1.noarch_FEDORA.rpm --force

Paso 5: Probar Autofirma

Para probar Autofirma, ejecute el siguiente comando:

autofirma

Si todo ha ido bien, debería ver la interfaz de Autofirma.

Solución a un error común

Si al ejecutar Autofirma recibe el siguiente error:

Error: Could not find or load main class es.gob.afirma.main.Main

Es probable que el path de Java aún esté apuntando a la versión 17. Para solucionar este problema, siga los pasos anteriores para asignar el path a la versión 11.

Conclusión

Con estos sencillos pasos, podrá instalar Autofirma en Fedora 38 y empezar a firmar documentos electrónicos con certificados digitales.

viernes, 1 de septiembre de 2023

Actualizando el firmware de OpenWRT en el router WRT54GL

Actualizar de Kamikaze 8 a backfire 10.03.1

Conecto SSH con el router WRT54GL con el comando:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 192.168.110.1

Al hacer
opkg update

aparece una lista de todos los paquetes que no puede ser actualizados porque corresponden a una arquitectura diferente.


edito el archivo /etc/opkg.conf
vi /etc/opkg.conf
que contiene:

src/gz snapshots http://downloads.openwrt.org/kamikaze/8.09.2/brcm-2.4/packages
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /jffs

actualizo la primera linea y la sustituyo por:mount

src/gz snapshots http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages

y ejecuto dos veces:

opkg update

Despues al intentar instalar openvpn desde el UI LuCI aparece el siguiente error:


Installing openvpn (2.1.4-3) to root...

Collected errors:
 * verify_pkg_installable: Only have 0kb available on filesystem /, pkg openvpn needs 185
 * opkg_install_cmd: Cannot install package openvpn.

root@GW8923:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.7M      1.7M         0 100% /rom
tmpfs                     7.0M      1.2M      5.8M  18% /tmp
/dev/mtdblock/4           1.5M    336.0K      1.2M  22% /overlay
mini_fo:/overlay          1.7M      1.7M         0 100% /


root@GW8923:~# cp /rom/etc/opkg.conf /overlay/etc/opkg.conf

root@GW8923:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.7M      1.7M         0 100% /rom
tmpfs                     7.0M      1.3M      5.7M  18% /tmp
/dev/mtdblock/4           1.5M    336.0K      1.2M  22% /overlay
mini_fo:/overlay          1.7M      1.7M         0 100% /


renombro overlay/etc a /overlay/etc.old como paso previo para eliminar ese directorio


root@GW8923:~# mv /overlay/etc/ /overlay/etc.old

sigue apareciendo que hay 0 espacio disponible:


root@GW8923:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.7M      1.7M         0 100% /rom
tmpfs                     7.0M      1.4M      5.6M  20% /tmp
/dev/mtdblock/4           1.5M    336.0K      1.2M  22% /overlay
mini_fo:/overlay          1.7M      1.7M         0 100% /


Sin embargo, intento instalar de nuevo el paquete openvpn

Installing openvpn (2.1.4-3) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages/openvpn_2.1.4-3_brcm-2.4.ipk.
Installing kmod-tun (2.4.37.9-1) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages/kmod-tun_2.4.37.9-1_brcm-2.4.ipk.
Installing libopenssl (0.9.8r-1) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages/libopenssl_0.9.8r-1_brcm-2.4.ipk.
Installing zlib (1.2.3-5) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages/zlib_1.2.3-5_brcm-2.4.ipk.
Installing liblzo (2.04-1) to root...
Downloading http://downloads.openwrt.org/backfire/10.03.1/brcm-2.4/packages/liblzo_2.04-1_brcm-2.4.ipk.
Configuring kmod-tun.
Configuring zlib.
Configuring libopenssl.
Configuring liblzo.
Configuring openvpn.

Collected errors:
 * resolve_conffiles: Existing conffile /etc/config/openvpn is different from the conffile in the new package. The new conffile will be placed at /etc/config/openvpn-opkg.


Despues de instalarlo el espacio disponible en /overlay es menor:

root@GW8923:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.7M      1.7M         0 100% /rom
tmpfs                     7.0M      1.3M      5.7M  19% /tmp
/dev/mtdblock/4           1.5M      1.3M    240.0K  84% /overlay
mini_fo:/overlay          1.7M      1.7M         0 100% /

Instalo luci-app-openvpn

y el espacio disponible queda en:

root@GW8923:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 1.7M      1.7M         0 100% /rom
tmpfs                     7.0M      1.3M      5.7M  19% /tmp
/dev/mtdblock/4           1.5M      1.3M    180.0K  88% /overlay
mini_fo:/overlay          1.7M      1.7M         0 100% /

el sistema de archivos tiene los siguientes puntos de montaje:

  
root@GW8923:~# mount
rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro)
none on /dev type devfs (rw)
none on /proc type proc (rw)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock/4 on /overlay type jffs2 (rw)
mini_fo:/overlay on / type mini_fo (rw)



Rendimiento de discos SATA con bcache y SSD

Mi actual configuración de almacenamiento en Fedora 29 tiene dos RAID0. Uno con discos SATA y bcache y el segundo con discos SDD. El RAID0 esta implementado con Intel Rapid Storage Technology (RST).

Para mostrar el listado de unidades de almacenamiento y particiones actual, ejecutar el comando:

lsblk -o NAME,MAJ:MIN,RM,SIZE,TYPE,FSTYPE,MOUNTPOINT
NAME          MAJ:MIN RM   SIZE TYPE  FSTYPE          MOUNTPOINT
sda             8:0    0 232.9G disk  isw_raid_member 
└─md126         9:126  0 465.8G raid0                 
  ├─md126p1   259:0    0   120G md    xfs             /
  ├─md126p2   259:1    0   1.9G md    ext4            
  └─md126p3   259:2    0 343.9G md    xfs             /home/VMsRepository
sdb             8:16   0 232.9G disk  isw_raid_member 
└─md126         9:126  0 465.8G raid0                 
  ├─md126p1   259:0    0   120G md    xfs             /
  ├─md126p2   259:1    0   1.9G md    ext4            
  └─md126p3   259:2    0 343.9G md    xfs             /home/VMsRepository
sdc             8:32   0 465.8G disk  isw_raid_member 
└─md124         9:124  0 931.5G raid0                 
  └─md124p1   259:3    0 931.5G md    bcache          
    └─bcache0 252:0    0 931.5G disk  xfs             /home
sdd             8:48   0 111.8G disk                  
├─sdd1          8:49   0   500M part  vfat            /boot/efi
├─sdd2          8:50   0     1G part  ext4            /boot
├─sdd3          8:51   0   7.9G part  swap            [SWAP]
└─sdd4          8:52   0 102.5G part  bcache          
  └─bcache0   252:0    0 931.5G disk  xfs             /home
sde             8:64   0 465.8G disk  isw_raid_member 
└─md124         9:124  0 931.5G raid0                 
  └─md124p1   259:3    0 931.5G md    bcache          
    └─bcache0 252:0    0 931.5G disk  xfs             /home
sdk             8:160  0 931.5G disk                  
└─sdk1          8:161  0 931.5G part  ext4            /run/media/Backup01
sr0            11:0    1  1024M rom  

Configuración RAID0 con discos SATA:
/dev/sdcWDC WD5000AZRX-00A8LB0 (01.01A01)500 GB /dev/md/Volume0_0p11000.21 GB /boot/efi524MB EFI SystemFAT16 /boot1.1 GBExt4 swap8,4 GBLinux swap /dev/sdeWDC WD5000AZRX-00A8LB0 (01.01A01)500 GB /dev/md124: Container : /dev/md/imsm0, member 0 Raid Level : raid0 Array Size : 976768000 (931.52 GiB 1000.21 GB) Raid Devices : 2 Total Devices : 2 /dev/sddKINGSTON SH103S3120G (501ABBF0)120 GB 110 GB bcache /home1 TB GB XFS
# mdadm --detail /dev/md124
/dev/md124:
         Container : /dev/md/imsm0, member 0
        Raid Level : raid0
        Array Size : 976768000 (931.52 GiB 1000.21 GB)
      Raid Devices : 2
     Total Devices : 2

             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

        Chunk Size : 128K

Consistency Policy : none


              UUID : 29a34795:f040ca44:6d80b65e:22c429a8
    Number   Major   Minor   RaidDevice State
       1       8       64        0      active sync   /dev/sde
       0       8       32        1      active sync   /dev/sdc

# mdadm --detail /dev/md125
/dev/md125:
           Version : imsm
        Raid Level : container
     Total Devices : 2

   Working Devices : 2


              UUID : c0bdc8e8:5bba49c4:0467a19c:d0a09f7a
     Member Arrays : /dev/md/Volume0_0

    Number   Major   Minor   RaidDevice

       -       8       64        -        /dev/sde
       -       8       32        -        /dev/sdc

Y la configuración de RAID0 con discos SSD:
 
/dev/sdaSamsung SSD 850 EVO 250GB (EMT02B6Q) /dev/sdbSamsung SSD 850 EVO 250GB (EMT02B6Q) /dev/md/SystemRAID0500.11 GB /129 GB XFS Not mounted2 GB Ext4 home/VMsRepository369 GB XFS /dev/md126: Container : /dev/md/imsm1, member 0 Raid Level : raid0 Array Size : 488391680 (465.77 GiB 500.11 GB) Raid Devices : 2 Total Devices : 2
# mdadm --detail /dev/md126
/dev/md126:
         Container : /dev/md/imsm1, member 0
        Raid Level : raid0
        Array Size : 488391680 (465.77 GiB 500.11 GB)
      Raid Devices : 2
     Total Devices : 2

             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

        Chunk Size : 128K

Consistency Policy : none


              UUID : dc00ef36:c7b058c3:a6598f75:06f6e016
    Number   Major   Minor   RaidDevice State
       1       8        0        0      active sync   /dev/sda
       0       8       16        1      active sync   /dev/sdb

# mdadm --detail /dev/md127
/dev/md127:
           Version : imsm
        Raid Level : container
     Total Devices : 2

   Working Devices : 2


              UUID : 0125bb79:4caae511:15023fbb:4006b23c
     Member Arrays : /dev/md/SystemRAID0

    Number   Major   Minor   RaidDevice

       -       8        0        -        /dev/sda
       -       8       16        -        /dev/sdb


Comparando los dos RAID0:
Primero en el raid SSD

#sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting

randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.7
Starting 4 processes
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
Jobs: 4 (f=4): [r(4)][100.0%][r=153MiB/s,w=0KiB/s][r=39.1k,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=4): err= 0: pid=19959: Sun May 26 20:38:56 2019
   read: IOPS=40.6k, BW=159MiB/s (166MB/s)(2048MiB/12902msec)
    slat (usec): min=73, max=8454, avg=94.76, stdev=28.83
    clat (usec): min=2, max=10144, avg=1477.35, stdev=157.81
     lat (usec): min=87, max=10244, avg=1572.52, stdev=164.40
    clat percentiles (usec):
     |  1.00th=[ 1270],  5.00th=[ 1303], 10.00th=[ 1336], 20.00th=[ 1385],
     | 30.00th=[ 1401], 40.00th=[ 1434], 50.00th=[ 1467], 60.00th=[ 1483],
     | 70.00th=[ 1516], 80.00th=[ 1565], 90.00th=[ 1631], 95.00th=[ 1696],
     | 99.00th=[ 1860], 99.50th=[ 1958], 99.90th=[ 2278], 99.95th=[ 2966],
     | 99.99th=[ 9765]
   bw (  KiB/s): min=38320, max=42080, per=25.03%, avg=40680.80, stdev=871.14, samples=100
   iops        : min= 9580, max=10520, avg=10170.18, stdev=217.76, samples=100
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 100=0.01%, 250=0.01%
  lat (usec)   : 500=0.01%, 750=0.01%, 1000=0.01%
  lat (msec)   : 2=99.59%, 4=0.38%, 10=0.01%, 20=0.01%
  cpu          : usr=4.53%, sys=14.80%, ctx=524767, majf=0, minf=111
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=524288,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=159MiB/s (166MB/s), 159MiB/s-159MiB/s (166MB/s-166MB/s), io=2048MiB (2147MB), run=12902-12902msec

Disk stats (read/write):
    md126: ios=520885/0, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=262144/0, aggrmerge=0/0, aggrticks=21902/0, aggrin_queue=27, aggrutil=99.02%
  sdb: ios=262144/0, merge=0/0, ticks=22610/0, in_queue=44, util=99.02%
  sda: ios=262144/0, merge=0/0, ticks=21195/0, in_queue=10, util=97.82%

Ahora en el raid SATA con bcache

# sudo fio --name=randread --ioengine=libaio --iodepth=16 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=4 --runtime=240 --group_reporting

randread: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
...
fio-3.7
Starting 4 processes
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
randread: Laying out IO file (1 file / 512MiB)
Jobs: 4 (f=4): [r(4)][100.0%][r=1164KiB/s,w=0KiB/s][r=291,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=4): err= 0: pid=20549: Sun May 26 20:44:54 2019
   read: IOPS=291, BW=1168KiB/s (1196kB/s)(274MiB/240041msec)
    slat (usec): min=80, max=194852, avg=13690.49, stdev=10673.08
    clat (usec): min=5, max=610985, avg=205391.13, stdev=44617.88
     lat (msec): min=27, max=635, avg=219.08, stdev=46.30
    clat percentiles (msec):
     |  1.00th=[  124],  5.00th=[  142], 10.00th=[  155], 20.00th=[  169],
     | 30.00th=[  180], 40.00th=[  190], 50.00th=[  201], 60.00th=[  211],
     | 70.00th=[  224], 80.00th=[  241], 90.00th=[  264], 95.00th=[  284],
     | 99.00th=[  338], 99.50th=[  355], 99.90th=[  401], 99.95th=[  430],
     | 99.99th=[  575]
   bw (  KiB/s): min=   80, max=  448, per=24.99%, avg=291.67, stdev=44.48, samples=1920
   iops        : min=   20, max=  112, avg=72.88, stdev=11.12, samples=1920
  lat (usec)   : 10=0.01%
  lat (msec)   : 50=0.01%, 100=0.07%, 250=85.32%, 500=14.56%, 750=0.02%
  cpu          : usr=0.08%, sys=0.39%, ctx=70109, majf=0, minf=109
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=99.9%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=70076,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16

Run status group 0 (all jobs):
   READ: bw=1168KiB/s (1196kB/s), 1168KiB/s-1168KiB/s (1196kB/s-1196kB/s), io=274MiB (287MB), run=240041-240041msec

Disk stats (read/write):
    bcache0: ios=70048/212, merge=0/0, ticks=954259/668, in_queue=954927, util=28.96%, aggrios=35128/266, aggrmerge=0/6, aggrticks=206/200, aggrin_queue=303, aggrutil=0.21%
    md124: ios=70028/331, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=35014/155, aggrmerge=0/14, aggrticks=477297/315, aggrin_queue=460121, aggrutil=21.90%
  sde: ios=33713/152, merge=0/13, ticks=448824/272, in_queue=432278, util=20.81%
  sdc: ios=36316/158, merge=0/15, ticks=505771/359, in_queue=487965, util=21.90%
  sdd: ios=229/202, merge=0/13, ticks=412/401, in_queue=606, util=0.21% 

Usando la utilidad de benchmarking de gnome-disks.
 
En la partición 3 del raid SSD:

En la partición con bcache del raid con discos SATA:

Primero con la cache vacía:

Después de realizar el test anterior, la cache ya contiene datos y el tiempo de acceso se reduce de forma drástica:

Comparamos ahora el mismo dispositivo sin cache activada:


Con respecto al tiempo de arranque:
Con la configuración actual de discos HDD en RAID0 con bcache en SSD, el tiempo de arranque es:
# systemd-analyze 
Startup finished in 1.824s (kernel) + 1.994s (initrd) + 58.781s (userspace) = 1min 2.600s
graphical.target reached after 58.764s in userspace

Un segundo arranque confirma resultados similares:
# systemd-analyze 
Startup finished in 1.793s (kernel) + 1.874s (initrd) + 59.652s (userspace) = 1min 3.320s
graphical.target reached after 59.584s in userspace

Para obtener el resultado de forma gráfica, se puede usar:
# systemd-analyze plot > Pictures/Bootcharts/plot-20190603-1.svg

o también:
/usr/lib/systemd/systemd-bootchart
que crea un archivo svg en /run/log
 
En este articulo se citan varias posibilidades para reducir el tiempo de arranque.