Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce guide décrit les procédures de mise à jour d'une appliance Secure Malware Analytics en mode air-gap.
Remarque : le maintien des appareils en mode air-gap peut diminuer leur efficacité. Pensez à l'arbitrage entre la sécurité et la fonctionnalité avant de continuer.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Cisco recommande de se familiariser avec les sujets suivants :
Les informations contenues dans ce document sont basées sur des périphériques dans un environnement de travaux pratiques contrôlé avec des configurations par défaut. Si votre réseau est actif, faites preuve de prudence et comprenez parfaitement les implications potentielles de toute commande avant de continuer.
La plupart des appliances Secure Malware Analytics se connectent à Internet et utilisent le processus de mise à jour en ligne. Cependant, certains appareils sont maintenus strictement au sein des réseaux internes (entrefer). Cisco ne recommande pas cette approche car elle réduit l'efficacité. Ce guide décrit le processus de mise à jour hors ligne pour les personnes qui doivent entretenir des appareils à air libre.
Pour les mises à jour Secure Malware Analytics hors ligne, Cisco fournit des supports de mise à jour sur demande. Suivez le processus de mise à jour hors connexion décrit dans ce document.
Support : le support de mise à jour Airgap (hors ligne) est fourni sur demande par le support Secure Malware Analytics. Il s'agit d'un fichier ISO qui peut être copié sur un lecteur USB ou un disque dur (avec une taille suffisante).
Taille :La taille du support de mise à jour varie en fonction des versions prises en charge et peut augmenter considérablement avec l'introduction de nouvelles machines virtuelles. Pour les versions actuelles, sa taille est d'environ 30 Go, outil de désynchronisation inclus, qui permet des mises à jour incrémentielles pour les modifications liées aux VM.
Cycle de démarrage de la mise à niveau : chaque fois que le support de mise à jour airgap est amorcé, il détermine la version suivante vers laquelle effectuer la mise à niveau et copie le contenu associé à cette version suivante sur l'appliance. Une version donnée peut également lancer l'installation d'un package si cette version ne comporte aucune vérification préalable qui doit être exécutée pendant l'exécution de l'appliance. Si la version inclut de telles vérifications ou un remplacement des parties du processus de mise à jour qui pourraient ajouter de telles vérifications, alors la mise à jour ne s'applique pas réellement jusqu'à ce que l'utilisateur se connecte à OpAdmin et appelle la mise à jour avec OpAdmin > Operations > Update Appliance.
Crochets de pré-installation : selon la présence de crochets de pré-installation pour cette mise à niveau spécifique, il exécute la mise à niveau immédiatement ou redémarre l'appliance en mode de fonctionnement normal pour permettre à l'utilisateur d'accéder à l'interface d'administration habituelle et de démarrer cette mise à niveau manuellement.
Répéter selon les besoins : chaque cycle d'amorçage du support ne met à niveau (ou ne prépare la mise à niveau) qu'une seule étape vers la version cible finale ; l'utilisateur doit amorcer autant de fois que nécessaire pour effectuer la mise à niveau vers la version de destination souhaitée.
Le support CIMC n'est pas pris en charge pour les mises à jour à intervalle d'air.
En raison des contraintes de licence sur les composants tiers utilisés, les supports de mise à niveau pour les versions 1.x ne sont plus disponibles après la fin de vie du matériel UCS M3. Il est donc essentiel que les appliances UCS M3 soient remplacées ou mises à niveau avant la fin de vie.
Migrations : si les notes de version des versions couvertes incluent des scénarios dans lesquels la migration doit obligatoirement avoir lieu avant l'installation de la version suivante, l'utilisateur doit suivre ces étapes avant de redémarrer à nouveau pour éviter de mettre son appliance dans un état inutilisable.
Remarque : la première version 2.1.x plus récente que 2.1.4, en particulier, exécute plusieurs migrations de base de données. Il n'est pas sûr de continuer tant que ces migrations ne sont pas terminées. Pour plus d'informations, consultez la note de migration de Threat Grid Appliance 2.1.5.
Si la mise à niveau d'airgap débute avec une version antérieure à la version 2.1.3, elle utilise une clé de cryptage dérivée de la licence individuelle et doit donc être personnalisée par appliance. (Le seul effet visible par l'utilisateur est qu'avec les supports conçus pour prendre en charge les versions d'origine antérieures à la version 2.1.3, Secure Malware Analytics a besoin des licences installées sur ces appareils au préalable, et les supports ne fonctionneront sur aucun appareil ne figurant pas dans la liste pour laquelle ils ont été créés.)
Si vous commencez avec la version 2.1.3 ou une version ultérieure, le support airgap est générique et aucune information client n'est nécessaire.
Première vérification de la version Air Gapped disponible sur cette page : Tableau de recherche des versions des appareils
1. Ouvrez une demande d'assistance TAC pour obtenir le support de mise à jour hors ligne. Cette demande doit inclure le numéro de série de l'appliance ainsi que le numéro de version de l'appliance.
2. L'assistance TAC fournit un ISO mis à jour en fonction de votre installation.
3. Gravez l'image ISO sur un USB amorçable. Notez que USB est le seul périphérique/méthode pris en charge pour les mises à jour hors connexion.
Il s'agit du nom de fichier mis à jour ex : TGA Airgap Update 2.16.2-2.17.2.
Cela signifie que ce support peut être utilisé pour une appliance exécutant une version minimale : 2.16.2 et mettre à niveau l'appliance vers la version : 2.17.2.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations de ce document sont basées sur un système d'exploitation Linux (par exemple : CentOS, RedHat).
Les informations contenues dans ce document sont basées sur des périphériques dans un environnement de travaux pratiques contrôlé avec des configurations par défaut. Si votre réseau est actif, faites preuve de prudence et comprenez parfaitement les implications potentielles de toute commande avant de continuer.
Installer le langage de programmation 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
Exécutez ces trois commandes après l'installation, sinon la commande desync échoue
# export GOROOT=/usr/local/go
# export GOPATH=$HOME/Projects/Proj1
# export PATH=$GOPATH/bin:$GOROOT/bin:$PATH
Vous pouvez vérifier la version GO en procédant comme suit :
# go version
Étape 1. Copiez le contenu du fichier Zip fourni par Secure Malware Analytics Support, y compris les fichiers desync.linux et .caibx dans le même répertoire localement sur la machine.
Étape 2. Accédez au répertoire dans lequel vous avez stocké les fichiers :
Exemple :
# cd MyDirectory/TG
Étape 3. Exécutez la commande pwd pour vous assurer que vous êtes à l'intérieur du répertoire.
# pwd
Étape 4. Une fois que vous êtes à l'intérieur du répertoire qui inclut la commande desync.linux et le fichier .caibx, exécutez la commande de votre choix pour commencer le processus de téléchargement.
Remarque : voici des exemples pour différentes versions ISO. Veuillez vous référer au fichier .caibx à partir des instructions fournies par le support Secure Malware Analytics.
Pour les versions 2.16.2 à 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
Pour les versions 2.4.3.2 à 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
Pour les versions 2.5 à 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
Une fois le téléchargement démarré, une barre de progression s'affiche.
Remarque : la vitesse de téléchargement et la taille du support de mise à niveau dans votre environnement peuvent avoir un impact sur le temps de composition de l'ISO.
Assurez-vous de comparer le MD5 du fichier téléchargé à celui disponible avec le bundle fourni par le support pour faire valider l'intégrité de l'ISO téléchargé.
Une fois le téléchargement terminé, les fichiers ISO sont créés dans le même répertoire.
Branchez l'USB sur la machine et exécutez la commande dd pour créer le lecteur USB amorçable.
# dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M
Où <MY_USB> est le nom de votre clé USB (ne tenez pas compte des crochets).
Insérez le lecteur USB et mettez sous tension ou redémarrez le périphérique. Dans l'écran de démarrage de Cisco, appuyez sur F6 pour entrer dans le menu de démarrage.
Conseil :
Exécutez le téléchargement après les heures de bureau ou les heures creuses car cela peut affecter la bande passante.
Pour arrêter l'outil, fermez le terminal ou appuyez sur Ctrl+c/Ctrl+z.
Pour continuer, exécutez la même commande pour reprendre le téléchargement.
Installer le langage de programmation GO
Fermez et rouvrez la commande CMD run pour vérifier :
go version
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
Note : Si la commande git ne fonctionne pas, vous pouvez télécharger et installer Git à partir d'ici : https://git-scm.com/download/win.
Exécutez ensuite les deux commandes ci-dessous une par une :
cd desync/cmd/desync
go install
\$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
Pour créer cette récupération spécifique USB, il est crucial d'utiliser Rufus version 2.17, car il vous permet d'utiliser des options d'ajout essentielles. Vous pouvez trouver toutes les versions de RUFUS dans ce référentiel.
Le support de mise à jour détermine la version suivante dans le chemin de mise à niveau et copie le contenu de cette version sur l'appliance. La solution matérielle-logicielle exécute la mise à niveau immédiatement ou redémarre en mode de fonctionnement normal pour vous permettre d'entrer dans OpAdmin et de démarrer cette mise à niveau manuellement.
Une fois le processus de démarrage ISO terminé, redémarrez l'appliance Secure Malware Analytics en mode de fonctionnement.
Connectez-vous à l'interface utilisateur du portail et vérifiez si des avertissements indiquent que la mise à niveau est sans danger, etc., avant de continuer.
L'USB n'étant toujours pas connecté au terminal, exécutez la commande « 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$
Une fois la clé USB branchée.
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$
Ceci confirme que le périphérique USB dans /dev est "/dev/sdb".
Autres moyens de confirmer, après la connexion de la clé USB :
La commande dmesg fournit des informations. Une fois l'USB connecté, exécutez la commande dmesg | grep -iE 'usb|attached'.
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$
La commande fidsk fournit des informations sur la taille, qui peuvent être utilisées pour confirmer : 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$
Remarque : N'oubliez pas de démonter l'USB avant d'exécuter la commande « dd ».
Confirmez que le périphérique USB de l'exemple est monté.
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]
Pour démonter le périphérique USB, utilisez sudo umount /dev/sdb1.
xsilenc3x@Alien15:~/testarea/usb$ sudo umount /dev/sdb1
Vérifiez à nouveau que le périphérique n'est pas considéré comme « monté ».
xsilenc3x@Alien15:~/testarea/usb$ sudo mount -l | grep -i sdb
oflag=sync et status=progress dans la commande dd.
Lors de l'écriture de nombreux blocs de données, l'option "status=progress" fournit des informations sur les opérations d'écriture en cours. Ceci est utile pour confirmer si la commande "dd" est en cours d'écriture dans le cache de page ; elle peut être utilisée pour afficher la progression et le temps complet en secondes de toutes les opérations d'écriture.
Lorsqu'il n'est pas utilisé, "dd" ne fournit pas d'informations sur la progression, seuls les résultats des opérations d'écriture sont fournis avant que "dd" ne retourne :
[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]$
Lorsqu'elles sont utilisées, les informations en temps réel sur les opérations d'écriture sont mises à jour toutes les secondes.
[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]
Remarque : dans la documentation officielle du processus de mise à niveau hors ligne TGA, la commande indiquée est : dd if=airgap-update.iso of=/dev/<MY_USB> bs=64M
Après quelques tests, on observe l'exemple suivant.
Une fois qu'un fichier de 10 Mo est créé avec "dd" en utilisant le périphérique /dev/zero.
1M x 10 = 10M (10240 kB + données système précédentes dans les caches de pages de fichiers sales = 10304 kB —> c'est ce qui est perçu dans le cache de pages sales à la fin 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
Remarque : une fois la commande « dd » renvoyée, l'opération d'écriture sur le périphérique de blocage n'a pas été terminée, elle a été perçue 11 secondes après le retour.
Si c'était la commande "dd" lors de la création de l'USB amorçable avec le TGA ISO, ET j'avais retiré l'USB du point d'extrémité avant ces 11 secondes = J'aurais un ISO corrompu dans l'USB amorçable.
Explication:
Les périphériques de type bloc fournissent un accès en mémoire tampon aux périphériques matériels. Cela fournit une couche d'abstraction aux applications lors de l'utilisation de périphériques matériels.
Les périphériques de bloc permettent à une application de lire/écrire par blocs de données de tailles différentes ; cette fonction read()/write() est appliquée sur les caches de page (tampons) et non directement sur le périphérique de bloc.
Le noyau ( et non l'application effectuant la lecture/écriture ) gère le mouvement des données des tampons (caches de pages) vers les unités de bloc.
Par conséquent :
L'application (en l'occurrence "dd") n'a pas le contrôle du vidage des tampons si elle n'est pas chargée de le faire.
L'option "oflag=sync" force l'écriture physique synchrone (par le noyau) après que chaque bloc de sortie (fourni par "dd") est placé dans le cache de page.
oflag=sync dégrade les performances "dd" par rapport à la non-utilisation de l'option ; mais, si elle est activée, elle assure une écriture physique sur le périphérique bloc après chaque appel write() de "dd".
Test : L'utilisation de l'option "oflag=sync" de la commande "dd" pour confirmer toutes les opérations d'écriture avec les données du cache de page sale a été effectuée au retour de la commande "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]$
Il ne reste aucune donnée de l'opération d'écriture dans le cache des pages modifiées.
L'opération d'écriture a été appliquée avant (ou au même instant) le retour de la commande "dd" (pas 11 secondes après comme le test précédent).
Maintenant, je suis sûr qu'après le retour de la commande "dd" il n'y avait aucune donnée dans le cache de la page sale liée à l'opération d'écriture = aucun problème dans la création USB amorçable (si la somme de contrôle ISO est correcte).
Remarque : tenez compte de cet indicateur (oflag=sync) de la commande "dd" lorsque vous travaillez sur ce type de cas.
Nous devons nous assurer que le disque dur est formaté à l'aide de l'option « DD » à l'aide de n'importe quel outil disponible et que le support doit être copié par la suite sur le lecteur. Si nous n'utilisons pas cette mise en forme, nous ne pourrons pas lire ce média.
Une fois que le support est chargé sur le disque dur/l'unité USB à l'aide du formatage « DD », nous devons le connecter à l'appliance TGA et redémarrer le périphérique.
Il s'agit de l'écran de sélection du menu de démarrage par défaut. Nous devons appuyer sur « F6 » pour démarrer le périphérique et sélectionner le média de démarrage
Une fois que le périphérique reconnaît notre entrée, il vous invite à entrer dans le menu de sélection du démarrage.
Il s'agit de l'invite qui peut différer entre les différents modèles TGA. Idéalement, nous verrions l'option de démarrage à l'aide du média de démarrage (upgrade filesystem) à partir de ce menu lui-même, mais s'il n'est pas vu, nous devons nous connecter au « shell EFI ».
Vous devez appuyer sur « ESC » avant que le script « startup.sh » ne se termine pour accéder à l'environnement de ligne de commande EFI. Une fois que nous nous connectons au shell EFI, nous remarquons que les partitions détectées dans ce cas sont 3 systèmes de fichiers : fs0:, fs1:, fs2.
Identification du système de fichiers approprié :
En cas de systèmes de fichiers manquants :
Afin de démarrer le périphérique dans le support de démarrage (système de fichiers de mise à niveau), nous devons exécuter le fichier « bootx64.efi » :
fs0:\efi\boot\bootx64.efi
Pour référence, nous avons affiché le contenu des autres systèmes de fichiers ainsi que ci-dessous :
fs1 : il s'agit du système de fichiers de démarrage principal.
fs2 : il s'agit du système de fichiers de démarrage de l'image de récupération.
Pour vérifier le système de fichiers correct qui contient le support de démarrage monté. Nous pouvons le faire en parcourant les différents systèmes de fichiers et en vérifiant le fichier de démarrage « .efi »
Remarque : la séquence du support de démarrage réel (système de fichiers de mise à niveau), dans ce cas « fs0: », peut également varier avec d'autres périphériques.
Le nom et le chemin peuvent varier, mais dans toutes les images modernes, cela devrait être le même.
Liste de contrôle permettant de localiser le support de démarrage approprié (système de fichiers de mise à niveau) :
Programme d'installation sur site SMA 2.19.2
Pour les appareils SMA endommagés et/ou en réparation, utilisez le programme d'installation sur site pour réinstaller le logiciel SMA. Veuillez noter que ce forfait spécial est destiné UNIQUEMENT à des fins de RÉCUPÉRATION. Son utilisation pour une mise à niveau peut entraîner une perte de données irréversible.
Récupération
En cas de récupération lorsque les TGA sont bloqués et une fois que GATE fournit cette image spéciale, nous devons utiliser une version spécifique d'un logiciel bien connu appelé RUFUS. RUFUS est largement utilisé pour créer des USB amorçables. Dans le cas de cette image spécifique, nous devons utiliser RUFUS version 2.17. Ceci est très important pour utiliser la version 2.17. Il s'agit de la dernière version où vous pouvez utiliser des options d'ajout qui est très important dans la création de cette récupération USB spécifique. Vous pouvez trouver toutes les versions de ce référentiel Rufus référentiel au cas où ces fichiers ne sont plus disponibles Je incluent également des installateurs pour les versions complètes et portables dans ce document.
Mot de passe pour RUFUS_217.zip
Remarque spéciale pour la mise à jour Airgap TGA ISO hors ligne 2.x-2.12.3ag2 MUST_RESET [airgap-update-MUST_RESET-2.12.3ag2]
Si vous utilisez la mise à jour TGA Airgap 2.x-2.12.3ag2 MUST_RESET pour mettre à niveau des appareils qui sont plus anciens que 2.11.x, vous DEVEZ RÉINITIALISER les données [données-destruction] pour que la mise à niveau fonctionne correctement.
Ce support de mise à niveau airgap est un support unique construit pour permettre des mises à niveau de versions 2.x même très anciennes directement vers 2.12.3ag2 ; il est spécifiquement testé pour fonctionner avec 2.2.3 et 2.5 comme versions de départ : les versions plus récentes que la version précédente sont très susceptibles de fonctionner ; les versions plus anciennes que la version précédente (mais plus récentes que la version 2.0) peuvent fonctionner de manière plausible.
- Les mises à niveau à partir d'une version antérieure à 2.11.x nécessitent une réinitialisation des données pour fonctionner correctement. En effet, le processus de mise à niveau normal implique des migrations de données qui ne sont plus incluses au-delà de la version mineure suivante. Pour la même raison, les sauvegardes créées sur une version antérieure à 2.11.x peuvent ne pas être restaurables sur la build installée par ce support ou peuvent provoquer un comportement défectueux après avoir été restaurées.
- Si vous effectuez une mise à niveau à partir d'une version utilisant `/sandcastle` plutôt que `/data` pour le stockage en masse (c'est-à-dire une version antérieure à 2.7), il peut y avoir une panne de démarrage transitoire et unique après l'installation de cette version. L'état du système lorsque cela se produit est tel qu'indiqué dans le fichier nommé `airgap-update-MUST_RESET-2.12.3ag2-filesystem-rename-hang-screenshot.png` dans le même répertoire que ce fichier README. Lorsque cet écran est affiché pendant plus de 15 secondes sans modification, vous pouvez redémarrer le système en toute sécurité.
Révision | Date de publication | Commentaires |
---|---|---|
3.0 |
18-Sep-2024 |
Les instructions ont été mises à jour dans ce document |
2.0 |
09-Nov-2021 |
Première publication |
1.0 |
08-Nov-2021 |
Première publication |