すべてのプロダクト
Search
ドキュメントセンター

Elastic Compute Service:既知の問題

最終更新日:Jan 11, 2024

このトピックでは、さまざまなオペレーティングシステムのAlibaba Cloudイメージの既知の問題、これらの問題の範囲、およびこれらの問題の解決策について説明します。

Windows Server: 6月2022日にMicrosoftによってリリースされたパッチにより、NATが有効になっているサーバーでRRASの問題が発生します

  • 問題の説明: 2022年6月23日のMicrosoftからの発表によると、2022年6月にMicrosoftがリリースしたセキュリティパッチのインストールは、次のリスクをもたらす可能性があります。Routing and Remote Access Service (RRAS) を使用しているWindowsサーバーがインターネットへの接続を失い、サーバーに接続するデバイスがインターネットに接続できない可能性があります。
  • Windows Serverの影響を受けるバージョン:
    • Windows Server 2022
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2012
    Windows Server 2012 R2およびWindows Server 2012のシステム更新プログラムを確認する場合は、次の図に示すように、① のタグが付いている更新プログラムの確認を選択します。 ① オプションがリンクされている更新リポジトリは、Alibaba Cloud内部のWindows Server update Services (WSUS) サーバーです。 ② オプションがリンクされている更新リポジトリは、公式のMicrosoft Windows updateサーバーです。 特定の場合、セキュリティ更新は潜在的な問題を引き起こし得る。 この状況を防ぐために、Alibaba CloudはMicrosoftのWindowsセキュリティ更新プログラムをチェックし、チェックに合格した更新プログラムのみを内部WSUSサーバーにリリースします。 Check for updates
  • 解決策: 関連するパッチがAlibaba Cloud WSUSから削除されました。 Windowsオペレーティングシステムがこの問題の影響を受けないようにするには、オペレーティングシステムにパッチがインストールされているかどうかを確認することをお勧めします。 オペレーティングシステムのバージョンに基づいて、次のいずれかのコマンドを実行します。
    Windows Server 2012 R2: wmic qfe get hotfixid | find "5014738"
    Windows Server 2019: wmic qfe get hotfixid | 「5014692」を見つける
    Windows Server 2016: wmic qfe get hotfixid | 「5014702」を見つける
    Windows Server 2012: wmic qfe get hotfixid | 「5014747」を見つける
    Windows Server 2022: wmic qfe get hotfixid | find "5014678" 
    パッチがインストールされており、WindowsサーバーでRRASの問題が発生していることをコマンド出力が示す場合は、パッチをアンインストールしてサーバーに機能を復元することをお勧めします。 オペレーティングシステムのバージョンに基づいて次のいずれかのコマンドを実行して、パッチをアンインストールします。
    Windows Server 2012 R2: wusa /uninstall /kb:5014738
    Windows Server 2019: wusa /uninstall /kb:5014692
    Windows Server 2016: wusa /uninstall /kb:5014702
    Windows Server 2012: wusa /uninstall /kb:5014747
    Windows Server 2022: wusa /uninstall /kb:5014678 
    説明 この問題に関する詳細な更新と運用ガイダンスについては、Microsoftの公式の指示に従ってください。 詳細については、「パブリックインターフェイスでNATが有効になっている場合、RRASサーバーは接続を失う可能性があります」をご参照ください。

Windows Server: 1月2022日にリリースされたパッチは、Windows Serverドメインコントローラー (DC) で異常な動作を引き起こします

  • 問題の説明: 2022年1月13日のMicrosoftからの発表によると、2022年1月にMicrosoftがリリースしたセキュリティパッチのインストールは、次のリスクをもたらす可能性があります。Hyper-Vの仮想マシンが起動できず、Windows Server DCが再起動または再起動ループに陥ることができず、IPSec VPN接続が失敗します。
  • Windows Serverの影響を受けるバージョン:
    • Windows Server 2022
    • Windowsサーバー、バージョン20H2
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2
    • Windows Server 2012
    Windows Server 2012 R2およびWindows Server 2012のシステム更新プログラムを確認する場合は、次の図に示すように、① のタグが付いている更新プログラムの確認を選択します。 ① オプションがリンクされている更新リポジトリは、Alibaba Cloud内部のWindows Server update Services (WSUS) サーバーです。 ② オプションがリンクされている更新リポジトリは、公式のMicrosoft Windows updateサーバーです。 特定の場合、セキュリティ更新は潜在的な問題を引き起こし得る。 この状況を防ぐために、Alibaba CloudはMicrosoftのWindowsセキュリティ更新プログラムをチェックし、チェックに合格した更新プログラムのみを内部WSUSサーバーにリリースします。 Check for updates
  • 解決策: 関連するパッチがAlibaba Cloud WSUSから削除されました。 Windowsオペレーティングシステムがこの問題の影響を受けないようにするには、オペレーティングシステムにパッチがインストールされているかどうかを確認することをお勧めします。 オペレーティングシステムのバージョンに基づいて、次のいずれかのコマンドを実行します。
    Windows Server 2012 R2: wmic qfe get hotfixid | find "5009624"
    Windows Server 2019: wmic qfe get hotfixid | 「5009557」を見つける
    Windows Server 2016: wmic qfe get hotfixid | 「5009546」を見つける
    Windows Server 2012: wmic qfe get hotfixid | 「5009586」を見つける
    Windows Server 2022: wmic qfe get hotfixid | 「5009555」
    を見つけるパッチがオペレーティングシステムにインストールされていて、DCを使用できないか、仮想マシンを起動できない場合は、パッチをアンインストールしてサーバーに機能を復元することをお勧めします。 オペレーティングシステムのバージョンに基づいて次のいずれかのコマンドを実行して、パッチをアンインストールします。
    Windows Server 2012 R2: wusa /uninstall /kb:5009624
    Windows Server 2019: wusa /uninstall /kb:5009557
    Windows Server 2016: wusa /uninstall /kb:5009546
    Windows Server 2012: wusa /uninstall /kb:5009586
    Windows Server 2022: wusa /uninstall /kb:5009555 
    説明 この問題に関する詳細な更新と運用ガイダンスについては、Microsoftの公式の指示に従ってください。 詳細については、「パブリックインターフェイスでNATが有効になっている場合、RRASサーバーは接続を失う可能性があります」をご参照ください。

Linux: 特定のインスタンスタイプの場合、より新しいカーネルバージョンのオペレーティングシステムを実行するインスタンスが開始されると、コールトレースが発生する場合があります。

  • 問題の説明: ecs.i2.4xlargeなどの特定のインスタンスタイプのインスタンスが、カーネルバージョンが4.18.0-240.1.1.el8_3.x86_64のRed Hat Enterprise Linux (RHEL) 8.3やCentOS 8.3などの最新のカーネルバージョンのオペレーティングシステムを実行している場合、インスタンスの起動時にコールトレースが発生する可能性があります。 コールトレースの例:
    Dec 28 17:43:45 localhost SELinux: Initializing.
    Dec 28 17:43:45 localhostカーネル: Dentryキャッシュハッシュテーブルエントリ: 8388608 (order: 14, 67108864バイト)
    Dec 28 17:43:45 localhostカーネル: Inode-cacheハッシュテーブルエントリ: 4194304 (order: 13, 33554432バイト)
    12月28日17:43:45 localhostカーネル: マウントキャッシュハッシュテーブルエントリ: 131072 (order: 8, 1048576バイト)
    12月28日17:43:45 localhostカーネル: Mountpoint-キャッシュハッシュテーブルエントリ: 131072 (order: 8, 1048576バイト)
    12月28 17:43:45 localhostカーネル: チェックされていないMSRアクセスエラー: WRMSRから0x3a (0x000000000000 **** を書き込もうとした) at rIP: 0xffffff8f26 **** (native_write_msr + 0x 4/0x 20)
    12月28日17:43:45 localhostカーネル: Call Trace:
    12月28日17:43:45 localhostカーネル: init_ia32_feat_ctl + 0x7 3/0x28b
    12月28日17:43:45 localhostカーネル: init_intel + 0xdf/0x400
    12月28日17:43:45 localhostカーネル: identify_cpu + 0x1f 1/0x510
    12月28日17:43:45 localhostカーネル: identify_boot_cpu + 0xc/0x77
    12月28 17:43:45 localhostカーネル: check_bugs + 0x2 8/0xa9a
    12月28日17:43:45 localhostカーネル:? __slab_alloc + 0x2 9/0x30
    12月28日17:43:45 localhostカーネル:? kmem_cache_alloc + 0x 1aa/0x1b0
    12月28 17:43:45 localhostカーネル: start_kernel + 0x 4fa/0x53e
    12月28日17:43:45 localhostカーネル: secondary_startup_64 + 0xb 7/0xc0
    12月28 17:43:45 localhostカーネル: 最終レベルiTLBエントリ: 4KB 64、2MB 8、4MB 8
    12月28 17:43:45 localhostカーネル: 最終レベルdTLBエントリ: 4KB 64、2MB 0、4MB 0、1GB 4
    12月28 17:43:45 localhostカーネル: FEATURE SPEC_CTRL Present
    12月28 17:43:45 localhostカーネル: FEATURE IBPB_SUPPORT Present 
  • 原因: 最新のコミュニティ更新プログラムパッケージを使用して、モデル固有レジスタ (MSR) への書き込み用のパッチを含めることで、カーネルバージョンが更新されます。 ただし、ecs.i2.4xlargeなどの一部のインスタンスタイプは、仮想化による制限のため、MSRへの書き込みをサポートしていません。
  • 解決策: コールトレースはシステムの動作や安定性に影響しません。 この問題は無視できます。

Linux: 特定のLinuxカーネルバージョンと、クロック速度の高いhfg6汎用インスタンスファミリーとの互換性の問題により、カーネルパニックが発生する可能性があります。

  • 問題の説明: CentOS 8、SUSE Linux Enterprise Server (SLES) 15 SP2、openSUSE 15.2などの一部のオープンソースLinuxディストリビューションのカーネルがhfg6インスタンスで最新バージョンに更新されると、カーネルパニックエラーが発生する可能性があります。 トレース呼び出しのデバッグ方法の例を次の図に示します。kernel panic
  • 原因: 一部のLinuxカーネルバージョンは、クロック速度の高いhfg6汎用インスタンスファミリーと互換性がありません。
  • 解決策:
    • 互換性の問題は、SLES 15 SP2とopenSUSE 15.2の最新のカーネルバージョンで修正されています。 次のコードは、変更コミットの情報を示しています。 最新のカーネルバージョンにこの情報が含まれている場合、カーネルバージョンはhfg6インスタンスファミリーと互換性があります。
      コミット
      著者: Giovanni Gherdovich <ggherdovich@suse.cz>
      日付: 9月24日木曜日16:51:09 2020 + 0200
      
          x86、sched: 周波数不変性の保釈
          turbo_freq/base_freqは0 (bsc#1176925) を与える。
      
          suse-commit: a66109f44265ff3f3278fb34646152bc2b3224a5
          
          
      コミット
      著者: Giovanni Gherdovich <ggherdovich@suse.cz>
      日付: 9月24日木曜日16:16:50 2020 + 0200
      
          x86、sched: ターボ周波数の場合、周波数の不変性から逃れる
          が不明です (bsc#1176925) 。
      
          suse-commit: 53cd83ab2b10e7a524cb5a287cd61f38ce06aab7
      
      コミット
      著者: Giovanni Gherdovich <ggherdovich@suse.cz>
      日付: 9月24日木曜日16:10:30 2020 + 0200
      
          x86、sched: 周波数不変でカウンターのオーバーフローをチェック
          アカウンティング (bsc#1176925) 。
    • yum updateコマンドを実行して、hfg6インスタンスでCentOS 8のカーネルをkernel-4.18.0-240以降に更新すると、カーネルパニックエラーが発生することがあります。 このエラーが発生した場合は、カーネルを以前のバージョンにロールバックします。

Linux: Pipリクエストがタイムアウト

  • 問題の説明: Pipリクエストが時間切れまたは失敗することがあります。
  • 影響を受けるイメージ: CentOS、Debian、Ubuntu、SUSE、openSUSE、Alibaba Cloud Linux。
  • 原因: Alibaba Cloudは3つのpipリポジトリアドレスを提供します。 デフォルトのアドレスiがs mirrors.aliyun.comされます。 このアドレスにアクセスするには、インスタンスがインターネットにアクセスできる必要があります。 インスタンスにパブリックIPアドレスが割り当てられていない場合、pipリクエストはタイムアウトします。
    • デフォルトのパブリックリポジトリアドレス: mirrors.aliyun.com
    • 仮想プライベートクラウド (VPC) の内部リポジトリアドレス: mirrors.cloud.aliyuncs.com
    • クラシックネットワークの内部リポジトリアドレス: mirrors.aliyuncs.com
  • 解決策: 次のいずれかの方法を使用して問題を解決します。
    • 方法 1

      elastic IPアドレス (EIP) をインスタンスに関連付けて、パブリックIPアドレスをインスタンスに割り当てます。 詳細については、「EIPとECSインスタンスの関連付け」をご参照ください。

      または、インスタンス設定をアップグレードまたはダウングレードして、サブスクリプションインスタンスにパブリックIPアドレスを割り当てることもできます。 詳細については、「サブスクリプションインスタンスのインスタンスタイプのアップグレード」をご参照ください。

    • 方法 2
      pipリクエストが失敗した場合は、インスタンスで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];
      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];
          mkdir -p ~/.pip
      cat > ~/.pip/pip.conf << EOF
      [グローバル]
      index-url=http://$pypi_source/pypi/simple /
      [インストール]
      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 

CentOS 8.0: パブリックイメージの更新後、作成されるインスタンスのイメージバージョン番号が変更されます。

  • 問題の説明: centos_8_0_x64_20G_alibase_20200218.vhdパブリックイメージから作成されたインスタンスに接続すると、インスタンスのオペレーティングシステムバージョンがCentOS 8.1であることがわかります。
    testuser @ ecshost:~$ lsb_release -a
    LSBバージョン: :core-4.1-amd64:core-4.1-noarch
    ディストリビューターID: CentOS
    説明: CentOS Linuxリリース8.1.1911 (コア)
    リリース: 8.1.1911
    コードネーム: コア 
  • 原因: centos_8_0_x64_20G_alibase_20200218.vhdイメージは、最新のコミュニティ更新パッケージを使用して更新されたパブリックイメージです。 イメージ内のCentOSのバージョンが8.1にアップグレードされました。 したがって、実際のオペレーティングシステムのバージョンはCentOS 8.1です。 centos_8_0_x64_20G_alibase_20200218.vhd
  • 影響を受けるイメージ: centos_8_0_x64_20G_alibase_20200218.vhd。
  • 解決策: RunInstancesなどの操作を呼び出し、ImageIdをcentos_8_0_x64_20G_alibase_20191225.vhdに設定して、オペレーティングシステムのバージョンがCentOS 8.0のインスタンスを作成できます。

CentOS 7: 一部のイメージIDの更新によって問題が発生する可能性があります

  • 問題の説明: 一部のCentOS 7パブリックイメージではイメージIDが更新されており、自動O&M中にイメージIDを取得するポリシーに影響を与える可能性があります。
  • 影響を受ける画像: CentOS 7.5とCentOS 7.6。
  • 原因: 最新バージョンのCentOS 7.5およびCentOS 7.6パブリックイメージで使用されるイメージIDは、% OS type %_% major version number %_% minor version number %_% special field %_alibase_% date %.% format % です。 たとえば、CentOS 7.5パブリックイメージのイメージIDプレフィックスは、centos_7_05_64からcentos_7_5_x64に更新されます。 イメージIDの更新に応じて、影響を受ける可能性のある自動O&Mポリシーを調整する必要があります。 イメージIDの詳細については、「2023のリリースノート」をご参照ください。

CentOS 7: インスタンスの再起動後、ホスト名が大文字から小文字に変更されます。

  • 問題の説明: CentOS 7を実行する一部のインスタンスが初めて再起動されると、これらのインスタンスのホスト名が大文字から小文字に変更されます。 次の表にいくつかの例を示します。
    ホスト名インスタンスを初めて再起動した後のホスト名インスタンスの再起動後もホスト名は小文字のまま
    iZm5e1qe ***** sxx1ps5zXizm5e1qe ***** sxx1ps5zx必須
    ZZHostzzhost必須
    NetworkNodenetworknode必須
  • 次の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
  • 影響を受けるホスト名: インスタンスにデプロイされたアプリケーションのホスト名が大文字と小文字を区別する場合、これらのインスタンスを再起動するとサービスが影響を受ける可能性があります。 次の表に、インスタンスの再起動後にホスト名が変更されるかどうかを示します。
    ホスト名の現在の状態インスタンスの再起動後のホスト名の変更ホスト名が変更された時刻続きを読むこのセクション
    ECSコンソールを使用して、またはECS API操作を呼び出してインスタンスを作成する場合、ホスト名には大文字が含まれます。必須インスタンスが初めて再起動されたとき。必須
    ECSコンソールを使用して、またはECS API操作を呼び出してインスタンスを作成する場合、ホスト名には小文字のみが含まれます。任意N/A任意
    ホスト名には大文字が含まれており、インスタンスにログインした後にホスト名を変更します。任意N/A必須
  • 解決策: インスタンスの再起動後にインスタンスのホスト名に大文字を保持するには、次の操作を実行します。
    1. インスタンスに接続します。

      詳細については、「接続方法」をご参照ください。

    2. 既存のホスト名を表示します。
      [testuser @ izbp193 ***** 3i161uynzzx ~]# ホスト名
      izbp193 ***** 3i16 1uynzzx 
    3. 次のコマンドを実行して、ホスト名を静的にします。
      hostnamectl set-hostname -- static iZbp193 ***** 3i16 1uynzzX
    4. 次のコマンドを実行して、更新されたホスト名を表示します。
      [testuser @ izbp193 ***** 3i161uynzzx ~]# hostname
      iZbp193 ***** 3i16 1uynzzX 
  • 影響を受けるカスタムイメージを使用している場合は、cloud-initを最新バージョンに更新してから、別のカスタムイメージを作成することをお勧めします。 この問題を防ぐために、新しいカスタムイメージを使用してインスタンスを作成できます。 詳細については、「cloud-initのインストール」および「インスタンスからカスタムイメージを作成する」をご参照ください。

CentOS 6.8: NFSクライアントと共にインストールされたインスタンスが応答しない

  • 問題の説明: NFSクライアントと共にインストールされたCentOS 6.8インスタンスは応答せず、再起動する必要があります。
  • 原因: オペレーティングシステムのカーネルバージョンが2.6.32-696から2.6.32-696.10の範囲のインスタンスでNFSサービスを使用すると、NFSクライアントは、通信遅延のために不具合が発生した場合にTCP接続を終了しようとします。 NFSサーバがNFS要求に応答するのが遅い場合、NFSクライアントによって開始された接続は、延長された時間期間にわたってFIN_WAIT2状態のままであり得る。 ほとんどの場合、接続はタイムアウトし、接続がFIN_WAIT2状態に入ってから1分後に閉じられます。 次いで、NFSクライアントは、新しい接続を開始することができる。 ただし、カーネルバージョン2.6.32-696から2.6.32-696.10には、TCP接続の確立に問題があります。 その結果、接続はFIN_WAIT2状態のままであり、NFSクライアントはTCP接続を回復することができず、新しいTCP接続を開始することができません。 これによりリクエストがフリーズし、問題を解決する唯一の方法はインスタンスを再起動することです。
  • 影響を受ける画像: centos_6_08_32_40G_alibase_20170710.vhdとcentos_6_08_64_20G_alibase_20170824.vhd。
  • 解決策: yum updateコマンドを実行して、カーネルを2.6.32-696.11以降に更新します。
    重要 インスタンスで操作を実行する前に、スナップショットを作成してデータをバックアップする必要があります。 詳細については、「ディスクのスナップショットの作成」をご参照ください。

Debian 9.6: クラシックネットワークタイプのインスタンスにネットワーク構成の問題がある

  • 問題の説明: Debian 9パブリックイメージから作成されたクラシックネットワークタイプのインスタンスはpingできません。
  • 原因: デフォルトでは、systemd-networkdサービスはDebian 9で無効になっています。 Debian 9パブリックイメージから作成されたクラシックネットワークタイプのインスタンスには、Dynamic Host Configuration Protocol (DHCP) を使用してIPアドレスを自動的に割り当てることはできません。
  • 影響を受けるイメージ: debian_9_06_64_20G_alibase_20181212.vhd。
  • 解決策: 次のコマンドを順番に実行します。
    systemctl enable systemd-networkd
    systemctl start systemd-networkd

Fedora CoreOS: Fedora CoreOSカスタムイメージから作成されたインスタンスのホスト名は有効になりません

  • 問題の説明: Fedora CoreOSイメージを使用してインスタンスaを作成した後、インスタンスAからFedora CoreOSカスタムイメージを作成し、そのカスタムイメージを使用してインスタンスBを作成します。

    たとえば、Fedora CoreOSオペレーティングシステムを実行するインスタンスaからFedora CoreOSカスタムイメージを作成し、インスタンスAのホスト名をtest001に設定します。 次に、カスタムイメージからインスタンスBを作成し、インスタンスBのホスト名をtest002に設定します。 インスタンスBが作成されて接続された後、インスタンスBのホスト名はtest001のままですが、test002のままです。

  • 原因: Alibaba Cloudが提供するFedora CoreOSパブリックイメージは、Fedora CoreOSが提供するIgnitionを使用してインスタンス設定を初期化します。 Ignitionは、Fedora CoreOSおよびRHEL CoreOSが起動時にinitramfsのディスクを管理するために使用するユーティリティです。 Fedora CoreOSインスタンスが初めて起動すると、ignitionのcoreos-Ignition-firstboot-complete.service/boot/ignition.firstbootファイルが存在するかどうかを確認し、インスタンス設定を初期化するかどうかを決定します。 /boot/ignition.firstbootファイルが存在する場合、システムはインスタンス設定 (ホスト名設定を含む) を初期化し、/boot/ignition.firstbootファイルを削除します。

    Fedora CoreOSインスタンスは、Fedora CoreOSカスタムイメージの作成に使用される前に、少なくとも1回起動されている必要があります。 インスタンスが初めて起動すると、インスタンスのイメージから /boot/ignition.firstbootファイルが削除されます。 したがって、インスタンスから作成されたFedora CoreOSカスタムイメージには、/boot/ignition.firstbootファイルは含まれません。 Fedora CoreOSカスタムイメージから初めて作成されたインスタンスが起動すると、システムはインスタンス設定を初期化しません。 この場合、インスタンスのホスト名は変更されません。

  • 解決策:
    説明 Fedora CoreOSインスタンスに保存されているデータのセキュリティを確保するため、インスタンスのスナップショットを作成することを推奨します。 インスタンスでデータ例外が発生した場合、スナップショットを使用してディスクを通常の状態に戻すことができます。 詳細については、「ディスクのスナップショットの作成」をご参照ください。
    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
    イグニッションの設定方法については、「プロビジョニング後にイグニッションを0600および削除する権限の変更 /ブート /イグニッション /config.ign」をご参照ください。

openSUSE 15: カーネルの更新により、起動中にシステムがフリーズする可能性があります

  • 問題の説明: openSUSEカーネルバージョンが4.12.14-lp151.28.52-defaultに更新されると、特定のCPUタイプを持つインスタンスが起動中にフリーズする可能性があります。 既知のCPUタイプはIntelです®Xeon®CPU E5-2682 v4 @ 2.50GHz。 コールトレースのデバッグ結果を次のコードに示します。
    [ 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] トレースを呼び出す:
    [0.901281] cpuidle_enter_state + 0x 6f/0x2e0
    [0.901281] do_idle + 0x18 3/0x1e0
    [0.901281] cpu_startup_entry + 0x 5d/0x60
    [0.901281] start_secondary + 0x1b 0/0x200
    [0.901281] secondary_startup_64 + 0xa 5/0xb0
    [0.901281] コード: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 00 0f 1f 84 00 00 00 00 00 00 90 31 d2 65 48 8b 34 25 6c 01 00 00 48 89 f0 <0f> 01 c8 0f 84 00 00 00 00 00 00 00 00 00 00 1f 1f 84 00 00 00 00 00 00 00 * ** 
  • 原因: 新しいカーネルバージョンがCPUマイクロコードと互換性がありません。 詳細については、「起動中のフリーズの問題」をご参照ください。
  • 影響を受けるイメージ: 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'
            [x$feature_platform_search_hint = xy ];
              search -- no-フロッピー -- fs-uuid -- set=root-hint='hd0,msdos1' 20f5f35a-fbab-4c9c-8532-bb6c66ce ****
            else
              search -- no-フロッピー -- fs-uuid -- set=root 20f5f35a-fbab-4c9c-8532-bb6c66ce ****
            fi
            echo 'Loading Linux 4.12.14-lp151.28.52-デフォルト...'
            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ビット: yum updateコマンドを実行してカーネルのバージョンを更新できない

  • 問題の説明: RHEL 8 64ビットオペレーティングシステムを実行しているECSインスタンスでyum updateコマンドを実行してカーネルバージョンを更新した後、インスタンスを再起動してもインスタンスオペレーティングシステムのカーネルバージョンは変更されません。
  • 原因: RHEL 8 64ビットオペレーティングシステムでは、grub2環境変数を格納する /boot /GRUB2 /grubenvファイルのサイズが1,024バイトではありません。 その結果、カーネルのバージョンを更新することはできません。
  • 解決策: カーネルバージョンを更新した後、新しいカーネルバージョンをデフォルトの起動バージョンに設定します。 次の操作を実行します。
    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コマンドを実行して、手順iiで取得したカーネル起動パラメーターの値をkerneloptsの値に設定します。
      grub2-editenvセットkernelopts="root=UUID=0dd6268d-9bde-40e1-b010-0d3574b4 **** ro crashkernel=auto net.ifnames=0 vga=792 console=tty0 console=ttyS0,115200n8 noibrs nosmt"
    7. 次のコマンドを実行してインスタンスを再起動し、新しいカーネルバージョンを有効にします。
      reboot

SUSE Linux Enterprise Server: SMTサーバーに接続できません

  • 問題の説明: 有料のAlibaba CloudイメージをSUSE Linux Enterprise ServerまたはSUSE Linux Enterprise Server for SAPで使用すると、同時マルチスレッド (SMT) サーバーで接続タイムアウトなどの接続エラーが発生することがあります。 SMTサーバーのコンポーネントをダウンロードまたは更新すると、次のようなエラーメッセージが返されます。
    • 登録サーバーから「このサーバーはこのサービスへのアクセスが許可されていることを確認できませんでした」 (500)
    • サービス 'SMT-http_mirrors_cloud_aliyuncs_com 'ロケーションのリポジトリインデックスファイルの取得に関する問題 ****
  • 影響を受けるイメージ: SUSE Linux Enterprise ServerおよびSUSE Linux Enterprise Server for SAP
  • 解決策: SMTを再度登録して有効にします。
    1. 次のコマンドを順番に実行して、SMTを登録およびアクティブ化します:
      SUSEConnect -d
      SUSEConnect-クリーンアップ
      systemctl restart guestregister 
    2. 次のコマンドを実行してSMTがアクティブ化されているかどうかを確認します。
      SUSEConnect -s
      SMTがアクティブ化されている場合、次のようなコマンド出力が返されます。
      [{"identifier":"SLES_SAP","version":"12.5","arch":"x86_64","status":"Registered"}]

SLES 12 SP5: カーネルの更新により、起動中にシステムがフリーズする可能性があります

  • 問題の説明: 以前のカーネルバージョンがSLES 12 SP5に更新された場合、またはSLES 12 SP5のカーネルを更新した場合、特定のCPUタイプを持つインスタンスが起動中にフリーズすることがあります。 これらの既知のCPUタイプはIntel ®Xeon®CPU E5-2682 v4 @ 2.50GHzインテル®Xeon®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] トレースを呼び出す:
    [0.901281] cpuidle_enter_state + 0x 6f/0x2e0
    [0.901281] do_idle + 0x18 3/0x1e0
    [0.901281] cpu_startup_entry + 0x 5d/0x60
    [0.901281] start_secondary + 0x1b 0/0x200
    [0.901281] secondary_startup_64 + 0xa 5/0xb0
    [0.901281] コード: 6c 01 00 0f ae 38 0f ae f0 0f 1f 84 00 00 00 00 00 00 0f 1f 84 00 00 00 00 00 00 90 31 d2 65 48 8b 34 25 6c 01 00 00 48 89 f0 <0f> 01 c8 0f 84 00 00 00 00 00 00 00 00 00 00 1f 1f 84 00 00 00 00 00 00 00 * ** 
  • 原因: 新しいカーネルバージョンがCPUマイクロコードと互換性がありません。
  • 解決策: /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'
            [x$feature_platform_search_hint = xy ];
              search -- no-フロッピー -- fs-uuid -- set=root-hint='hd0,msdos1' fd7bda55-42d3-4fe9-a2b0-45efdced ****
            else
              search -- no-フロッピー -- fs-uuid -- set=ルートfd7bda55-42d3-4fe9-a2b0-45efdced ****
            fi
            echo 'Linux 4.12.14のロード-122.26-デフォルト...'
            linux /boot/vmlinuz-4.12.14-122.26-default root=UUID=fd7bda55-42d3-4fe9-a2b0-45efdced **** net.ifnames=0 console=tty0 console=ttyS0,115200n8 comitigations=auto splash=silent quiet showopts idle=nomwait
            echo 'Loading initial ramdisk ...'
            initrd /boot/initrd-4.12.14-122.26-default
    }