Elastic Compute Service:Problèmes connus liés aux images publiques

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:\Users\Administrator> Get-PhysicalDisk | Select-Object FriendlyName, MediaType

FriendlyName    MediaType
------------    ---------
Red Hat VirtIO Unspecified

PS C:\Users\Administrator>

CentOS 8.0 : Problème de dénomination de l'image publique

Symptômes : Après avoir créé une instance CentOS à l'aide de l'image publique centos_8_0_x64_20G_alibase_20200218.vhd, vous vous connectez à l'instance et constatez que la version du système est CentOS 8.1.

testuser@ecshost:~$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID:    CentOS
Description:    CentOS Linux version 8.1.1911 (Core)
Version:    8.1.1911
Codename:    Core

Cause : Cette image publique a été mise à jour avec les derniers paquets communautaires, ce qui a entraîné la mise à niveau de sa version vers la 8.1.

ID d'image concerné : centos_8_0_x64_20G_alibase_20200218.vhd.

Solution : Si vous avez besoin de CentOS 8.0, appelez l'opération API et définissez le paramètre ImageId sur centos_8_0_x64_20G_alibase_20191225.vhd pour créer une instance ECS.

CentOS 7 : Problèmes liés aux modifications des ID d'image

Symptômes : Les ID de certaines images publiques CentOS 7 ont changé. Cette modification peut affecter les processus automatisés qui dépendent d'ID d'image spécifiques.

Images concernées : CentOS 7.5 et CentOS 7.6

Cause : Les dernières versions des images publiques CentOS 7.5 et CentOS 7.6 utilisent le format d'ID d'image %OS_Type%_%Major_Version%_%Minor_Version%_%Special_Field%_alibase_%Date%.%Format%. Par exemple, le préfixe de l'ID d'image pour CentOS 7.5 est passé de centos_7_05_64 à centos_7_5_x64. Vous devez ajuster vos politiques d'exploitation et de maintenance automatisées en conséquence. Pour plus d'informations sur les ID d'image, consultez les Notes de version pour 2023.

CentOS 7 : Modification de la casse du nom d'hôte après redémarrage

Symptômes : Sur certaines instances CentOS 7, les lettres majuscules contenues dans un nom d'hôte sont converties en minuscules après le premier redémarrage.

Images concernées : Les images publiques CentOS suivantes ainsi que toutes les images personnalisées créées à partir de celles-ci.

• centos_7_2_64_40G_base_20170222.vhd

• centos_7_3_64_40G_base_20170322.vhd

• centos_7_03_64_40G_alibase_20170503.vhd

• centos_7_03_64_40G_alibase_20170523.vhd

• centos_7_03_64_40G_alibase_20170625.vhd

• centos_7_03_64_40G_alibase_20170710.vhd

• centos_7_02_64_20G_alibase_20170818.vhd

• centos_7_03_64_20G_alibase_20170818.vhd

• centos_7_04_64_20G_alibase_201701015.vhd

  Applications concernées : Si votre application est sensible à la casse du nom d'hôte, ses services peuvent être affectés par un redémarrage de l'instance. Utilisez le tableau suivant pour déterminer si vous êtes concerné.

Solution : Pour conserver les lettres majuscules dans le nom d'hôte après un redémarrage, suivez les étapes ci-dessous.

1. Connectez-vous à distance à l'instance.

   Pour plus d'informations, consultez les Méthodes de connexion.

2. Consultez le nom d'hôte actuel.

   [testuser@izbp193*3i161uynzzx ~]# hostname
   izbp193*3i161uynzzx

3. Exécutez la commande suivante pour rendre le nom d'hôte persistant.

   hostnamectl set-hostname --static iZbp193*3i161uynzzX

4. Exécutez la commande suivante pour consulter le nom d'hôte mis à jour.

   [testuser@izbp193*3i161uynzzx ~]# hostname
   iZbp193*3i161uynzzX

   Étapes suivantes : Si vous utilisez une image personnalisée, mettez à jour cloud-init vers la dernière version, puis créez une nouvelle image personnalisée. Cela permet d'éviter que le problème ne se produise sur les nouvelles instances créées à partir de l'image. Pour plus d'informations, consultez Installer cloud-init et Créer une image personnalisée à partir d'une instance.

CentOS 6.8 : Plantage de l'instance cliente NFS

Symptômes : Une instance CentOS 6.8 avec le client NFS chargé peut se bloquer, nécessitant un redémarrage pour récupérer.

Cause : Lorsque vous utilisez le service NFS avec une version du noyau comprise entre 2.6.32-696 et 2.6.32-696.10, le module nfsclient du noyau interrompt proactivement la connexion TCP en cas de latence de communication. Si le serveur NFS répond lentement, la connexion initiée par le nfsclient peut rester bloquée dans l'état FIN_WAIT2. Normalement, une connexion dans l'état FIN_WAIT2 expire et est libérée après une minute, permettant au nfsclient de rétablir la connexion. Toutefois, en raison d'un défaut dans l'implémentation TCP de ces versions du noyau, la connexion dans l'état FIN_WAIT2 n'expire jamais. Par conséquent, la connexion TCP du nfsclient ne peut jamais être fermée, ce qui bloque les nouvelles connexions et fige indéfiniment les requêtes utilisateur. Le redémarrage de l'instance ECS constitue la seule méthode de récupération.

ID d'images concernés : centos_6_08_32_40G_alibase_20170710.vhd et centos_6_08_64_20G_alibase_20170824.vhd.

Solution : Exécutez la commande yum update pour mettre à niveau le noyau du système vers la version 2.6.32-696.11 ou ultérieure.

Noyau Ubuntu 5.15 : Le débranchement à chaud d'un disque déclenche une tâche bloquée

Symptômes : Lors du débranchement à chaud d'un disque depuis une instance exécutant la version 5.15.0-144-generic du noyau Ubuntu, une tâche bloquée peut être déclenchée de manière intermittente avec un délai d'expiration d'environ 120 secondes. Les processus couramment bloqués incluent :

• kworker (thread de branchement à chaud ACPI)

• udev-worker (processus de gestion des événements de périphérique)

  Cause : Ce problème est dû à un défaut logique dans la fonction del_gendisk() du noyau. Une condition de concurrence entre le gel de la file d'attente et la libération de la référence sysfs conduit à un interblocage ABBA.

• Le processus kworker détient le verrou de gel de la file d'attente et attend la libération de la référence sysfs.

• Le processus udev-worker détient la référence sysfs et attend que la file d'attente soit dégélée ou qu'elle se termine.

  Étant donné que le noyau ne définit pas l'indicateur QUEUE_FLAG_DYING, la fonction blk_queue_enter() ne peut pas se terminer, ce qui entraîne un interblocage.

Solution :

• Méthode 1 : Mettre à niveau le noyau (recommandé)

  Effectuez la mise à niveau vers une version du noyau incluant le correctif (5,19 ou ultérieure, ou un noyau de distribution incluant le patch).

• Méthode 2 : Appliquer un patch (solution temporaire)

  Dans le noyau 5,15, modifiez la fonction del_gendisk() en remplaçant blk_queue_start_drain(q); par blk_set_queue_dying(q);. Cette modification définit l'indicateur QUEUE_FLAG_DYING, ce qui permet aux requêtes d'E/S en attente de se terminer rapidement et évite l'interblocage.

Les instances Ubuntu 24.04 affectées par CVE-2024-57843 peuvent rencontrer des paniques du noyau ou une corruption de la mémoire

• Symptômes : CVE-2024-57843 est un dépassement de page croisée de 16 octets qui se produit lorsque le pilote virtio-net remplit les tampons RX fusionnables. Dans certaines conditions spécifiques, telles qu'une MTU de 4084 ou supérieure, les instances Ubuntu 24.04 LTS peuvent subir une panique du noyau, échouer lors du transfert de fichiers volumineux ou corrompre silencieusement les structures de données du noyau.

• Portée de l'impact et solution : Pour plus d'informations, consultez Impact et correction de CVE-2024-57843 pour les images officielles ECS.

Les instances CentOS Stream 9 affectées par CVE-2024-57843 peuvent rencontrer des paniques du noyau ou une corruption de la mémoire

• Symptômes : CVE-2024-57843 est un dépassement de page croisée de 16 octets qui se produit lorsque le pilote virtio-net remplit les tampons RX fusionnables. Dans certaines conditions spécifiques, telles qu'une MTU de 4084 ou supérieure, les instances CentOS Stream 9 peuvent subir une panique du noyau, échouer lors du transfert de fichiers volumineux ou corrompre silencieusement les structures de données du noyau.

• Portée de l'impact et solution : Pour plus d'informations, consultez Impact et correction de CVE-2024-57843 pour les images officielles ECS.

Les instances Fedora 40 affectées par CVE-2024-57843 peuvent rencontrer des paniques du noyau ou une corruption de la mémoire

• Symptômes : CVE-2024-57843 est un dépassement de page croisée de 16 octets qui se produit lorsque le pilote virtio-net remplit les tampons RX fusionnables. Dans certaines conditions spécifiques, telles qu'une MTU de 4084 ou supérieure, les instances Fedora 40 peuvent subir une panique du noyau, échouer lors du transfert de fichiers volumineux ou corrompre silencieusement les structures de données du noyau. Fedora 40 a atteint sa fin de vie (EOL). Nous vous recommandons de migrer vers Fedora 41 ou une version ultérieure.

• Portée de l'impact et solution : Pour plus d'informations, consultez Impact et correction de CVE-2024-57843 pour les images officielles ECS.

Fedora CoreOS : Le nom d'hôte n'est pas appliqué depuis les images personnalisées

Symptômes : Lorsque vous créez une instance ECS (instance B) à partir d'une image personnalisée créée depuis une autre instance Fedora CoreOS (instance A), le nouveau nom d'hôte spécifié pour l'instance B n'est pas appliqué. L'instance B conserve le nom d'hôte de l'instance A.

Par exemple, vous disposez d'une instance ECS (instance A) exécutant le système d'exploitation Fedora CoreOS et portant le nom d'hôte test001. Vous utilisez ensuite une image personnalisée issue de cette instance pour créer une nouvelle instance ECS (instance B). Lors du processus de création, vous définissez le nom d'hôte de instance B sur test002. Après avoir créé et vous être connecté à distance à instance B, le nom d'hôte de instance B reste test001.

Cause : Les images publiques Fedora CoreOS fournies par Alibaba Cloud utilisent le service Ignition officiel pour l'initialisation de l'instance. Ignition est un utilitaire utilisé par Fedora CoreOS et Red Hat Enterprise Linux CoreOS pour manipuler les disques pendant la phase initramfs du démarrage du système. Lorsqu'une instance ECS démarre pour la première fois, le service coreos-ignition-firstboot-complete.service d'Ignition vérifie l'existence du fichier /boot/ignition.firstboot pour déterminer s'il doit initialiser l'instance. Si ce fichier vide existe, Ignition procède à l'initialisation, qui inclut la configuration du nom d'hôte, puis supprime le fichier /boot/ignition.firstboot.

Étant donné que l'instance Fedora CoreOS d'origine a été démarrée au moins une fois, le fichier /boot/ignition.firstboot n'est plus présent dans l'image personnalisée. Lorsque vous utilisez cette image personnalisée pour créer une nouvelle instance ECS, Ignition n'exécute pas le processus d'initialisation au premier démarrage et le nouveau nom d'hôte n'est pas appliqué.

Solution :

Avant de créer une image personnalisée à partir d'une instance Fedora CoreOS, utilisez les permissions root pour créer le fichier /ignition.firstboot dans le répertoire /boot :

1. Remontez /boot en mode lecture-écriture.

   sudo mount /boot -o rw,remount

2. Créez le fichier /ignition.firstboot.

   sudo touch /boot/ignition.firstboot

3. Remontez /boot en mode lecture seule.

   sudo mount /boot -o ro,remount

   Spécification de configuration Ignition.

OpenSUSE 15 : Blocage au démarrage après la mise à jour du noyau

Symptômes : Après la mise à niveau du noyau OpenSUSE vers la version 4.12.14-lp151.28.52-default, une instance peut se bloquer au démarrage sur certains types de CPU. Le type de CPU connu comme étant affecté est Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz. Voici la trace d'appel :

[    0.901281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.901281] CR2: ffffc90000d68000 CR3: 000000000200a001 CR4: 00000000003606e0
[    0.901281] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.901281] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.901281] Call Trace:
[    0.901281]  cpuidle_enter_state+0x6f/0x2e0
[    0.901281]  do_idle+0x183/0x1e0
[    0.901281]  cpu_startup_entry+0x5d/0x60
[    0.901281]  start_secondary+0x1b0/0x200
[    0.901281]  secondary_startup_64+0xa5/0xb0
[    0.901281] Code: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 90 31 d2 65 48 8b 34 25 40 6c 01 00 48 89 d1 48 89 f0 <0f> 01 c8 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00  

Cause : La nouvelle version du noyau est incompatible avec le microcode du CPU. Pour plus d'informations, consultez Bug 1162092.

Image concernée : opensuse_15_1_x64_20G_alibase_20200520.vhd.

Solution : Dans le fichier /boot/grub2/grub.cfg, ajoutez le paramètre de noyau idle=nomwait à la ligne commençant par linux. Voici un exemple de modification :

menuentry 'openSUSE Leap 15.1'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-20f5f35a-fbab-4c9c-8532-bb6c66ce' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  20f5f35a-fbab-4c9c-8532-bb6c66ce
        else
          search --no-floppy --fs-uuid --set=root 20f5f35a-fbab-4c9c-8532-bb6c66ce
        fi
        echo    'Loading Linux 4.12.14-lp151.28.52-default ...'
        linux   /boot/vmlinuz-4.12.14-lp151.28.52-default root=UUID=20f5f35a-fbab-4c9c-8532-bb6c66ce  net.ifnames=0 console=tty0 console=ttyS0,115200n8 splash=silent mitigations=auto quiet idle=nomwait
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-4.12.14-lp151.28.52-default
}

Red Hat Enterprise Linux 8 : Échec de la mise à jour du noyau

Symptômes : Sur une instance ECS Red Hat Enterprise Linux 8 64 bits, vous exécutez la commande yum update pour mettre à jour le noyau, puis redémarrez l'instance. Après le redémarrage, vous constatez que la version du noyau n'a pas changé.

Cause : Dans Red Hat Enterprise Linux 8 64 bits, le fichier /boot/grub2/grubenv qui stocke les variables d'environnement GRUB2 présente une taille anormale. Le fichier ne fait pas la taille standard de 1 024 octets, ce qui entraîne l'échec de la mise à jour du noyau.

Résolution : Après la mise à jour du noyau, vous devez définir manuellement la nouvelle version comme version de démarrage par défaut. Suivez ces étapes :

1. Mettez à jour le noyau.

   yum update kernel -y

2. Récupérez les paramètres de démarrage du noyau du système d'exploitation actuel.

   grub2-editenv list | grep kernelopts

3. Sauvegardez l'ancien fichier /grubenv.

   mv /boot/grub2/grubenv /home/grubenv.bak

4. Générez un nouveau fichier /grubenv.

   grub2-editenv /boot/grub2/grubenv create

5. Définissez la nouvelle version du noyau comme version de démarrage par défaut.

   Dans cet exemple, la version du noyau mise à jour est /boot/vmlinuz-4.18.0-305.19.1.el8_4.x86_64.

   grubby --set-default /boot/vmlinuz-4.18.0-305.19.1.el8_4.x86_64

6. Définissez les paramètres de démarrage du noyau.

   Définissez le paramètre kernelopts avec la valeur obtenue à l'étape 2.

   grub2-editenv - set kernelopts="root=UUID=0dd6268d-9bde-40e1-b010-0d3574b4 ro crashkernel=auto net.ifnames=0 vga=792 console=tty0 console=ttyS0,115200n8 noibrs nosmt"

7. Redémarrez l'instance ECS pour démarrer sur le nouveau noyau.

   reboot

   Avertissement

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

   L'opération de redémarrage arrête l'instance pendant une courte période et peut interrompre les services en cours d'exécution sur l'instance. Nous vous recommandons de redémarrer l'instance pendant les heures creuses.

SUSE Linux Enterprise Server : Échec de la connexion au serveur SMT

Symptômes : Lorsque vous utilisez une image payante SUSE Linux Enterprise Server ou SUSE Linux Enterprise Server for SAP, vous pouvez rencontrer des délais d'expiration de connexion ou d'autres problèmes avec le serveur Subscription Management Tool (SMT). Lorsque vous tentez de télécharger ou de mettre à jour des composants, un message d'erreur similaire à l'un des suivants s'affiche :

• Registration server returned 'This server could not verify that you are authorized to access this service.' (500)

• Problem retrieving the repository index file for service 'SMT-http_mirrors_cloud_aliyuncs_com' location

  Images concernées : SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP

Résolution : Vous devez réenregistrer et activer le service SMT.

1. Exécutez les commandes suivantes dans l'ordre pour réenregistrer et activer le service SMT.

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. Exécutez la commande suivante pour vérifier l'état d'activation du service SMT.

   SUSEConnect -s

   [{"identifier":"SLES_SAP","version":"12.5","arch":"x86_64","status":"Registered"}]

SUSE Linux Enterprise Server 12 SP5 : Blocage au démarrage après la mise à jour du noyau

SymptômesIntel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHzIntel(R) Xeon(R) CPU E7-8880 v4 @ 2.20GHz

[    0.901281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.901281] CR2: ffffc90000d68000 CR3: 000000000200a001 CR4: 00000000003606e0
[    0.901281] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    0.901281] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    0.901281] Call Trace:
[    0.901281]  cpuidle_enter_state+0x6f/0x2e0
[    0.901281]  do_idle+0x183/0x1e0
[    0.901281]  cpu_startup_entry+0x5d/0x60
[    0.901281]  start_secondary+0x1b0/0x200
[    0.901281]  secondary_startup_64+0xa5/0xb0
[    0.901281] Code: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00 90 31 d2 65 48 8b 34 25 40 6c 01 00 48 89 d1 48 89 f0 <0f> 01 c8 0f 1f 84 00 00 00 00 00 0f 1f 84 00 00 00 00 00  

Cause : La nouvelle version du noyau est incompatible avec le microcode du processeur.

Résolution : Dans le fichier /boot/grub2/grub.cfg, ajoutez le paramètre de noyau idle=nomwait à la ligne commençant par linux. Voici un exemple du fichier modifié :

menuentry 'SLES 12-SP5'  --class sles --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-fd7bda55-42d3-4fe9-a2b0-45efdced' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd0,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  fd7bda55-42d3-4fe9-a2b0-45efdced
        else
          search --no-floppy --fs-uuid --set=root fd7bda55-42d3-4fe9-a2b0-45efdced
        fi
        echo    'Loading Linux 4.12.14-122.26-default ...'
        linux   /boot/vmlinuz-4.12.14-122.26-default root=UUID=fd7bda55-42d3-4fe9-a2b0-45efdced  net.ifnames=0 console=tty0 console=ttyS0,115200n8 mitigations=auto splash=silent quiet showopts idle=nomwait
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-4.12.14-122.26-default
}

AnolisOS 8.9 RHCK : Échec du démarrage sur les instances ecs.ebmc8i et ecs.ebmg8i

Symptômes : En raison d'un problème de compatibilité entre AnolisOS 8.9 RHCK et Intel QAT, le système plante lors du démarrage sur les instances ecs.ebmc8i et ecs.ebmg8i. Si vous devez utiliser AnolisOS 8 RHCK sur ces types d'instances, nous vous recommandons d'utiliser AnolisOS 8.10 RHCK.

Voici un exemple du journal de plantage du noyau déclenché lors du démarrage :

[   31.165923] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
[   31.174877] PGD 80a74ee067 P4D 0
[   31.178620] Oops: 0000 [#1] SMP NOPTI
[   31.182761] CPU: 134 PID: 2746 Comm: systemd-udevd Not tainted 4.18.0-513.18.1.0.1.an8.x86_64 #1
[   31.192672] Hardware name: Alibaba Alibaba Cloud ECS/Alibaba Cloud ECS, BIOS 3.0.ES.AL.P.087.05 04/07/2024
[   31.192673] RIP: 0010:qat_rsa_exit_tfm+0x14/0x40 [intel_qat]
[   31.209951] Code: 00 c7 83 80 00 00 00 00 00 00 00 5b 5d 41 5c 41 5d c3 cc cc cc cc 0f 1f 44 00 00 53 48 8b 87 c5 00

[   31.209952] RSP: 0018:ff5c35909f277ab8 EFLAGS: 00010282
[   31.209954] RAX: 0000000000000000 RBX: ff2aa603110ee100 RCX: 0000000000000091
[   31.209955] RDX: 0000000000000090 RSI: ff2aa603110ee140 RDI: ff2aa603110ee100
[   31.209956] RBP: ff2aa603110ee100 R08: ff5c35909f277a88 R09: ff2aa603110ee000
[   31.209957] R10: 0000000000000000 R11: 000000000006000c0 R12: ff2aa603110ee100
[   31.255995] 4xxx 0001:ed:00.0: qat_dev1 started 9 acceleration engines
[   31.261146] R13: ff2aa603110ee000 R14: ff5c35909f277b50 R15: ff5c35909f277b30
[   31.261148] FS:  00007fb8e8256280(0000) GS:ff2aa6807fd80000(0000) knlGS:0000000000000000
[   31.276913] WARNING: CPU: 175 PID: 0 at kernel/workqueue.c:1650 __queue_delayed_work+0x68/0x80
[   31.284627] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   31.293749] Modules linked in:
[   31.303466] CR2: 0000000000000020 CR3: 00000080a8aaa003 CR4: 00000000000771ee0
[   31.309953]  iTCO_wdt
[   31.313408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   31.321457]  pmt_crashlog
[   31.324032] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
[   31.332282]  pmt_telemetry
[   31.335566] PKRU: 55555554
[   31.343894]  intel_sdsi
[   31.347296] Call Trace:
[   31.350659]  iTCO_vendor_support
[   31.353751]  ? __die_body+0x1a/0x60
[   31.356805]  pmt_class
[   31.360774]  ? no_context+0x1ba/0x3f0
[   31.360779]  ? __bad_area_nosemaphore+0x16c/0x1c0
[   31.360781]  ? do_page_fault+0x37/0x12d
[   31.365016]  joydev
[   31.368003]  ? page_fault+0x1e/0x30
[   31.372437]  ipmi_ssif
[   31.378064]  ? qat_rsa_exit_tfm+0x14/0x40 [intel_qat]
[   31.382679]  intel_uncore
[   31.385367]  ? public_key_verify_signature+0x249/0x320
[   31.389592]  cdc_ether
[   31.392570]  crypto_destroy_tfm+0x40/0xc0
[   31.398562]  pcspkr
[   31.401833]  crypto_destroy_tfm+0x40/0xc0
[   31.407910]  usbnet
[   31.410885]  public_key_verify_signature+0x254/0x320

Cause : Un problème de compatibilité entre AnolisOS 8.9 RHCK et Intel QAT provoque un plantage du système lors du démarrage sur les instances ecs.ebmc8i et ecs.ebmg8i.

Résolution : Si vous devez utiliser AnolisOS 8 RHCK sur ces types d'instances, utilisez plutôt AnolisOS 8.10 RHCK.

Trace d'appel au démarrage avec les noyaux récents

Symptômes : Une trace d'appel peut apparaître lors du démarrage de certains types d'instances, tels que ecs.i2,4xlarge, exécutant un système d'exploitation avec une version récente du noyau, comme RHEL 8.3 ou CentOS 8.3 avec le noyau 4.18.0-240.1.1.el8_3.x86_64. Voici un exemple de trace d'appel :

Dec 28 17:43:45 localhost SELinux:  Initializing.
Dec 28 17:43:45 localhost kernel: Dentry cache hash table entries: 8388608 (order: 14, 67108864 bytes)
Dec 28 17:43:45 localhost kernel: Inode-cache hash table entries: 4194304 (order: 13, 33554432 bytes)
Dec 28 17:43:45 localhost kernel: Mount-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Dec 28 17:43:45 localhost kernel: Mountpoint-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Dec 28 17:43:45 localhost kernel: unchecked MSR access error: WRMSR to 0x3a (tried to write 0x000000000000) at rIP: 0xffffffff8f26 (native_write_msr+0x4/0x20)
Dec 28 17:43:45 localhost kernel: Call Trace:
Dec 28 17:43:45 localhost kernel:  init_ia32_feat_ctl+0x73/0x28b
Dec 28 17:43:45 localhost kernel:  init_intel+0xdf/0x400
Dec 28 17:43:45 localhost kernel:  identify_cpu+0x1f1/0x510
Dec 28 17:43:45 localhost kernel:  identify_boot_cpu+0xc/0x77
Dec 28 17:43:45 localhost kernel:  check_bugs+0x28/0xa9a
Dec 28 17:43:45 localhost kernel:  ? __slab_alloc+0x29/0x30
Dec 28 17:43:45 localhost kernel:  ? kmem_cache_alloc+0x1aa/0x1b0
Dec 28 17:43:45 localhost kernel:  start_kernel+0x4fa/0x53e
Dec 28 17:43:45 localhost kernel:  secondary_startup_64+0xb7/0xc0
Dec 28 17:43:45 localhost kernel: Last level iTLB entries: 4KB 64, 2MB 8, 4MB 8
Dec 28 17:43:45 localhost kernel: Last level dTLB entries: 4KB 64, 2MB 0, 4MB 0, 1GB 4
Dec 28 17:43:45 localhost kernel: FEATURE SPEC_CTRL Present
Dec 28 17:43:45 localhost kernel: FEATURE IBPB_SUPPORT Present

Cause : Les mises à jour communautaires de ces versions du noyau incluent un correctif qui tente d'écrire dans les registres spécifiques au modèle (MSR). Cependant, certains types d'instances, tels que ecs.i2,4xlarge, s'exécutent sur une version de virtualisation qui ne prend pas en charge l'écriture dans les MSR, ce qui provoque la trace d'appel.

Résolution : Vous pouvez ignorer cette trace d'appel en toute sécurité, car elle n'affecte ni le fonctionnement ni la stabilité du système.

Famille d'instances hfg6 : L'incompatibilité du noyau provoque un panic

Symptômes : Sur les instances appartenant à la famille d'instances hfg6, la mise à niveau vers un nouveau noyau peut provoquer un panic du noyau sur certaines distributions Linux, telles que CentOS 8, SUSE Linux Enterprise Server 15 SP2 et OpenSUSE 15.2. Voici un exemple de trace d'appel :

[    0.005000]  apic_timer_interrupt+0xf/0x20
[    0.005000]  </IRQ>
[    0.005000] RIP: 0010:smp_call_functioxx
[    0.005000] Code: 8b 4c 24 38 65 48 3xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx xxx
3 e2 01 75 f5 eb ca 8b 05 b1 37 c0 01 85 xxx
[    0.005000] RSP: 000xxx      cfd80 EFLAGS: 00xxx    ORIG_RAX: ffxxx
[    0.005000] RAX: 000xxx            RBX: fffxxx        RCX: 00000000
[    0.005000] RDX: 000xxx            RSI: 000xxx        RDI: 00000000
[    0.005000] RBP: fffxxx            R08: 000xxx        R09: 00000000
[    0.005000] R10: fffxxx            R11: 000xxx        R12: 00000000
[    0.005000] R13: fffxxx            R14: 000xxx        R15: ffffffff
[    0.005000]  ? sort_range+0x20/0x20
[    0.005000]  ? poke_int3_handler+0xe0/0xe0
[    0.005000]  ? poke_int3_handler+0xe0/0xe0
[    0.005000]  ? poke_int3_handler+0xe0/0xe0
[    0.005000]  on_each_cpu+0x28/0x60
[    0.005000]  text_poke_bp_batch+0xcd/0x160
[    0.005000]  ? set_rq_offline+0x60/0x60
[    0.005000]  arch_jump_label_transform_apply+0x2e/0x50
[    0.005000]  static_key_slow_inc_cpuslocked+0x88/0x90
[    0.005000]  sched_cpu_activate+0xf1/0x100
[    0.005000]  ? refresh_zone_stat_thresholds+0x140/0x140
[    0.005000]  cpuhp_invoke_callback+0x8d/0x500
[    0.005000]  ? sort_range+0x20/0x20
[    0.005000]  cpuhp_thread_fun+0xb0/0x110
[    0.005000]  smpboot_thread_fn+0xc5/0x160
[    0.005000]  kthread+0x112/0x130
[    0.005000]  ? kthread_flush_work_fn+0x10/0x10
[    0.005000]  ret_from_fork+0x35/0x40
[    0.005000] Modules linked in:
[    0.005000] ---[ end trace 79c5ba462cfc4c1b ]---
[    0.005000] RIP: 0010:arch_scale_freq_tick+0x67/0x7e

Cause : Il existe un problème de compatibilité entre la famille d'instances hfg6 et certaines versions du noyau Linux.

Résolution :

• Les dernières versions du noyau pour SUSE Linux Enterprise Server 15 SP2 et OpenSUSE 15.2 incluent un correctif pour ce problème. Si votre noyau inclut les commits suivants, il est compatible avec la famille d'instances hfg6.

  commit 1e33d5975b49472e286bd7002ad0f689af33fab8
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:51:09 2020 +0200
  
      x86, sched: Bail out of frequency invariance if
      turbo_freq/base_freq gives 0 (bsc#1176925).
  
      suse-commit: a66109f44265ff3f3278fb34646152bc2b3224a5
      
      
  commit dafb858aa4c0e6b0ce6a7ebec5e206f4b3cfc11c
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:16:50 2020 +0200
  
      x86, sched: Bail out of frequency invariance if turbo frequency
      is unknown (bsc#1176925).
  
      suse-commit: 53cd83ab2b10e7a524cb5a287cd61f38ce06aab7
  
  commit 22d60a7b159c7851c33c45ada126be8139d68b87
  Author: Giovanni Gherdovich <ggherdovich@suse.cz>
  Date:   Thu Sep 24 16:10:30 2020 +0200
  
      x86, sched: check for counters overflow in frequency invariant
      accounting (bsc#1176925).

  Si vous utilisez la commande yum update pour effectuer une mise à niveau vers la version du noyau kernel-4.18.0-240 ou ultérieure sur une instance de la famille d'instances hfg6, un panic du noyau peut se produire. Dans ce cas, revenez à la version précédente du noyau.

pip : Délais d'expiration des requêtes

Symptômes : Les requêtes pip expirent parfois ou échouent.

Images concernées : CentOS, Debian, Ubuntu, SUSE, OpenSUSE et Alibaba Cloud Linux.

Cause : Alibaba Cloud fournit les points de terminaison source pip suivants. Le point de terminaison par défaut, mirrors.aliyun.com, nécessite une connexion Internet publique. Si votre instance ne dispose pas d'adresse IP publique, les requêtes pip peuvent expirer.

• (Réseau public par défaut) : mirrors.aliyun.com

• Réseau interne VPC : mirrors.cloud.aliyuncs.com

  Résolution : Utilisez l'une des méthodes suivantes pour résoudre le problème.

• Méthode 1 : Attribuez une adresse IP publique à votre instance en associant une adresse Elastic IP (EIP). Pour plus d'informations, consultez la rubrique Associer une EIP à une instance.

  Pour les instances par abonnement, vous pouvez également attribuer une nouvelle adresse IP publique lorsque vous modifiez le type d'instance.

• Méthode 2 :

  Si les réponses pip sont retardées, exécutez le script fix_pypi.sh sur l'instance ECS et réessayez l'opération. Suivez ces étapes :

  1. Connectez-vous à l'instance à distance.

     Pour plus d'informations, consultez la rubrique Se connecter à une instance à l'aide d'un client VNC.

  2. Exécutez la commande suivante pour télécharger le fichier de script.

     wget http://image-offline.oss-cn-hangzhou.aliyuncs.com/fix/fix_pypi.sh

  3. Exécutez le script.

     Pour les instances dans un VPC, exécutez la commande bash fix_pypi.sh "mirrors.cloud.aliyuncs.com".

  4. Réessayez l'opération pip.

     Le script fix_pypi.sh contient les éléments suivants :

  #!/bin/bash
  
  function config_pip() {
      pypi_source=$1
  
      if [[ ! -f ~/.pydistutils.cfg ]]; then
  cat > ~/.pydistutils.cfg << EOF
  [easy_install]
  index-url=http://$pypi_source/pypi/simple/
  EOF
      else
          sed -i "s#index-url.*#index-url=http://$pypi_source/pypi/simple/#" ~/.pydistutils.cfg
      fi
  
      if [[ ! -f ~/.pip/pip.conf ]]; then
      mkdir -p ~/.pip
  cat > ~/.pip/pip.conf << EOF
  [global]
  index-url=http://$pypi_source/pypi/simple/
  [install]
  trusted-host=$pypi_source
  EOF
      else
          sed -i "s#index-url.*#index-url=http://$pypi_source/pypi/simple/#" ~/.pip/pip.conf
          sed -i "s#trusted-host.*#trusted-host=$pypi_source#" ~/.pip/pip.conf
      fi
  }
  
  config_pip $1