本文介绍了不同发行平台的云服务器ECS镜像的已知故障、故障涉及范围以及解决方法。
部分高版本内核系统在部分实例规格上启动时可能出现Call Trace
- 问题描述:部分高版本内核系统(例如
4.18.0-240.1.1.el8_3.x86_64
内核版本的RHEL 8.3、CentOS 8.3系统等),在部分实例规格(例如ecs.i2.4xlarge)上启动时可能出现如下所示的Call Trace: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
- 问题原因:这部分内核版本社区更新合入了尝试Write MSR的PATCH,但部分实例规格(例如ecs.i2.4xlarge)由于虚拟化版本不支持Write MSR,导致出现该Call Trace。
- 修复方案:该Call Trace不影响系统正常使用及稳定性,您可以忽略该报错。
高主频通用型实例规格族hfg6与部分Linux内核版本存在兼容性问题导致panic
- 问题描述:目前Linux社区的部分系统,例如CentOS 8、SUSE Linux Enterprise Server 15 SP2、OpenSUSE 15.2等系统。在高主频通用型实例规格族hfg6的实例中升级新版本内核可能出现内核错误(Kernel panic)。calltrace调试示例如下:
- 问题原因:高主频通用型实例规格族hfg6与部分Linux内核版本存在兼容性问题。
- 修复方案:
- SUSE Linux Enterprise Server 15 SP2和OpenSUSE 15.2系统目前最新版内核已经修复。变更提交(commit)内容如下,如果您升级的最新版内核包含此内容,则已兼容实例规格族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).
- CentOS 8系统如果使用命令yum update升级到最新内核版本
kernel-4.18.0-240
及以上,在高主频通用型实例规格族hfg6的实例中,可能出现Kernel panic。如果发生该问题,请回退至上一个内核版本。
- SUSE Linux Enterprise Server 15 SP2和OpenSUSE 15.2系统目前最新版内核已经修复。变更提交(commit)内容如下,如果您升级的最新版内核包含此内容,则已兼容实例规格族hfg6。
SUSE Linux Enterprise Server 12 SP5:内核升级可能导致启动hang的问题
- 问题描述:SLES(SUSE Linux Enterprise Server)12 SP5之前的内核版本在升级至SLES 12 SP5,或SLES 12 SP5内部内核版本升级后,实例可能在某些CPU规格上启动hang。现已知的CPU规格为
Intel? Xeon? CPU E5-2682 v4 @ 2.50GHz
与Intel? Xeon? CPU E7-8880 v4 @ 2.20GHz
。对应的calltrace调试结果如下:[ 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 ** **
- 问题原因:新内核版本与CPU Microcode不兼容。
- 修复方案:在
/boot/grub2/grub.cfg
文件中,以linux
开头一行中增加内核参数idle=nomwait
。文件修改的示例内容如下: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 }
OpenSUSE 15:内核升级可能导致启动hang的问题
- 问题描述:OpenSUSE内核版本升级到
4.12.14-lp151.28.52-default
后,实例可能在某些CPU规格上启动hang,现已知的CPU规格为Intel? Xeon? CPU E5-2682 v4 @ 2.50GHz
。对应的calltrace调试结果如下:[ 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 ** **
- 问题原因:新内核版本与CPU Microcode不兼容,更多信息,请参见启动hang问题。
- 涉及镜像:opensuse_15_1_x64_20G_alibase_20200520.vhd。
- 修复方案:在/boot/grub2/grub.cfg文件中,以
linux
开头一行中增加内核参数idle=nomwait
。文件修改的示例内容如下: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 }
CentOS 8.0:公共镜像命名问题
- 问题描述:使用centos_8_0_x64_20G_alibase_20200218.vhd公共镜像创建了CentOS系统实例,远程连接实例后检查系统版本,您发现实际为CentOS 8.1。
root@ecshost:~$ lsb_release -a LSB Version: :core-4.1-amd64:core-4.1-noarch Distributor ID: CentOS Description: CentOS Linux release 8.1.1911 (Core) Release: 8.1.1911 Codename: Core
- 问题原因:该镜像出现在公共镜像列表中,已更新最新社区更新包,同时也升级了版本到8.1,所以实际版本是8.1。
- 涉及镜像ID:centos_8_0_x64_20G_alibase_20200218.vhd。
- 修复方案:如果您需要使用CentOS 8.0的系统版本,可以通过RunInstances等接口,设置
ImageId=centos_8_0_x64_20G_alibase_20191225.vhd
创建ECS实例。
Debian 9.6:经典网络配置问题
- 问题描述:无法Ping通使用Debian 9公共镜像创建的经典网络类型实例。
- 问题原因:因为Debian系统默认禁用了systemd-networkd服务,经典网络类型实例无法通过DHCP(Dynamic Host Configuration Protocol)模式自动分配IP。
- 涉及镜像ID:debian_9_06_64_20G_alibase_20181212.vhd。
- 修复方案:您需要依次运行下列命令解决该问题。
systemctl enable systemd-networkd
systemctl start systemd-networkd
CentOS 6.8:装有NFS Client的实例异常崩溃的问题
- 问题描述:加载了NFS客户端(NFS Client)的CentOS 6.8实例出现超长等待状态,只能通过重启实例解决该问题。
- 问题原因:在2.6.32-696~2.6.32-696.10的内核版本上使用NFS服务时,如果通信延迟出现毛刺(glitch,电子脉冲),内核nfsclient会主动断开TCP连接。若NFS服务端(Server)响应慢,nfsclient发起的连接可能会卡顿在FIN_WAIT2状态。正常情况下,FIN_WAIT2状态的连接默认在一分钟后超时并被回收,nfsclient可以发起重连。但是,由于此类内核版本的TCP实现有缺陷,FIN_WAIT2状态的连接永远不会超时,因此nfsclient的TCP连接永远无法关闭,无法发起新的连接,造成用户请求卡死(hang死),永远无法恢复,只能通过重启ECS实例进行修复。
- 涉及镜像ID:centos_6_08_32_40G_alibase_20170710.vhd和centos_6_08_64_20G_alibase_20170824.vhd。
- 修复方案:您可以运行yum update命令升级系统内核至2.6.32-696.11及以上版本。
注意 操作实例时,请确保您已经提前创建了快照备份数据。具体操作,请参见 创建一个云盘快照。
CentOS 7:重启系统后主机名大写字母被修改
- 问题描述:第一次重启ECS实例后,部分CentOS 7实例的主机名(hostname)存在大写字母变成小写字母的现象,如下表所示。
实例hostname示例 第一次重启后示例 后续是否保持小写不变 iZm5e1qe*****sxx1ps5zX izm5e1qe*****sxx1ps5zx 是 ZZHost zzhost 是 NetworkNode networknode 是 - 涉及镜像:以下CentOS公共镜像,和基于以下公共镜像创建的自定义镜像。
- 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
- 涉及Hostname类型:如果您的应用有hostname大小写敏感现象,重启实例后会影响业务。您可根据下面的修复方案修复以下类型的hostname。
hostname类型 是否受影响 何时受影响 是否继续阅读文档 在控制台或通过API创建实例时,hostname中有大写字母 是 第一次重启实例 是 在控制台或通过API创建实例时,hostname中全是小写字母 否 不适用 否 hostname中有大写字母,您登录实例后自行修改了hostname 否 不适用 是 - 修复方案:如果重启实例后需要保留带大写字母的hostname时,可按如下步骤操作。
- 远程连接实例。
具体操作,请参见连接方式介绍。
- 查看现有的hostname。
[root@izbp193*****3i161uynzzx ~]# hostname izbp193*****3i161uynzzx
- 运行以下命令固化hostname。
hostnamectl set-hostname --static iZbp193*****3i161uynzzX
- 运行以下命令查看更新后的hostname。
[root@izbp193*****3i161uynzzx ~]# hostname iZbp193*****3i161uynzzX
- 远程连接实例。
- 下一步:如果您使用的是自定义镜像,请更新cloud-init软件至最新版本后,再次创建自定义镜像。避免使用存在该问题的自定义镜像创建新实例后发生同样的问题。更多信息,请参见安装cloud-init和使用实例创建自定义镜像。
Linux:pip操作时的超时问题
- 问题描述:pip请求偶有超时或失败现象。
- 涉及镜像:CentOS、Debian、Ubuntu、SUSE、OpenSUSE、Alibaba Cloud Linux。
- 原因分析:阿里云提供了以下三个pip源地址。其中,默认访问地址为mirrors.aliyun.com,访问该地址的实例需能访问公网。当您的实例未分配公网IP时,会出现pip请求超时故障。
- (默认)公网:mirrors.aliyun.com
- 专有网络VPC内网:mirrors.cloud.aliyuncs.com
- 经典网络内网:mirrors.aliyuncs.com
- 修复方案:您可采用以下任一方法解决该问题。
- 方法一
为您的实例分配公网IP,即为实例绑定一个弹性公网IP(EIP)。具体操作,请参见绑定ECS实例。
包年包月实例还可通过升降配重新分配公网IP。具体操作,请参见包年包月实例升配规格。
- 方法二
一旦出现pip响应延迟的情况,您可在ECS实例中运行脚本 fix_pypi.sh,然后再重试pip操作。具体步骤如下:
- 远程连接实例。
具体操作,请参见通过密码认证登录Linux实例。
- 运行以下命令获取脚本文件。
wget http://image-offline.oss-cn-hangzhou.aliyuncs.com/fix/fix_pypi.sh
- 运行脚本。
- 专有网络VPC实例:运行命令
bash fix_pypi.sh "mirrors.cloud.aliyuncs.com"
。 - 经典网络实例:运行命令
bash fix_pypi.sh "mirrors.aliyuncs.com"
。
- 专有网络VPC实例:运行命令
- 重试pip操作。
fix_pypi.sh脚本内容如下:#!/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
- 远程连接实例。
- 方法一