公共镜像已知问题

问题描述：使用centos_8_0_x64_20G_alibase_20200218.vhd公共镜像创建了CentOS系统实例，远程连接实例后检查系统版本，您发现实际为CentOS 8.1。

testuser@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实例。

问题描述：部分CentOS 7公共镜像更新了镜像ID，可能会影响到您自动化运维过程中获取镜像ID的策略。

涉及镜像：CentOS 7.5、CentOS 7.6

原因分析：CentOS 7.5和CentOS 7.6公共镜像在最新版本中使用的镜像ID格式为%OS类型%_%大版本号%_%小版本号%_%特殊字段%_alibase_%日期%.%格式%。例如，CentOS 7.5的镜像ID前缀由原centos_7_05_64更新为centos_7_5_x64。您需要根据镜像ID的变更自行调整可能受影响的自动化运维策略。关于镜像ID的更多信息，请参见2023年。

问题描述：第一次重启ECS实例后，部分CentOS 7实例的主机名（hostname）存在大写字母变成小写字母的现象，如下表所示。

涉及镜像：以下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时，可按如下步骤操作。

1. 远程连接实例。

   具体操作，请参见选择合适的工具连接实例。

2. 查看现有的hostname。

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

3. 运行以下命令固化hostname。

   hostnamectl set-hostname --static iZbp193*****3i161uynzzX

4. 运行以下命令查看更新后的hostname。

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

下一步：如果您使用的是自定义镜像，请更新cloud-init软件至最新版本后，再次创建自定义镜像。避免使用存在该问题的自定义镜像创建新实例后发生同样的问题。更多信息，请参见安装cloud-init和使用实例创建自定义镜像。

问题描述：加载了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及以上版本。

问题描述：无法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

问题描述：当您选择Fedora CoreOS镜像创建了一台ECS实例A，通过实例A创建了一个自定义镜像，然后通过该自定义镜像新建了一台ECS实例B时，您为实例B设置的主机名不生效（登录实例B查看时，实例B的主机名与实例A的主机名相同）。

例如，您有一台Fedora CoreOS操作系统的ECS实例（实例A），主机名为test001，然后您使用该实例对应的自定义镜像新建了一台ECS实例（实例B），并且在创建实例的过程中，将实例B的主机名设置为了test002。当您成功创建并远程连接实例B后，实例B的主机名仍然为test001。

问题原因：阿里云公共镜像提供的Fedora CoreOS镜像采用操作系统官方的Ignition服务进行实例初始化配置。Ignition服务是指Fedora CoreOS与Red Hat Enterprise Linux CoreOS在系统启动时进入initramfs期间用来操作磁盘的程序。ECS实例在首次启动时，Ignition中的coreos-ignition-firstboot-complete.service会根据/boot/ignition.firstboot文件（该文件为空文件）是否存在，判断是否进行实例的初始化配置。如果文件存在，则进行初始化配置（其中包括配置主机名），并删除/boot/ignition.firstboot文件。

由于创建Fedora CoreOS实例后至少启动了一次，则对应自定义镜像中的/boot/ignition.firstboot文件已被删除。当您使用该自定义镜像新建ECS实例时，实例首次启动并不会进行初始化配置，对应的主机名称也不会发生变化。

修复方案：

当您基于Fedora CoreOS实例创建自定义镜像前，先使用root权限（管理员权限）在/boot目录下创建/ignition.firstboot文件。命令行操作说明如下：

1. 以读写方式重新挂载/boot。

   sudo mount /boot -o rw,remount

2. 创建/ignition.firstboot文件。

   sudo touch /boot/ignition.firstboot

3. 以只读方式重新挂载/boot。

   sudo mount /boot -o ro,remount

关于Ignition相关的配置说明，请参见Ignition配置说明参考。

问题描述：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
}

问题描述：在Red Hat Enterprise Linux 8 64位操作系统的ECS实例中，运行yum update更新内核版本并重启实例后，发现内核版本仍为旧的内核版本。

问题原因：RHEL 8 64位操作系统中存储GRUB2环境变量的文件/boot/grub2/grubenv大小异常，该文件大小不是标准的1024字节，从而导致更新内核版本失败。

修复方案：您需要在更新内核版本后，将新的内核版本设置为默认启动版本。完整的操作说明如下所述：

1. 运行以下命令，更新内核版本。

   yum update kernel -y

2. 运行以下命令，获取当前操作系统的内核启动参数。

   grub2-editenv list | grep kernelopts

3. 运行以下命令，备份旧的/grubenv文件。

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

4. 运行以下命令，生成一个新的/grubenv文件。

   grub2-editenv /boot/grub2/grubenv create

5. 运行以下命令，把新的内核版本设置为默认启动版本。

   本示例中，更新后的新内核版本以/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. 运行以下命令，设置内核启动参数。

   其中，参数- set kernelopts需要手动设置，取值为步骤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. 运行以下命令，重启ECS实例至新的内核版本。

   reboot

   警告

   重启实例会造成您的实例停止工作，可能导致业务中断，建议您在非业务高峰期时执行该操作。

问题描述：您购买并使用阿里云付费镜像SUSE Linux Enterprise Server或SUSE Linux Enterprise Server for SAP时，会遇到SMT Server连接超时或异常的情况。当您尝试下载或更新组件时，返回类似于如下所示的报错信息：

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

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

涉及镜像：SUSE Linux Enterprise Server、SUSE Linux Enterprise Server for SAP

解决方案：您需要重新注册并激活SMT服务。

1. 依次运行以下命令，重新注册并激活SMT服务。

   SUSEConnect -d
   SUSEConnect --cleanup
   systemctl restart guestregister

2. 运行以下命令，验证SMT服务的激活状态。

   SUSEConnect -s

   命令行返回示例如下，表示成功激活SMT服务。

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

问题描述：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
}

问题描述：部分高版本内核系统（例如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不影响系统正常使用及稳定性，您可以忽略该报错。

问题描述：目前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。如果发生该问题，请回退至上一个内核版本。

问题描述：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）。具体操作，请参见将EIP绑定至ECS实例。

  包年包月实例还可通过升降配重新分配公网IP。具体操作，请参见包年包月实例升配规格。

• 方法二

  一旦出现pip响应延迟的情况，您可在ECS实例中运行脚本fix_pypi.sh，然后再重试pip操作。具体步骤如下：

  1. 远程连接实例。

     具体操作，请参见通过VNC连接实例。

  2. 运行以下命令获取脚本文件。

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

  3. 运行脚本。

     • 专有网络VPC实例：运行命令bash fix_pypi.sh "mirrors.cloud.aliyuncs.com"。

     • 经典网络实例：运行命令bash fix_pypi.sh "mirrors.aliyuncs.com"。

  4. 重试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