【ITニュース解説】Four Debian 13 Boxes, One Brief: 1,923 Packages on Metal, 328 in the Cloud, and the Backup GPT Header Nobody Relocated

今回の分析は、オープンソースのオペレーティングシステムであるDebian 13を、物理的なノートパソコンと、Amazon Web Services (AWS)、Google Compute Engine (GCE)、Microsoft Azureという主要な3つのクラウドサービス上で動作させた際の、それぞれのシステム構成と挙動の違いを探るものだ。特に、それぞれの環境が自身のハードウェア情報をどれだけ認識し、どのようなツールをデフォルトで提供しているかに焦点を当てている。システムエンジニアを目指す上で、OSがどのような環境で動くかによって、その挙動や利用できる機能が大きく異なることを理解する上で重要な情報となる。

まず、物理マシンにインストールされたDebian 13には1923個ものソフトウェアパッケージが含まれていたのに対し、クラウド環境のDebian 13イメージには、それぞれ328個、337個、350個と、大幅に少ないパッケージしか含まれていなかった。これは、クラウドサービスが通常、「必要最低限の構成でOSを提供し、必要なソフトウェアはユーザーが後から追加する」という異なる設計思想に基づいているためである。これにより、クラウドインスタンスの起動が速くなり、リソース消費も抑えられる。

次に、各マシンがNVMeという高速なストレージデバイスから起動しているにもかかわらず、NVMeドライブの健康状態をチェックするための重要なコマンドラインツールであるnvme-cliが、AWSとAzureのイメージではデフォルトでインストールされていなかった点が注目される。GCEはnvme-cliだけでなく、システムハードウェア情報を詳細に読み取るdmidecodeも標準で提供しており、他のクラウドよりも多くの診断ツールを最初から搭載していることがわかる。また、クラウド環境ではファームウェア関連のパッケージは一切含まれておらず、ファームウェアのロード試行も記録されない。これは故障を意味するのではなく、クラウド環境では物理的なハードウェアのファームウェア管理は、仮想化を実現するソフトウェアであるハイパーバイザー側が行うため、ゲストOS（仮想マシン内のOS）には不要だからである。

さらに、ディスクのパーティション管理に関する興味深い違いが明らかになった。AWSとGCEの両方で、システムの起動時に「GPT（GUIDパーティションテーブル）のバックアップヘッダがプライマリと一致しない」という同じ警告メッセージが表示された。GPTはディスクのパーティション情報が記録される場所であり、データの安全性を高めるために通常、ディスクの先頭にプライマリ、末尾にバックアップのヘッダを持つ。この警告は、ディスクのサイズが後から拡張された際に、プライマリGPTは更新されたが、ディスクの末尾にあるバックアップGPTヘッダがその変更に合わせて移動されなかったために発生する。しかし、AWSではこの警告が修正されずに残り続けるのに対し、GCEでは同じ起動処理の中で、Googleが提供するgce-disk-expandのようなディスク管理ツールによって自動的に修正された。これは、同じ警告メッセージであっても、それぞれのクラウドプラットフォームの構成や提供ツールによって、それが「ユーザーが手動で修正すべき欠陥」であるか、「システムが自動修正する一時的な現象」であるかが異なることを示している。この違いは、OSの外部からログメッセージを読み取るだけでは判断できず、実際にOS内部でどのようなツールが利用可能か、どのような処理が行われているかを確認しないとわからない。

また、セキュリティ面では、Azureの環境でのみ「Retbleed」というCPUの投機的実行脆弱性が報告された。これは、Azureが仮想マシンに提供するハイパーバイザー側のCPUマイクロコードに起因するものであり、ゲストOS内部で修正できる問題ではない。一方で、AWSとGCEではこの脆弱性は報告されなかった。これは、クラウドプラットフォームごとのハードウェア構成や仮想化技術の違いが、セキュリティ上のリスクに影響を与える例である。

クラウド環境では、物理マシンでは利用できる特定のハードウェア情報や機能が、ハイパーバイザーによって提供されなかったり、マスクされたりするケースがある。例えば、ハードウェアセンサー情報を提供する/sys/class/hwmonや、CPUの電力消費を制御するRAPLの機能は、クラウド環境では利用できなかったり、限定的だったりする。特にCPUのマイクロコードリビジョンは、AWSでは実際の値が報告されるのに対し、GCEとAzureでは0xffffffffとマスクされ、実際の情報が得られない。これは、ハイパーバイザーがゲストOSに提示するハードウェア情報の範囲を制御しているためである。

このような違いを正確に把握するためには、OSの外部からコマンドを実行するだけでなく、OS内部にログインし、その環境がデフォルトで提供するツール（例えば、パッケージ管理ツールのdpkg）を使って調査することが非常に重要であると強調されている。特に、command -vのようなコマンドパス（PATH環境変数）に依存するツールではなく、dpkgのようにインストールされているパッケージ自体を確認する方法が推奨される。これは、システム管理用のコマンドが格納されるパス（/usr/sbinなど）が、ログインユーザーのデフォルトのPATHに含まれていないために、実際にはインストールされているツールが「見つからない」と誤って判断されるケースがあるためだ。この分析では、AIアシスタントのClaude Codeを各マシンにインストールし、それぞれのマシンに「自身のハードウェアを分析せよ」という統一された指示を与えることで、これらの内部情報を効率的に引き出した。

多くの差異が見られる一方で、全ての環境に共通する安定性も確認された。全てのシステムでカーネルに大きな問題はなく、重要なシステムサービスも正常に動作し、全てのPCIデバイスには適切なドライバがロードされていた。また、クラウド環境ではsystemd-ssh-generatorがAF_VSOCKという特定のネットワーク機能のプローブに失敗するという共通のログが出力されるが、これはクラウド環境がvsock機能を提供していないためであり、システムの安定性には影響しない。

最終的に、この分析は、単一のOSイメージであっても、それが動作する基盤（物理マシンか、どのクラウドプラットフォームか）によって、提供されるツール、ハードウェア情報の認識、そして潜在的な問題の挙動が大きく異なることを明らかにしている。特に、同じ起動メッセージや警告であっても、その背後にある意味や必要とされる対応がプラットフォームによって異なるため、システムを運用する際には、OS内部から詳細な情報を収集し、多角的に分析することの重要性が強く示されている。