Actualizar el modo Air-Gap de Secure Malware Analytics Appliance

Introducción

Esta guía describe los procedimientos para actualizar un Secure Malware Analytics Appliance en modo Air-Gap.

Nota: el mantenimiento de los dispositivos en modo Air-Gap puede disminuir su eficacia. Antes de continuar, considere la posibilidad de elegir entre seguridad y funcionalidad.

Prerequisites

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico de entradas a través de la línea de comandos en entornos Windows y Unix/Linux
• Conocimiento del dispositivo de análisis de malware
• Conocimientos de Cisco Integrated Management Controller (IMC)

Componentes Utilizados

Cisco recomienda familiarizarse con los siguientes temas:

• SO basado en Windows 10 y Linux (por ejemplo: CentOS y RedHat)
• RUFUS 2,17
• C220 M4, M510 y M520 M5, M610 y M620 M6 (modelos de appliances)

La información de este documento se basa en dispositivos en un entorno de laboratorio controlado con configuraciones predeterminadas. Si su red está activa, tenga cuidado y comprenda a fondo las posibles implicaciones de cualquier comando antes de continuar.

Antecedentes

La mayoría de los dispositivos Secure Malware Analytics se conectan a Internet y utilizan el proceso de actualización en línea. Sin embargo, algunos dispositivos se mantienen estrictamente dentro de las redes internas (con espacios de ventilación). Cisco no recomienda este enfoque, ya que reduce la eficacia. Esta guía proporciona el proceso de actualización fuera de línea para aquellos que deben mantener los dispositivos con espacios de ventilación limitados.

Para las actualizaciones de Secure Malware Analytics sin conexión, Cisco proporciona medios de actualización previa solicitud. Siga el proceso de actualización sin conexión descrito en este documento.

Medios: El soporte de Secure Malware Analytics proporciona medios de actualización Airgap (sin conexión) a petición. Es un archivo ISO que se puede copiar a una unidad USB o disco duro (con tamaño suficiente).

Tamaño:El tamaño de los medios de actualización varía en función de las versiones compatibles y puede aumentar significativamente con la introducción de nuevas máquinas virtuales. Para las versiones actuales, el tamaño es de aproximadamente 30 GB, incluida la herramienta desync, que permite actualizaciones incrementales para cambios relacionados con VM.

Ciclo de arranque de actualización: Cada vez que se arranca el medio de actualización de airgap, determina la siguiente versión a la que actualizar y copia el contenido asociado a esa próxima versión en el dispositivo. Una versión determinada también puede iniciar la instalación de un paquete si dicha versión no tiene ninguna comprobación de requisitos previos que se deba ejecutar mientras el dispositivo se está ejecutando. Si la versión incluye dichas comprobaciones o una sustitución en partes del proceso de actualización que podrían agregar dichas comprobaciones, la actualización no se aplicará realmente hasta que el usuario inicie sesión en OpAdmin e invoque la actualización con OpAdmin > Operations > Update Appliance.

 Ganchos de preinstalación: Dependiendo de si hay algún enlace de preinstalación para esa actualización específica, ejecuta la actualización inmediatamente o reinicia el dispositivo nuevamente en su modo de funcionamiento normal para permitir que el usuario ingrese a la interfaz administrativa habitual e inicie esa actualización manualmente.

 Repita El Proceso Según Sea Necesario: Por lo tanto, cada ciclo de arranque de medios de este tipo actualiza (o se prepara para actualizar) solo un paso hacia la versión final de destino; el usuario debe iniciar tantas veces como sea necesario para actualizar a la versión de destino deseada.

Limitaciones

El medio CIMC no es compatible con las actualizaciones por espacios de aire.

Debido a las limitaciones de licencia de los componentes de terceros utilizados, los medios de actualización para las versiones 1.x ya no están disponibles después de que el hardware UCS M3 haya alcanzado el fin de vida útil (EOL). Por lo tanto, es fundamental que los appliances UCS M3 se sustituyan o actualicen antes de la fase EOL. 

Requirements

Migraciones: Si las notas de la versión de las versiones incluidas incluyen situaciones en las que es obligatorio que la migración se realice antes de instalar la siguiente versión, el usuario debe seguir estos pasos antes de reiniciar de nuevo para evitar que su dispositivo quede en un estado inutilizable.

Nota: La primera versión 2.1.x más reciente que la 2.1.4, en particular, ejecuta varias migraciones de bases de datos. No es seguro continuar hasta que se completen estas migraciones. Para obtener más información, consulte la nota de migración de Threat Grid Appliance 2.1.5.

 Si a partir de una versión anterior a la 2.1.3, el medio de actualización airgap utiliza una clave de cifrado derivada de la licencia individual y, por lo tanto, debe personalizarse por dispositivo. (El único efecto visible para el usuario es que, con medios creados para admitir versiones de origen anteriores a la 2.1.3, Secure Malware Analytics necesita las licencias instaladas en esos dispositivos de antemano y los medios no funcionarán en ningún dispositivo que no esté en la lista para la que se creó.)

Si se empieza con la versión 2.1.3 o posterior, el medio de ventilación es genérico y no se necesita información del cliente. 

Antes de comenzar

• Copia de seguridad. Debe considerar la posibilidad de realizar una copia de seguridad del dispositivo antes de continuar con la actualización.
• Revise las notas de la versión de la versión que desea actualizar para comprobar si hay alguna migración en segundo plano necesaria antes de actualizar a la versión más reciente
• Verifique la versión actual de su dispositivo: OpAdmin > Operations > Update Appliance
• Revise el historial de versiones del dispositivo Secure Malware Analytics en la tabla de búsqueda de número de compilación/versión, que está disponible en todos los documentos del dispositivo Threat Grid: Notas de la versión, Notas de migración, Guía de configuración y configuración y Guía del administrador.

Actualizar un dispositivo de análisis de malware seguro sin conexión (Airgapped)

En primer lugar, compruebe la versión disponible de Air Gapped en esta página: Tabla de búsqueda de versión de dispositivo

1. Abra una solicitud de asistencia del TAC para obtener los medios de actualización sin conexión. Esta solicitud debe incluir el número de serie del dispositivo, así como el número de compilación del dispositivo.

2. El soporte del TAC proporciona una ISO actualizada basada en su instalación.

3. Grabe la imagen ISO en un USB de arranque. Tenga en cuenta que USB es el único dispositivo/método compatible para las actualizaciones sin conexión.

Convenciones para la asignación de nombres

Este es el nombre de archivo actualizado, por ejemplo: TGA Airgap Update 2.16.2-2.17.2.

Esto significa que este medio se puede utilizar para un dispositivo que ejecuta una versión mínima: 2.16.2 y actualizar el dispositivo a la versión: 2.17.2.

Limitaciones

• El medio CIMC no es compatible con las actualizaciones por espacios de aire.
• Debido a las limitaciones de licencia de los componentes de terceros utilizados, los medios de actualización para las versiones 1.x ya no estarán disponibles después de que el hardware UCS M3 haya alcanzado el fin de vida útil (EOL). Por lo tanto, es fundamental que los appliances UCS M3 se sustituyan o actualicen antes de la fase EOL.

Linux/MAC - Descarga de ISO

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Una máquina Linux con acceso a Internet para descargar el ISO y crear la unidad de instalación USB de arranque.
• Las instrucciones de descarga de Airgap las proporciona Secure Malware Analytics Support.
• lenguaje de programación GO. Descargar
• El archivo de índice .caibx (incluido en el archivo zip proporcionado por el Soporte del TAC).
• Herramienta de desincronización (incluida en el archivo zip proporcionado por Secure Malware Analytics Support).

Componentes Utilizados

La información de este documento se basa en un sistema operativo basado en Linux (por ejemplo: CentOS y RedHat). 

La información de este documento se basa en dispositivos en un entorno de laboratorio controlado con configuraciones predeterminadas. Si su red está activa, tenga cuidado y comprenda a fondo las posibles implicaciones de cualquier comando antes de continuar.

Configurar

Instalación del lenguaje de programación GO

# wget https://go.dev/dl/go1.23.1.linux-amd64.tar.gz
# tar -xzf go1.23.1.linux-amd64.tar.gz
# mv go /usr/local

Ejecute estos tres comandos después de la instalación, si no falla el comando desync

# export GOROOT=/usr/local/go
# export GOPATH=$HOME/Projects/Proj1
# export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

Puede verificar la versión GO de la siguiente manera:

# go version

Descargue el ISO mediante el comando Desync

Paso 1. Copie el contenido del archivo Zip proporcionado por Secure Malware Analytics Support incluyendo el archivo desync.linux y el archivo .caibx en el mismo directorio localmente en el equipo.

Paso 2. Cambie al directorio en el que almacenó los archivos:

Ejemplo:

# cd MyDirectory/TG

Paso 3. Ejecute el comando pwd para asegurarse de que está dentro del directorio.

# pwd

Paso 4. Una vez que esté dentro del directorio que incluye el comando desync.linux y el archivo .caibx, ejecute el comando de su elección para comenzar el proceso de descarga.

Nota: Estos son los ejemplos de diferentes versiones de ISO; consulte el archivo .caibx de las instrucciones proporcionadas por el Soporte de Secure Malware Analytics.

Para las versiones 2.16.2 a 2.17.2 ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/sma-appliance-airgap-update airgap-update-2.16.2ag-2.17.2.caibx airgap-update-2.16.2ag-2.17.2.iso

Para las versiones 2.4.3.2 a 2.5 ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/threatgrid-appliance-airgap-update airgap-update-2.4.3.2-2.5.caibx airgap-update-2.4.3.2-2.5.iso

Para las versiones 2.5 a 2.7.2ag ISO:

# desync extract -k -s s3+https://s3.amazonaws.com/threatgrid-appliance-airgap-update airgap-update-2.5-2.7.2ag.caibx airgap-update-2.5-2.7.2ag.iso

Una vez que comienza la descarga, se muestra una barra de progreso.

Nota: La velocidad de descarga y el tamaño de los medios de actualización en su entorno pueden afectar al tiempo para componer la ISO.
Asegúrese de comparar el MD5 del archivo descargado con el disponible con el paquete proporcionado por el soporte para validar la integridad del ISO descargado.

Una vez completada la descarga, los ISO se crean en el mismo directorio.

Conecte el USB a la máquina y ejecute el comando dd para crear la unidad USB de arranque.

# dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M

Donde <MY_USB> es el nombre de la llave USB (no entre paréntesis angulares).

Introduzca la unidad USB y encienda o reinicie el equipo. En la pantalla de inicio de Cisco, presione F6 para ingresar al Menú de inicio.

Consejo:
Ejecute la descarga después de las horas de oficina o fuera de las horas pico, ya que podría afectar al ancho de banda.
Para detener la herramienta, cierre el terminal o presione Ctrl+c/Ctrl+z.
Para continuar, ejecute el mismo comando para reanudar la descarga.

Windows - Descarga de ISO

Instalación del lenguaje de programación GO

1. Descargue el lenguaje de programación GO necesario. Instalar desde https://golang.org/dl/ En mi caso, selecciono la versión destacada. Reinicie el CMD y pruébelo con
   
   

   Cierre y vuelva a abrir el comando CMD run para verificar:

   go version

   

   Descargue el ISO mediante el comando Desync

2. Instale el DESINCRÓNICO herramienta. Después de la ejecución del comando, puede observar un montón de mensajes de descarga. Aproximadamente después de 2-3 minutos, la descarga debe hacerse.
   

   go install github.com/folbricht/desync/cmd/desync@latest

   In case desync is not working using above command then change directory to C drive and run this command: 
   
   git clone https://github.com/folbricht/desync.git
   
   

   

   Nota: Si el comando git no funciona, puedes descargar e instalar Git desde aquí : https://git-scm.com/download/win.

   Luego ejecute debajo de dos comandos uno por uno :
   
   

   cd desync/cmd/desync
   
   go install

   

    

3. Vaya a   go — > bin ubicación. Por ejemplo C:\Users\<username>\go\bin y copie y pegue el TAC proporcionado .caibx archivo de índice.
   
4. (Verificar) Vuelva a su mensaje de CMD y navegue hasta la carpeta go\bin y ejecute los comandos de descarga. Debería ver inmediatamente cómo continúa la descarga. Espere a que se complete la descarga. Ahora debería tener la información completa .ISO en la misma ubicación que el archivo copiado anteriormente .caibx archivo de índice
   

   \$HOME/go/bin/desync extract -k -s s3+https://s3.amazonaws.com/sma-appliance-airgap-update airgap-update-2.16.2ag-2.17.2.caibx airgap-update-2.16.2ag-2.17.2.iso
   

   

   Para crear este USB de recuperación específico, es crucial utilizar la versión 2.17 de Rufus, ya que le permite utilizar opciones de dd esenciales. Puede encontrar todas las versiones de RUFUS en este repositorio.

   

    

Arranque del dispositivo desde USB

1. Introduzca el puerto USB, reinicie el aparato, y presione rápidamente F6 en la pantalla de inicio de Cisco para ingresar al Menú de inicio.
   
2. Navegue hasta la unidad USB que contiene la actualización y presione Enter para seleccionar.
   
   

   El medio de actualización determina la siguiente versión en la ruta de actualización y copia el contenido de esa versión en el dispositivo. El dispositivo ejecuta la actualización inmediatamente o se reinicia de nuevo en su modo de funcionamiento normal para permitirle introducir OpAdmin e iniciar la actualización manualmente.

   Una vez finalizado el proceso de arranque ISO, reinicie el dispositivo Secure Malware Analytics de nuevo en modo de funcionamiento.

   Inicie sesión en la interfaz de usuario del portal y compruebe si hay advertencias que indiquen si es seguro actualizar, etc., antes de continuar.

3. Navegue hasta la interfaz OpAdmin y aplique las actualizaciones, si no se aplicaron automáticamente durante el reinicio: OpAdmin > Operations > Update Appliance NOTA: El proceso de actualización incluye reinicios adicionales como parte de la actualización, que se realiza a partir de los medios USB. Por ejemplo, es necesario utilizar el botón Reiniciar en la página de instalación después de instalar las actualizaciones.
   Repita este procedimiento según sea necesario para cada versión del dispositivo USB.

Cómo encontrar el dispositivo /dev correcto

Con el USB todavía no conectado al terminal ejecute el comando "lsblk | grep -iE 'disk|part'.

xsilenc3x@Alien15:~/testarea/usb$ lsblk | grep -iE 'disk|part'
sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   128M  0 part
└─sda2        8:2    0 931.4G  0 part /media/DATA
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   650M  0 part
├─nvme0n1p2 259:2    0   128M  0 part
├─nvme0n1p3 259:3    0 114.1G  0 part
├─nvme0n1p4 259:4    0   525M  0 part /boot
├─nvme0n1p5 259:5    0   7.6G  0 part [SWAP]
├─nvme0n1p6 259:6    0  38.2G  0 part /
├─nvme0n1p7 259:7    0  62.7G  0 part /home
├─nvme0n1p8 259:8    0  13.1G  0 part
└─nvme0n1p9 259:9    0   1.1G  0 part
xsilenc3x@Alien15:~/testarea/usb$

 Una vez conectada la memoria USB.

xsilenc3x@Alien15:~/testarea/usb$ lsblk | grep -iE 'disk|part'
.sda           8:0    0 931.5G  0 disk
├─sda1        8:1    0   128M  0 part
└─sda2        8:2    0 931.4G  0 part /media/DATA
sdb           8:16   1   3.7G  0 disk
└─sdb1        8:17   1   3.7G  0 part /media/xsilenc3x/ARCH_201902  <--------- not observed when the USB was not connected
nvme0n1     259:0    0 238.5G  0 disk
├─nvme0n1p1 259:1    0   650M  0 part
├─nvme0n1p2 259:2    0   128M  0 part
├─nvme0n1p3 259:3    0 114.1G  0 part
├─nvme0n1p4 259:4    0   525M  0 part /boot
├─nvme0n1p5 259:5    0   7.6G  0 part [SWAP]
├─nvme0n1p6 259:6    0  38.2G  0 part /
├─nvme0n1p7 259:7    0  62.7G  0 part /home
├─nvme0n1p8 259:8    0  13.1G  0 part
└─nvme0n1p9 259:9    0   1.1G  0 part
xsilenc3x@Alien15:~/testarea/usb$

Esto confirma que el dispositivo USB en /dev es "/dev/sdb".

Otras formas de confirmar, después de conectar el dispositivo USB:

El comando dmesg proporciona cierta información. Una vez conectado el USB, ejecute el comando dmesg | grep -iE 'usb|attachment'.

xsilenc3x@Alien15:~/testarea/usb$ dmesg | grep -iE 'usb|attached'
[842717.663757] usb 1-1.1: new high-speed USB device number 13 using xhci_hcd
[842717.864505] usb 1-1.1: New USB device found, idVendor=0781, idProduct=5567
[842717.864510] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[842717.864514] usb 1-1.1: Product: Cruzer Blade
[842717.864517] usb 1-1.1: Manufacturer: SanDisk
[842717.864519] usb 1-1.1: SerialNumber: 4C530202420924105393
[842717.865608] usb-storage 1-1.1:1.0: USB Mass Storage device detected
[842717.866074] scsi host1: usb-storage 1-1.1:1.0
[842718.898700] sd 1:0:0:0: Attached scsi generic sg1 type 0
[842718.922265] sd 1:0:0:0: [sdb] Attached SCSI removable disk  <-------
xsilenc3x@Alien15:~/testarea/usb$

El comando fidsk proporciona información sobre el tamaño, que se puede utilizar para confirmar: sudo fdisk -l /dev/sdb.

xsilenc3x@Alien15:~/testarea/usb$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 3.7 GiB, 4004511744 bytes, 7821312 sectors  <-------
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x63374e06

Device     Boot Start    End Sectors  Size Id Type
/dev/sdb1  *        0 675839  675840  330M  0 Empty
/dev/sdb2         116   8307    8192    4M ef EFI (FAT-12/16/32)
xsilenc3x@Alien15:~/testarea/usb$

Nota: Recuerde desmontar el USB antes de ejecutar el comando "dd".

Confirmación de que el dispositivo USB del ejemplo está montado.

xsilenc3x@Alien15:~/testarea/usb$ sudo mount -l | grep -i sdb
/dev/sdb1 on /media/xsilenc3x/ARCH_201902 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) [ARCH_201902]

Para desmontar el dispositivo USB utilice sudo umount /dev/sdb1.

xsilenc3x@Alien15:~/testarea/usb$ sudo umount /dev/sdb1

Vuelva a comprobar si el dispositivo no se considera "montado".

xsilenc3x@Alien15:~/testarea/usb$ sudo mount -l | grep -i sdb

status=opción de progreso

oflag=sync y status=progress en el comando dd.

Cuando se escriben numerosos bloques de datos, la opción "status=progress" proporciona información sobre las operaciones de escritura actuales. Esto es útil para confirmar si el comando "dd" está escribiendo actualmente en la caché de páginas; se puede utilizar para mostrar el progreso y la cantidad completa de tiempo en segundos de todas las operaciones de escritura.

Cuando no se utiliza, "dd" no proporciona información sobre el progreso, sólo se proporcionan los resultados de las operaciones de escritura antes de que "dd" devuelva:

[rootuser@centos8-01 tga-airgap]$ dd if=/dev/zero of=testfile.txt bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 5.03493 s, 1.7 GB/s
[rootuser@centos8-01 tga-airgap]$ 

Cuando se utiliza, la información en tiempo real sobre las operaciones de escritura se actualiza cada segundo.

[rootuser@centos8-01 tga-airgap]$ dd if=/dev/zero of=testfile.txt bs=1M count=8192 status=progress
8575254528 bytes (8.6 GB, 8.0 GiB) copied, 8 s, 1.1 GB/s <----------------
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 8.03387 s, 1.1 GB/s
[rootuser@centos8-01 tga-airgap]

Nota: En la documentación oficial para el proceso de actualización sin conexión de TGA, el comando que se informa es : dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M

Después de algunas pruebas, se observa el siguiente ejemplo.

Una vez creado un archivo de 10MB con "dd" usando el dispositivo /dev/zero.

1M x 10 = 10M (10240 kB + datos anteriores del sistema en cachés de páginas de archivos dañadas = 10304 kB —> esto es lo que se percibe en la caché de páginas dañadas al final de "dd").

[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && dd if=/dev/zero of=testfile.txt bs=1M \
count=10 status=progress && cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                92 kB
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0138655 s, 756 MB/s
Dirty:             10304 kB <----- dirty page cache after "dd" returned | data still to be written to the block device
1633260775 <---- epoch time
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10372 kB
1633260778
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10380 kB
1633260779
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10404 kB
1633260781
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10412 kB
1633260782
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10424 kB
1633260783
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:             10436 kB
1633260785
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                 0 kB  <--- data in the dirty page cache flushed = written to the block device
1633260786 <---- epoch time
[rootuser@centos8-2 testarea]$
```

1633260786 - 1633260775 = 11 seconds

Nota: Después de que regresó el comando "dd", la operación de escritura en el dispositivo de bloqueo no se completó, se percibió 11 segundos después del retorno.
Si este fuera el comando "dd" al crear el USB de arranque con el TGA ISO, Y yo había eliminado el USB del terminal antes de esos 11 segundos = Yo tendría un ISO dañado en el USB de arranque.

Explicación:

Los dispositivos de bloqueo proporcionan acceso almacenado en búfer a los dispositivos de hardware. Esto proporciona una capa de abstracción para las aplicaciones cuando se trabaja con dispositivos de hardware.

Los dispositivos de bloqueo permiten que una aplicación lea/escriba por bloques de datos de diferentes tamaños; este read()/write() se aplica en las memorias caché de páginas (buffers) y no directamente en el dispositivo de bloqueo.
El núcleo ( y no la aplicación que hace la lectura/escritura ) administra el movimiento de datos desde los búferes (memorias caché de páginas) a los dispositivos de bloque.

Por lo tanto:

La aplicación (en este caso "dd") no tiene control sobre el vaciado de los búferes si no se le indica.

La opción "oflag=sync" fuerza la escritura física sincrónica (por parte del núcleo) después de colocar cada bloque de salida (proporcionado por "dd") en la memoria caché de la página.
oflag=sync degrada el rendimiento "dd" en comparación con no utilizar la opción; pero, si está activado, garantiza una escritura física en el dispositivo de bloqueo después de cada llamada write() desde "dd".

Prueba: El uso de la opción "oflag=sync" del comando "dd" para confirmar todas las operaciones de escritura con los datos de caché de páginas dañadas se completó al volver el comando "dd":

[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && dd if=/dev/zero of=testfile.txt bs=1M \
count=10 oflag=sync status=progress && cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                60 kB
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0841956 s, 125 MB/s
Dirty:                68 kB <---- No data remaining in the dirty page cache after "dd" returned
1633260819
[rootuser@centos8-2 testarea]$ cat /proc/meminfo | grep -iE 'dirty' && date +%s
Dirty:                36 kB
1633260821
[rootuser@centos8-2 testarea]$

No quedan datos de la operación de escritura en la caché de páginas dañadas.
La operación de escritura se aplicó antes (o en el mismo instante) de que regresara el comando "dd" (no 11 segundos después de la prueba anterior).
Ahora estoy seguro de que después de que el comando "dd" regresó no había datos en la memoria caché de la página corrupta relacionados con la operación de escritura = no hay problemas en la creación de arranque USB (si la suma de comprobación ISO es correcta).

Nota: Tenga en cuenta este indicador (oflag=sync) del comando "dd" cuando trabaje en este tipo de caso.

Secuencia de arranque para unidades de disco duro para actualizaciones fuera de línea

Requisito:

Debemos asegurarnos de que el disco duro esté formateado con la opción "DD" utilizando cualquier herramienta disponible y que los medios se copien después en la unidad. Si no utilizamos este formato, no podríamos leer este medio.

Una vez que tengamos los medios cargados en el disco duro/USB usando el formato "DD", necesitamos conectarlo al dispositivo TGA y reiniciar el dispositivo.

Esta es la pantalla de selección predeterminada del menú de arranque. Necesitamos presionar "F6" para iniciar el dispositivo y seleccionar el medio de arranque

Una vez que el dispositivo reconoce nuestra entrada, se le solicitará que entre en el menú de selección de arranque.

Este es el mensaje que puede diferir entre diferentes modelos TGA. Idealmente, veríamos la opción de arrancar usando el medio de arranque (upgrade filesystem) desde este mismo menú, pero si no se ve, necesitamos iniciar sesión en el "Shell de EFI".

 

Tendría que pulsar "ESC" antes de que el script "startup.sh" finalice para pasar al shell de EFI. Una vez que iniciamos sesión en el shell de EFI, nos daríamos cuenta de que las particiones detectadas en este caso son 3 sistemas de archivos: fs0:, fs1:, fs2.

¡Importante

Identificación del sistema de archivos correcto:

• Según la captura de pantalla anterior, usted podría ver que "fs0:" es el único medio con "USB" en su trayectoria y por lo tanto podemos estar seguros de que este sistema de archivos contendría el medio de arranque (upgrade filesystem).

En caso de que falten sistemas de archivos:

• Si sólo fs0: y fs1: están disponibles y no hay fs2:, verifique que el medio de arranque (sistema de archivos de actualización) se haya escrito en modo dd y que se haya conectado correctamente.
• Los medios de arranque (sistema de archivos de actualización) siempre deben tener un número menor que los medios de recuperación, y siempre deben estar uno al lado del otro; lo más probable es que cambie la unidad conectada al USB al principio del final (por lo tanto, si toma la posición frontal en fs0: o la posición posterior en fs2:) tendría que ser identificada
• En este caso, en la captura de pantalla siguiente, aparece el archivo ".efi" correcto, ya que se encuentra en la partición "\efi\boot" y tiene la convención de nomenclatura "bootx64.efi"

 

Para arrancar el dispositivo en el medio de arranque (upgrade filesystem), debemos ejecutar el archivo "bootx64.efi":

fs0:\efi\boot\bootx64.efi

Para su referencia, hemos mostrado el contenido de los otros sistemas de archivos a continuación:

fs1: Este es el sistema de archivos de arranque principal.

fs2: Este es el sistema de archivos de arranque de la imagen de recuperación.

Instrucciones varias:

Para verificar el sistema de archivos correcto que contiene el medio de arranque montado. Podemos hacerlo explorando los diferentes sistemas de archivos y verificando el archivo de inicio ".efi"

Nota: La secuencia del medio de arranque real (sistema de archivos de actualización) que en este caso es "fs0:" también puede variar con otros dispositivos.
El nombre y la ruta pueden variar, pero en todas las imágenes modernas, esto debe ser el mismo.

Lista de comprobación que puede ayudar a localizar el medio de arranque correcto (actualizar el sistema de archivos):

• Si la raíz de un sistema de archivos contiene "vmlinuz-appliance", no es el medio de arranque (upgrade filesystem).
• Si la raíz de un sistema de archivos contiene "meta_contents.tar.xz", no es el medio de arranque (upgrade filesystem).
• Si un sistema de archivos no contiene "efi\boot\bootx64.efi", no es el medio de arranque (sistema de archivos de actualización).