Elastic Compute Service:Masalah yang Diketahui untuk Gambar Publik

CentOS 8.0: Masalah penamaan gambar publik

Gejala: Setelah membuat instans CentOS menggunakan gambar publik centos_8_0_x64_20G_alibase_20200218.vhd, Anda menghubungkan ke instans dan menemukan bahwa versi sistem adalah 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

Penyebab: Gambar publik ini telah diperbarui dengan paket komunitas terbaru, yang meningkatkan versinya menjadi 8.1.

ID Gambar yang Terdampak: centos_8_0_x64_20G_alibase_20200218.vhd.

Resolusi: Jika Anda memerlukan CentOS 8.0, panggil operasi API dan atur parameter ImageId ke centos_8_0_x64_20G_alibase_20191225.vhd untuk membuat instans ECS.

CentOS 7: Masalah perubahan ID gambar

Gejala: ID gambar beberapa gambar publik CentOS 7 telah berubah. Perubahan ini dapat memengaruhi proses otomatis yang bergantung pada ID gambar tertentu.

Gambar yang Terdampak: CentOS 7.5 dan CentOS 7.6

Penyebab: Versi terbaru dari gambar publik CentOS 7.5 dan CentOS 7.6 menggunakan format ID gambar %OS_Type%_%Major_Version%_%Minor_Version%_%Special_Field%_alibase_%Date%.%Format%. Misalnya, awalan ID gambar untuk CentOS 7.5 diperbarui dari centos_7_05_64 menjadi centos_7_5_x64. Anda harus menyesuaikan kebijakan O&M otomatis Anda. Untuk informasi lebih lanjut tentang ID gambar, lihat Catatan Rilis untuk 2023.

CentOS 7: Perubahan huruf kapital hostname setelah restart

Gejala: Pada beberapa instans CentOS 7, huruf kapital dalam hostname diubah menjadi huruf kecil setelah restart pertama.

Gambar yang Terdampak: Gambar publik CentOS berikut dan gambar kustom apa pun yang dibuat darinya.

• 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

  Aplikasi yang Terdampak: Jika aplikasi Anda sensitif terhadap huruf kapital hostname, layanannya mungkin terdampak oleh restart instans. Gunakan tabel berikut untuk menentukan apakah Anda terdampak.

Resolusi: Untuk mempertahankan huruf kapital dalam hostname setelah restart, ikuti langkah-langkah berikut.

1. Hubungkan ke instans secara remote.

   Untuk informasi lebih lanjut, lihat Metode Koneksi.

2. Lihat hostname saat ini.

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

3. Jalankan perintah berikut untuk membuat hostname persisten.

   hostnamectl set-hostname --static iZbp193*3i161uynzzX

4. Jalankan perintah berikut untuk melihat hostname yang diperbarui.

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

   Langkah Selanjutnya: Jika Anda menggunakan gambar kustom, perbarui cloud-init ke versi terbaru lalu buat gambar kustom baru. Hal ini mencegah masalah terjadi pada instans baru yang dibuat dari gambar tersebut. Untuk informasi lebih lanjut, lihat Instal cloud-init dan Buat Gambar Kustom dari Instans.

CentOS 6.8: Instans klien NFS crash

Gejala: Instans CentOS 6.8 dengan klien NFS yang dimuat mungkin hang, memerlukan restart untuk pulih.

Penyebab: Saat menggunakan layanan NFS dengan versi kernel dari 2.6.32-696 hingga 2.6.32-696.10, nfsclient kernel secara proaktif memutus koneksi TCP jika terjadi gangguan latensi komunikasi. Jika server NFS lambat merespons, koneksi yang dimulai oleh nfsclient mungkin terjebak dalam status FIN_WAIT2. Biasanya, koneksi dalam status FIN_WAIT2 timeout dan diklaim kembali setelah satu menit, memungkinkan nfsclient memulai kembali koneksi. Namun, karena cacat dalam implementasi TCP pada versi kernel ini, koneksi dalam status FIN_WAIT2 tidak pernah timeout. Akibatnya, koneksi TCP nfsclient tidak pernah ditutup, yang memblokir koneksi baru dan menyebabkan permintaan pengguna hang tanpa batas. Merestart instans ECS adalah satu-satunya cara untuk pulih.

ID Gambar yang Terdampak: centos_6_08_32_40G_alibase_20170710.vhd dan centos_6_08_64_20G_alibase_20170824.vhd.

Resolusi: Jalankan perintah yum update untuk meningkatkan kernel sistem ke versi 2.6.32-696.11 atau lebih baru.

Kernel Ubuntu 5.15: Hot-unplug disk memicu hung task

Gejala: Saat melakukan hot-unplug disk dari instans yang menjalankan kernel Ubuntu versi 5.15.0-144-generic, hung task mungkin terpicu secara intermiten dengan timeout sekitar 120 detik. Proses yang umumnya macet meliputi:

• kworker (thread hot-plug ACPI)

• udev-worker (proses penanganan event perangkat)

  Penyebab: Masalah ini disebabkan oleh kelemahan logis dalam fungsi kernel del_gendisk(). Race condition antara freezing antrian dan melepaskan referensi sysfs menyebabkan deadlock ABBA.

• Proses kworker memegang lock freeze antrian dan menunggu referensi sysfs dilepaskan.

• Proses udev-worker memegang referensi sysfs dan menunggu antrian dibuka freeze atau keluar.

  Karena kernel tidak mengatur flag QUEUE_FLAG_DYING, blk_queue_enter() tidak dapat keluar, yang mengakibatkan deadlock.

Resolusi:

• Metode 1: Tingkatkan Kernel (Direkomendasikan)

  Tingkatkan ke versi kernel yang mencakup perbaikan (5.19 atau lebih baru, atau kernel distribusi yang mencakup patch tersebut).

• Metode 2: Terapkan Patch (Perbaikan Sementara)

  Pada kernel 5.15, modifikasi fungsi del_gendisk() dengan mengganti blk_queue_start_drain(q); dengan blk_set_queue_dying(q);. Perubahan ini mengatur flag QUEUE_FLAG_DYING, yang memungkinkan permintaan I/O tertunda keluar segera dan mencegah deadlock.

Instans Ubuntu 24.04 yang terdampak CVE-2024-57843 mungkin mengalami kernel panic atau korupsi memori

• Gejala: CVE-2024-57843 adalah overflow cross-page 16-byte yang terjadi saat driver virtio-net mengisi buffer RX yang dapat digabungkan. Dalam kondisi tertentu, seperti MTU 4084 atau lebih tinggi, instans Ubuntu 24.04 LTS mungkin mengalami kernel panic, gagal mentransfer file besar, atau diam-diam merusak struktur data kernel.

• Ruang Lingkup yang Terdampak dan Resolusi: Untuk informasi lebih lanjut, lihat Dampak dan Penanganan CVE-2024-57843 untuk Gambar Resmi ECS.

Instans CentOS Stream 9 yang terdampak CVE-2024-57843 mungkin mengalami kernel panic atau korupsi memori

• Gejala: CVE-2024-57843 adalah overflow cross-page 16-byte yang terjadi saat driver virtio-net mengisi buffer RX yang dapat digabungkan. Dalam kondisi tertentu, seperti MTU 4084 atau lebih tinggi, instans CentOS Stream 9 mungkin mengalami kernel panic, gagal mentransfer file besar, atau diam-diam merusak struktur data kernel.

• Ruang Lingkup yang Terdampak dan Resolusi: Untuk informasi lebih lanjut, lihat Dampak dan Penanganan CVE-2024-57843 untuk Gambar Resmi ECS.

Instans Fedora 40 yang terdampak CVE-2024-57843 mungkin mengalami kernel panic atau korupsi memori

• Gejala: CVE-2024-57843 adalah overflow cross-page 16-byte yang terjadi saat driver virtio-net mengisi buffer RX yang dapat digabungkan. Dalam kondisi tertentu, seperti MTU 4084 atau lebih tinggi, instans Fedora 40 mungkin mengalami kernel panic, gagal mentransfer file besar, atau diam-diam merusak struktur data kernel. Fedora 40 telah mencapai akhir masa pakai (EOL). Kami merekomendasikan Anda migrasi ke Fedora 41 atau versi lebih baru.

• Ruang Lingkup yang Terdampak dan Resolusi: Untuk informasi lebih lanjut, lihat Dampak dan Penanganan CVE-2024-57843 untuk Gambar Resmi ECS.

Fedora CoreOS: Hostname tidak diterapkan dari gambar kustom

Gejala: Saat membuat instans ECS (instans B) dari gambar kustom yang dibuat dari instans Fedora CoreOS lain (instans A), hostname baru yang ditentukan untuk instans B tidak diterapkan. Instans B tetap menggunakan hostname instans A.

Sebagai contoh, Anda memiliki instans ECS (instans A) yang menjalankan sistem operasi Fedora CoreOS dan memiliki hostname test001. Anda kemudian menggunakan gambar kustom dari instans ini untuk membuat instans ECS baru (instans B). Selama proses pembuatan, Anda mengatur hostname instans B menjadi test002. Setelah membuat dan menghubungkan secara remote ke instans B, hostname instans B tetap test001.

Penyebab: Gambar publik Fedora CoreOS yang disediakan oleh Alibaba Cloud menggunakan layanan Ignition resmi untuk inisialisasi instans. Ignition adalah utilitas yang digunakan oleh Fedora CoreOS dan Red Hat Enterprise Linux CoreOS untuk memanipulasi disk selama fase initramfs saat startup sistem. Saat instans ECS pertama kali dijalankan, coreos-ignition-firstboot-complete.service dalam Ignition memeriksa keberadaan file /boot/ignition.firstboot untuk menentukan apakah akan menginisialisasi instans. Jika file kosong ini ada, Ignition melanjutkan inisialisasi, yang mencakup konfigurasi hostname, lalu menghapus file /boot/ignition.firstboot.

Karena instans Fedora CoreOS asli telah dijalankan setidaknya sekali, file /boot/ignition.firstboot tidak lagi ada dalam gambar kustom. Saat Anda menggunakan gambar kustom ini untuk membuat instans ECS baru, Ignition tidak menjalankan proses inisialisasi saat boot pertama, dan hostname baru tidak diterapkan.

Resolusi:

Sebelum membuat gambar kustom dari instans Fedora CoreOS, gunakan izin root untuk membuat file /ignition.firstboot di direktori /boot:

1. Mount ulang /boot dalam mode read-write.

   sudo mount /boot -o rw,remount

2. Buat file /ignition.firstboot.

   sudo touch /boot/ignition.firstboot

3. Mount ulang /boot dalam mode read-only.

   sudo mount /boot -o ro,remount

   Spesifikasi Konfigurasi Ignition.

OpenSUSE 15: Hang saat startup setelah pembaruan kernel

Gejala: Setelah meningkatkan kernel OpenSUSE ke 4.12.14-lp151.28.52-default, instans mungkin hang saat startup pada jenis CPU tertentu. Jenis CPU yang diketahui terdampak adalah Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz. Berikut adalah call trace-nya:

[    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  

Penyebab: Versi kernel baru tidak kompatibel dengan Microcode CPU. Untuk informasi lebih lanjut, lihat Bug 1162092.

Gambar yang Terdampak: opensuse_15_1_x64_20G_alibase_20200520.vhd.

Solusi: Di file /boot/grub2/grub.cfg, tambahkan parameter kernel idle=nomwait pada baris yang dimulai dengan linux. Contoh modifikasinya sebagai berikut:

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: Gagal pembaruan kernel

Gejala: Pada instans ECS Red Hat Enterprise Linux 8 64-bit, Anda menjalankan perintah yum update untuk memperbarui kernel dan merestart instans. Setelah restart, Anda menemukan bahwa versi kernel tetap tidak berubah.

Penyebab: Pada Red Hat Enterprise Linux 8 64-bit, file /boot/grub2/grubenv yang menyimpan variabel lingkungan GRUB2 memiliki ukuran abnormal. File ini bukan 1.024 byte standar, yang menyebabkan pembaruan kernel gagal.

Resolusi: Setelah memperbarui kernel, Anda harus secara manual mengatur versi baru sebagai default untuk booting. Ikuti langkah-langkah berikut:

1. Perbarui kernel.

   yum update kernel -y

2. Dapatkan parameter boot kernel dari sistem operasi saat ini.

   grub2-editenv list | grep kernelopts

3. Cadangkan file /grubenv lama.

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

4. Buat file /grubenv baru.

   grub2-editenv /boot/grub2/grubenv create

5. Atur versi kernel baru sebagai versi boot default.

   Dalam contoh ini, versi kernel yang diperbarui adalah /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. Atur parameter boot kernel.

   Atur parameter kernelopts ke nilai yang Anda peroleh pada langkah 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. Restart instans ECS untuk boot ke kernel baru.

   reboot

   Peringatan

   Operasi mulai ulang akan menghentikan instans secara sementara dan dapat mengganggu layanan yang sedang berjalan di instans tersebut. Kami menyarankan Anda melakukan mulai ulang instans di luar jam sibuk.

   Operasi restart menghentikan instans secara singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda melakukan restart instans pada jam sepi.

   Operasi restart menghentikan instans secara singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda merestart instans selama jam sepi.

   Operasi restart menghentikan instans secara singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda melakukan restart instans selama jam sepi.

   Operasi restart menghentikan instans untuk waktu singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda merestart instans selama jam sepi.

   Operasi restart menghentikan instans secara singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda merestart instans pada jam sepi.

   Operasi restart menghentikan instans untuk waktu singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda merestart instans selama jam sepi.

   Operasi restart menghentikan instans secara singkat dan dapat mengganggu layanan yang sedang berjalan. Kami menyarankan Anda melakukan restart instans pada jam sepi.

SUSE Linux Enterprise Server: Kegagalan koneksi server SMT

Gejala: Saat menggunakan gambar SUSE Linux Enterprise Server atau SUSE Linux Enterprise Server for SAP berbayar, Anda mungkin mengalami timeout koneksi atau masalah lain dengan server Subscription Management Tool (SMT). Saat mencoba mengunduh atau memperbarui komponen, pesan error serupa salah satu berikut dikembalikan:

• 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

  Gambar yang Terdampak: SUSE Linux Enterprise Server, SUSE Linux Enterprise Server for SAP

Resolusi: Anda harus mendaftar ulang dan mengaktifkan layanan SMT.

1. Jalankan perintah berikut secara berurutan untuk mendaftar ulang dan mengaktifkan layanan SMT.

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. Jalankan perintah berikut untuk memverifikasi status aktivasi layanan SMT.

   SUSEConnect -s

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

SUSE Linux Enterprise Server 12 SP5: Hang saat startup setelah pembaruan kernel

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

Penyebab: Versi kernel baru tidak kompatibel dengan Microcode CPU.

Resolusi: Di file /boot/grub2/grub.cfg, tambahkan parameter kernel idle=nomwait pada baris yang dimulai dengan linux. Berikut contoh file yang telah dimodifikasi:

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: Kegagalan startup pada ecs.ebmc8i dan ecs.ebmg8i

Gejala: Karena masalah kompatibilitas antara AnolisOS 8.9 RHCK dan Intel QAT, sistem crash selama startup pada instans ecs.ebmc8i dan ecs.ebmg8i. Jika Anda perlu menggunakan AnolisOS 8 RHCK pada tipe instans ini, kami merekomendasikan Anda menggunakan AnolisOS 8.10 RHCK.

Berikut contoh log crash kernel yang dipicu selama startup:

[   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

Penyebab: Masalah kompatibilitas antara AnolisOS 8.9 RHCK dan Intel QAT menyebabkan sistem crash selama startup pada instans ecs.ebmc8i dan ecs.ebmg8i.

Resolusi: Jika Anda perlu menggunakan AnolisOS 8 RHCK pada tipe instans ini, gunakan AnolisOS 8.10 RHCK sebagai gantinya.

Call trace saat startup dengan kernel versi baru

Gejala: Call trace mungkin terjadi saat menjalankan tipe instans tertentu, seperti ecs.i2.4xlarge, yang menjalankan sistem operasi dengan versi kernel baru, seperti RHEL 8.3 atau CentOS 8.3 dengan kernel 4.18.0-240.1.1.el8_3.x86_64. Berikut contoh call trace-nya:

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

Penyebab: Pembaruan komunitas untuk versi kernel ini mencakup patch yang mencoba menulis ke Model-Specific Registers (MSR). Namun, beberapa tipe instans, seperti ecs.i2.4xlarge, berjalan pada versi virtualisasi yang tidak mendukung penulisan MSR, yang menyebabkan call trace.

Resolusi: Anda dapat mengabaikan call trace ini dengan aman karena tidak memengaruhi operasi atau stabilitas sistem.

Keluarga instans hfg6: Ketidakcocokan kernel menyebabkan panic

Gejala: Pada instans yang termasuk dalam keluarga instans hfg6, peningkatan ke kernel baru dapat menyebabkan kernel panic pada beberapa distribusi Linux, seperti CentOS 8, SUSE Linux Enterprise Server 15 SP2, dan OpenSUSE 15.2. Berikut contoh call trace-nya:

[    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

Penyebab: Masalah kompatibilitas ada antara keluarga instans hfg6 dan beberapa versi kernel Linux.

Resolusi:

• Versi kernel terbaru untuk SUSE Linux Enterprise Server 15 SP2 dan OpenSUSE 15.2 mencakup perbaikan untuk masalah ini. Jika kernel Anda mencakup commit berikut, maka kompatibel dengan keluarga instans 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).

  Jika Anda menjalankan perintah yum update untuk meningkatkan ke versi kernel kernel-4.18.0-240 atau lebih baru pada instans dari keluarga hfg6, kernel panic mungkin terjadi. Jika hal ini terjadi, kembalikan ke versi kernel sebelumnya.

pip: Timeout permintaan

Gejala: Permintaan pip kadang-kadang timeout atau gagal.

Gambar yang Terdampak: CentOS, Debian, Ubuntu, SUSE, OpenSUSE, dan Alibaba Cloud Linux.

Penyebab: Alibaba Cloud menyediakan titik akhir sumber pip berikut. Titik akhir default, mirrors.aliyun.com, memerlukan koneksi Internet publik. Jika instans Anda tidak memiliki alamat IP publik, permintaan pip mungkin timeout.

• (Default) Jaringan publik: mirrors.aliyun.com

• Jaringan internal VPC: mirrors.cloud.aliyuncs.com

  Resolusi: Gunakan salah satu metode berikut untuk mengatasi masalah ini.

• Metode 1: Tetapkan alamat IP publik ke instans Anda dengan mengasosiasikan alamat Elastic IP (EIP). Untuk informasi lebih lanjut, lihat Mengasosiasikan EIP dengan Instans.

  Untuk instans subscription, Anda juga dapat menetapkan alamat IP publik baru saat Anda mengubah tipe instans.

• Metode 2:

  Jika respons pip tertunda, jalankan skrip fix_pypi.sh pada instans ECS dan coba lagi operasinya. Ikuti langkah-langkah berikut:

  1. Hubungkan ke instans secara remote.

     Untuk informasi lebih lanjut, lihat Menghubungkan ke Instans Menggunakan Klien VNC.

  2. Jalankan perintah berikut untuk mengunduh file skrip.

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

  3. Jalankan skrip tersebut.

     Untuk instans di VPC, jalankan perintah bash fix_pypi.sh "mirrors.cloud.aliyuncs.com".

  4. Coba lagi operasi pip.

     Skrip fix_pypi.sh berisi hal berikut:

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