Elastic Compute Service:Problemas conhecidos para imagens públicas

CentOS 8.0: Problema de nomenclatura de imagem pública

Sintomas: Após criar uma instância CentOS usando a imagem pública centos_8_0_x64_20G_alibase_20200218.vhd, você se conecta à instância e descobre que a versão do sistema é o 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

Causa: Esta imagem pública foi atualizada com os pacotes mais recentes da comunidade, o que atualizou sua versão para 8.1.

id da imagem afetada: centos_8_0_x64_20G_alibase_20200218.vhd.

Resolução: Se você precisar do CentOS 8.0, chame a operação da api e defina o parâmetro ImageId como centos_8_0_x64_20G_alibase_20191225.vhd para criar uma instância ECS.

CentOS 7: Problemas de alteração de ID de imagem

Sintomas: Os ids de imagem de algumas imagens públicas do CentOS 7 foram alterados. Essa alteração pode afetar processos automatizados que dependem de IDs de imagem específicos.

Imagens afetadas: CentOS 7.5 e CentOS 7.6

Causa: As versões mais recentes das imagens públicas do CentOS 7.5 e CentOS 7.6 usam o formato de ID de imagem %OS_Type%_%Major_Version%_%Minor_Version%_%Special_Field%_alibase_%Date%.%Format%. Por exemplo, o prefixo do ID de imagem para o CentOS 7.5 é atualizado de centos_7_05_64 para centos_7_5_x64. Você deve ajustar suas políticas automatizadas de O&M de acordo. Para mais informações sobre IDs de imagem, consulte Release notes for 2023.

CentOS 7: Alteração de maiúsculas e minúsculas no hostname após reinicialização

Sintomas: Em algumas instâncias do CentOS 7, as letras maiúsculas em um hostname são convertidas para minúsculas após a primeira reinicialização.

Imagens afetadas: As seguintes imagens públicas do CentOS e quaisquer imagens personalizadas criadas a partir delas.

• 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

  Aplicativos afetados: Se o seu aplicativo for sensível a maiúsculas e minúsculas no hostname, seus services podem ser afetados por uma reinicialização da instância. Use a tabela a seguir para determinar se você é afetado.

Resolução: Para manter as letras maiúsculas no hostname após uma reinicialização, siga estas etapas.

1. Conecte-se à instância remotamente.

   Para mais informações, consulte Connection methods.

2. Visualize o hostname atual.

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

3. Execute o comando a seguir para tornar o hostname persistente.

   hostnamectl set-hostname --static iZbp193*3i161uynzzX

4. Execute o comando a seguir para visualizar o hostname atualizado.

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

   Próximas etapas: Se você usar uma imagem personalizada, atualize o cloud-init para a versão mais recente e crie uma nova imagem personalizada. Isso evita que o problema ocorra em novas instâncias criadas a partir da imagem. Para mais informações, consulte Install cloud-init e Create a custom image from an instance.

CentOS 6.8: Falha na instância do cliente NFS

Sintomas: Uma instância do CentOS 6.8 com o cliente NFS carregado pode travar, exigindo uma reinicialização para se recuperar.

Causa: Ao usar o service NFS com uma versão do kernel de 2.6.32-696 a 2.6.32-696.10, o nfsclient do kernel desconecta proativamente a conexão TCP se ocorrer uma falha de latência de comunicação. Se o servidor NFS demorar a responder, a conexão iniciada pelo nfsclient pode ficar presa no estado FIN_WAIT2. Normalmente, uma conexão no estado FIN_WAIT2 atinge o tempo limite e é recuperada após um minuto, permitindo que o nfsclient reinicie a conexão. No entanto, devido a um defeito na implementação TCP dessas versões do kernel, a conexão no estado FIN_WAIT2 nunca atinge o tempo limite. Como resultado, a conexão TCP do nfsclient nunca pode ser fechada, o que bloqueia novas conexões e faz com que as requisições do usuário travem indefinidamente. Reiniciar a instância ECS é a única maneira de se recuperar.

IDs de imagem afetados: centos_6_08_32_40G_alibase_20170710.vhd e centos_6_08_64_20G_alibase_20170824.vhd.

Resolução: Execute o comando yum update para atualizar o kernel do sistema para a versão 2.6.32-696.11 ou posterior.

Kernel 5.15 do Ubuntu: A remoção a quente do disco aciona uma tarefa travada

Sintomas: Ao remover um disco a quente de uma instância que executa a versão 5.15.0-144-generic do kernel do Ubuntu, uma tarefa travada pode ser acionada intermitentemente com um tempo limite de cerca de 120 segundos. Os processos travados comuns incluem:

• kworker (thread de hot-plug ACPI)

• udev-worker (processo manipulador de eventos de dispositivo)

  Causa: Este problema é causado por uma falha lógica na função del_gendisk() do kernel. Uma condição de corrida entre o congelamento da fila e a liberação da referência do sysfs leva a um deadlock ABBA.

• O processo kworker mantém o bloqueio de congelamento da fila e aguarda a liberação da referência do sysfs.

• O processo udev-worker mantém a referência do sysfs e aguarda que a fila seja descongelada ou saia.

  Como o kernel não define a flag QUEUE_FLAG_DYING, o blk_queue_enter() não pode sair, o que resulta em um deadlock.

Resolução:

• Método 1: Atualizar o kernel (Recomendado)

  Atualize para uma versão do kernel que inclua a correção (5.19 ou posterior, ou um kernel de distribuição que inclua o patch).

• Método 2: Aplicar um patch (Correção temporária)

  No kernel 5.15, modifique a função del_gendisk() substituindo blk_queue_start_drain(q); por blk_set_queue_dying(q);. Essa alteração define a flag QUEUE_FLAG_DYING, o que permite que as requisições de I/O pendentes saiam prontamente e evita o deadlock.

Instâncias do Ubuntu 24.04 afetadas pela CVE-2024-57843 podem apresentar kernel panics ou corrupção de memória

• Sintomas: A CVE-2024-57843 é um overflow cross-page de 16 bytes que ocorre quando o driver virtio-net preenche buffers RX mescláveis. Sob condições específicas, como um MTU de 4084 ou superior, as instâncias do Ubuntu 24.04 LTS podem apresentar um kernel panic, falhar na transferência de arquivos grandes ou corromper silenciosamente as estruturas de dados do kernel.

• Escopo afetado e resolução: Para mais informações, consulte Impact and remediation of CVE-2024-57843 for ECS official images.

Instâncias do CentOS Stream 9 afetadas pela CVE-2024-57843 podem apresentar kernel panics ou corrupção de memória

• Sintomas: A CVE-2024-57843 é um overflow cross-page de 16 bytes que ocorre quando o driver virtio-net preenche buffers RX mescláveis. Sob condições específicas, como um MTU de 4084 ou superior, as instâncias do CentOS Stream 9 podem apresentar um kernel panic, falhar na transferência de arquivos grandes ou corromper silenciosamente as estruturas de dados do kernel.

• Escopo afetado e resolução: Para mais informações, consulte Impact and remediation of CVE-2024-57843 for ECS official images.

Instâncias do Fedora 40 afetadas pela CVE-2024-57843 podem apresentar kernel panics ou corrupção de memória

• Sintomas: A CVE-2024-57843 é um overflow cross-page de 16 bytes que ocorre quando o driver virtio-net preenche buffers RX mescláveis. Sob condições específicas, como um MTU de 4084 ou superior, as instâncias do Fedora 40 podem apresentar um kernel panic, falhar na transferência de arquivos grandes ou corromper silenciosamente as estruturas de dados do kernel. O Fedora 40 atingiu o fim da vida útil (EOL). Recomendamos que você migre para o Fedora 41 ou posterior.

• Escopo afetado e resolução: Para mais informações, consulte Impact and remediation of CVE-2024-57843 for ECS official images.

Fedora CoreOS: Hostname não aplicado a partir de imagens personalizadas

Sintomas: Ao criar uma instância ECS (instância B) a partir de uma imagem personalizada que foi criada a partir de outra instância Fedora CoreOS (instância A), o novo hostname especificado para a instância B não é aplicado. A instância B retém o hostname da instância A.

Por exemplo, você tem uma instância ECS (instance A) que executa o sistema operacional Fedora CoreOS e tem o hostname test001. Em seguida, você usa uma imagem personalizada desta instância para criar uma nova instância ECS (instance B). Durante o processo de criação, você define o hostname da instance B como test002. Após criar e se conectar remotamente à instance B, o hostname da instance B ainda é test001.

Causa: As imagens públicas do Fedora CoreOS fornecidas pelo Alibaba Cloud usam o service oficial Ignition para inicialização da instância. O Ignition é um utilitário usado pelo Fedora CoreOS e pelo Red Hat Enterprise Linux CoreOS para manipular discos durante a fase initramfs da inicialização do sistema. Quando uma instância ECS é iniciada pela primeira vez, o coreos-ignition-firstboot-complete.service no Ignition verifica a existência do arquivo /boot/ignition.firstboot para determinar se deve inicializar a instância. Se esse arquivo vazio existir, o Ignition prossegue com a inicialização, que inclui a configuração do hostname, e então exclui o arquivo /boot/ignition.firstboot.

Como a instância original do Fedora CoreOS foi iniciada pelo menos uma vez, o arquivo /boot/ignition.firstboot não está mais presente na imagem personalizada. Quando você usa essa imagem personalizada para criar uma nova instância ECS, o Ignition não executa o processo de inicialização na primeira inicialização, e o novo hostname não é aplicado.

Resolução:

Antes de criar uma imagem personalizada a partir de uma instância Fedora CoreOS, use as permissões de root para criar o arquivo /ignition.firstboot no diretório /boot:

1. Remonte /boot no modo de leitura e gravação.

   sudo mount /boot -o rw,remount

2. Crie o arquivo /ignition.firstboot.

   sudo touch /boot/ignition.firstboot

3. Remonte /boot no modo somente leitura.

   sudo mount /boot -o ro,remount

   Ignition Configuration Specification.

OpenSUSE 15: Travamento na inicialização após atualização do kernel

Sintomas: Após atualizar o kernel do OpenSUSE para 4.12.14-lp151.28.52-default, uma instância pode travar na inicialização em determinados tipos de CPU. O tipo de CPU afetado conhecido é Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz. O seguinte é o rastreamento de chamadas:

[    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  

Causa: A nova versão do kernel é incompatível com o Microcode da CPU. Para mais informações, consulte Bug 1162092.

Imagem afetada: opensuse_15_1_x64_20G_alibase_20200520.vhd.

Solução: No arquivo /boot/grub2/grub.cfg, adicione o parâmetro do kernel idle=nomwait à linha que começa com linux. Um exemplo da modificação é o seguinte:

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: Falha na atualização do kernel

Sintomas: Em uma instância ECS de 64 bits do Red Hat Enterprise Linux 8, você executa o comando yum update para atualizar o kernel e reinicia a instância. Após a reinicialização, você descobre que a versão do kernel permanece inalterada.

Causa: No Red Hat Enterprise Linux 8 de 64 bits, o arquivo /boot/grub2/grubenv que armazena as variáveis de ambiente do GRUB2 tem um tamanho anormal. O arquivo não tem os 1.024 bytes padrão, o que faz com que a atualização do kernel falhe.

Resolução: Após atualizar o kernel, você deve definir manualmente a nova versão como padrão para inicialização. Siga estas etapas:

1. Atualize o kernel.

   yum update kernel -y

2. Obtenha os parâmetros de inicialização do kernel do sistema operacional atual.

   grub2-editenv list | grep kernelopts

3. Faça backup do arquivo /grubenv antigo.

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

4. Gere um novo arquivo /grubenv.

   grub2-editenv /boot/grub2/grubenv create

5. Defina a nova versão do kernel como a versão de inicialização padrão.

   Neste exemplo, a versão atualizada do kernel é /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. Defina os parâmetros de inicialização do kernel.

   Defina o parâmetro kernelopts com o valor obtido na etapa 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. Reinicie a instância ECS para inicializar no novo kernel.

   reboot

   Aviso

   A operação de reinicialização interrompe a instância por um curto período de tempo e pode interromper os services que estão sendo executados na instância. Recomendamos que você reinicie a instância durante horários de menor movimento.

SUSE Linux Enterprise Server: Falha na conexão com o servidor SMT

Sintomas: Ao usar uma imagem paga do SUSE Linux Enterprise Server ou SUSE Linux Enterprise Server for SAP, você pode encontrar tempos limite de conexão ou outros problemas com o servidor Subscription Management Tool (SMT). Ao tentar baixar ou atualizar componentes, uma mensagem de erro semelhante a uma das seguintes é retornada:

• 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

  Imagens afetadas: SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP

Resolução: Você deve registrar e ativar novamente o service SMT.

1. Execute os seguintes comandos em sequência para registrar e ativar novamente o service SMT.

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. Execute o comando a seguir para verificar o status de ativação do service SMT.

   SUSEConnect -s

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

SUSE Linux Enterprise Server 12 SP5: Travamento na inicialização após atualização do kernel

SintomasIntel(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  

Causa: A nova versão do kernel é incompatível com o Microcode da CPU.

Resolução: No arquivo /boot/grub2/grub.cfg, adicione o parâmetro do kernel idle=nomwait à linha que começa com linux. O seguinte fornece um exemplo do arquivo modificado:

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: Falha na inicialização em ecs.ebmc8i e ecs.ebmg8i

Sintomas: Devido a um problema de compatibilidade entre o AnolisOS 8.9 RHCK e o Intel QAT, o sistema trava durante a inicialização nas instâncias ecs.ebmc8i e ecs.ebmg8i. Se você precisar usar o AnolisOS 8 RHCK nesses tipos de instância, recomendamos o uso do AnolisOS 8.10 RHCK.

O seguinte é um exemplo do log de travamento do kernel acionado durante a inicialização:

[   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

Causa: Um problema de compatibilidade entre o AnolisOS 8.9 RHCK e o Intel QAT faz com que o sistema trave durante a inicialização nas instâncias ecs.ebmc8i e ecs.ebmg8i.

Resolução: Se você precisar usar o AnolisOS 8 RHCK nesses tipos de instância, use o AnolisOS 8.10 RHCK.

Rastreamento de chamadas na inicialização com kernels recentes

Sintomas: Um rastreamento de chamadas pode ocorrer ao iniciar determinados tipos de instância, como ecs.i2.4xlarge, que executam um sistema operacional com uma versão recente do kernel, como RHEL 8.3 ou CentOS 8.3 com o kernel 4.18.0-240.1.1.el8_3.x86_64. O seguinte fornece um exemplo do rastreamento de chamadas:

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

Causa: As atualizações da comunidade para essas versões do kernel incluem um patch que tenta gravar em Registradores Específicos do Modelo (MSRs). No entanto, alguns tipos de instância, como ecs.i2.4xlarge, são executados em uma versão de virtualização que não suporta gravações MSR, o que causa o rastreamento de chamadas.

Resolução: Você pode ignorar com segurança este rastreamento de chamadas, pois ele não afeta a operação ou a estabilidade do sistema.

Família de instâncias hfg6: Incompatibilidade de kernel causa panic

Sintomas: Em instâncias que pertencem à família de instâncias hfg6, a atualização para um novo kernel pode causar um kernel panic em algumas distribuições Linux, como CentOS 8, SUSE Linux Enterprise Server 15 SP2 e OpenSUSE 15.2. O seguinte é um exemplo de rastreamento de chamadas:

[    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

Causa: Existe um problema de compatibilidade entre a família de instâncias hfg6 e algumas versões do kernel Linux.

Resolução:

• As versões mais recentes do kernel para SUSE Linux Enterprise Server 15 SP2 e OpenSUSE 15.2 incluem uma correção para este problema. Se o seu kernel incluir os seguintes commits, ele é compatível com a família de instâncias 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).

  Se você usar o comando yum update para atualizar para a versão do kernel kernel-4.18.0-240 ou posterior em uma instância da família de instâncias hfg6, um kernel panic pode ocorrer. Se isso acontecer, reverta para a versão anterior do kernel.

pip: Tempos limite de requisição

Sintomas: As requisições do pip ocasionalmente atingem o tempo limite ou falham.

Imagens afetadas: CentOS, Debian, Ubuntu, SUSE, OpenSUSE e Alibaba Cloud Linux.

Causa: O Alibaba Cloud fornece os seguintes endpoints de origem do pip. O endpoint padrão, mirrors.aliyun.com, requer uma conexão pública com a Internet. Se a sua instância não tiver um endereço IP público, as requisições do pip podem atingir o tempo limite.

• (Padrão) Rede pública: mirrors.aliyun.com

• Rede interna da VPC: mirrors.cloud.aliyuncs.com

  Resolução: Use um dos métodos a seguir para resolver o problema.

• Método 1: Atribua um endereço IP público à sua instância associando um endereço Elastic IP (EIP). Para mais informações, consulte Associate an EIP with an instance.

  Para instâncias de assinatura, você também pode atribuir um novo endereço IP público ao change the instance type.

• Método 2:

  Se as respostas do pip estiverem atrasadas, execute o script fix_pypi.sh na instância ECS e tente a operação novamente. Siga estas etapas:

  1. Conecte-se à instância remotamente.

     Para mais informações, consulte Connect to an instance by using a VNC client.

  2. Execute o comando a seguir para baixar o arquivo de script.

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

  3. Execute o script.

     Para instâncias em uma VPC, execute o comando bash fix_pypi.sh "mirrors.cloud.aliyuncs.com".

  4. Tente a operação do pip novamente.

     O script fix_pypi.sh contém o seguinte:

  #!/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