GitHubの公式ドキュメント更新「Add note for derived Linux distros (Linux Mint) in package manager troubleshooting」でまず確認すべき点は、GitHub本体の機能変更ではなく、GitHub上で管理されているMicrosoft Learn系ドキュメントのトラブルシューティング追記であることです。
今回の更新は、Linux MintのようなUbuntu/Debian派生ディストリビューションで.NET関連パッケージをAPTから導入する際、/etc/os-release の値をそのまま使うとMicrosoft packages serverのURLが合わず、404エラーになる可能性を明記したものです。結論として、運用担当者はインストールスクリプト内の $ID と $VERSION_ID を確認し、必要に応じて派生元のUbuntuまたはDebianの値に読み替える準備をしておくべきです。(GitHub)
GitHubの公式ドキュメント更新で何が変わったか
2026年4月28日のコミットでは、dotnet/docs リポジトリ内の.NET Linuxインストール関連ドキュメントに、Linux Mintなどの派生ディストリビューション向けの注意書きが追加されました。変更対象は package-manager-failed-to-find-deb-classic.md と package-manager-failed-to-find-deb-new.md の2ファイルで、差分としては6行の追加です。(GitHub)
追加された要点は次のとおりです。
| 確認項目 | 変更前に見落としやすかった点 | 今回の更新で明確になった点 |
|---|---|---|
| 対象環境 | Ubuntu/Debian派生OSでも同じ手順を使えると思い込みやすい | Linux Mintなどでは /etc/os-release の値がMicrosoft側のディレクトリ名と一致しない場合がある |
| 主なエラー | wget や apt-get update の失敗を一時的な通信障害と誤解しやすい | $ID と $VERSION_ID が原因で404になる可能性がある |
| 対応方法 | OS名とバージョンをそのまま使う | 派生元のUbuntuまたはDebianのバージョンを確認して使う |
| 具体例 | Linux Mint 22を「mint 22」として扱う | Linux Mint 22はUbuntu 24.04ベースのため、ubuntu と 24.04 を使う例が示された |
重要なのは、これはGitHub Actions、GitHub API、GitHub Enterprise Cloudの仕様変更ではないという点です。Microsoft Learnの.NETドキュメントはGitHub上でソースが管理され、IssueやPull Requestを通じて改善できる構成になっています。今回の更新も、GitHubを通じて公開されたドキュメント改善として捉えるのが正確です。(Microsoft Learn)
なぜLinux Mintなどで404エラーが起きるのか
.NETのLinux向けインストール手順では、OS情報を取得するために次のような処理が使われます。
source /etc/os-releaseその後、取得した $ID と $VERSION_ID を使って、Microsoft packages server上の設定ファイルを参照します。
wget https://packages.microsoft.com/config/$ID/$VERSION_ID/prod.listUbuntuそのものなら、たとえば $ID が ubuntu、$VERSION_ID が 24.04 となり、想定されるパスに近い形になります。しかしLinux Mintのような派生ディストリビューションでは、/etc/os-release が派生OS側の名前やバージョンを返すことがあります。
その結果、スクリプトが次のような存在しないパスを見に行く可能性があります。
https://packages.microsoft.com/config/linuxmint/22/prod.list公式更新では、このような場合に派生元のUbuntuまたはDebianを確認し、その値を使うよう明記されました。Linux Mint 22の例では、$ID に ubuntu、$VERSION_ID に 24.04 を使う考え方が示されています。(GitHub)
影響を受けやすい環境
今回のGitHub公式ドキュメント更新は、すべてのGitHub利用者に直接影響するものではありません。影響が出やすいのは、Linux MintやUbuntu/Debian派生OS上で、Microsoftのパッケージフィードを使って.NET SDK、.NET Runtime、ASP.NET Core Runtimeなどを導入している環境です。
| 利用シーン | 影響度 | 確認すべきポイント |
|---|---|---|
| 開発者のLinux Mint端末 | 高 | apt で.NETを入れる手順が404になっていないか |
| GitHub Actionsのself-hosted runner | 中〜高 | runner OSが標準Ubuntuではなく派生ディストリビューションか |
| クラウドVMの初期構築スクリプト | 高 | cloud-init、Ansible、Shell Scriptで $ID / $VERSION_ID をそのまま使っていないか |
| 社内標準の開発者向けセットアップ手順 | 高 | 「Linuxなら同じ手順」として配布していないか |
| コンテナイメージのビルド | 中 | ベースイメージがUbuntu/Debian派生で、Microsoftリポジトリを追加していないか |
特に注意したいのは、エラーが「パッケージが存在しない」ように見える点です。実際にはパッケージ名ではなく、リポジトリ設定ファイルの取得先URLが誤っている場合があります。
まず確認すべきコマンド
Linux Mintなどの環境で.NETパッケージのインストールに失敗した場合は、いきなり再インストールするのではなく、OS検出値と参照先URLを確認します。
cat /etc/os-release次に、スクリプトで使われる値を確認します。
. /etc/os-release
printf 'ID=%s\nVERSION_ID=%s\n' "$ID" "$VERSION_ID"Linux Mintなどで派生元の情報が別ファイルにある場合は、次のような確認も役立ちます。
cat /etc/upstream-release/lsb-release 2>/dev/null || trueただし、環境によってファイル構成は異なる可能性があります。最終的には、ディストリビューションの公式リリース情報、社内の標準OSイメージ定義、またはベースイメージのDockerfileを確認し、どのUbuntu/Debianバージョンを基にしているかを特定してください。
修正時の基本方針
修正の基本は、/etc/os-release 自体を書き換えることではありません。OS情報ファイルを編集すると、他のツールやパッケージ管理、監視エージェントの判定に副作用が出る可能性があります。
実務では、インストールスクリプト側でMicrosoft packages serverに渡す値を明示的に指定するほうが安全です。
たとえばLinux Mint 22がUbuntu 24.04ベースであることを確認できた場合は、次のように変数を分けて扱います。
repo_id="ubuntu"
repo_version="24.04"
wget "https://packages.microsoft.com/config/${repo_id}/${repo_version}/prod.list" -O prod.list既存スクリプトが次のように書かれている場合は注意が必要です。
source /etc/os-release
wget https://packages.microsoft.com/config/$ID/$VERSION_ID/prod.list派生ディストリビューションも対象にするなら、次のように上書き可能な形にしておくと運用しやすくなります。
source /etc/os-release
repo_id="${MS_REPO_ID:-$ID}"
repo_version="${MS_REPO_VERSION:-$VERSION_ID}"
wget "https://packages.microsoft.com/config/${repo_id}/${repo_version}/prod.list" -O prod.listLinux Mint 22向けに実行する場合は、環境変数で明示できます。
MS_REPO_ID=ubuntu MS_REPO_VERSION=24.04 ./install-dotnet-packages.shこの形にしておくと、将来別の派生ディストリビューションや社内カスタムイメージが増えても、スクリプト本体を何度も書き換えずに済みます。
「404」と「Unable to locate package」は分けて考える
トラブルシューティングでは、エラーの種類を混同しないことが重要です。
| エラーの見え方 | 主な原因 | 対応の方向性 |
|---|---|---|
404 Not Found | Microsoft packages server上のパスが存在しない | $ID / $VERSION_ID を派生元の値に読み替える |
Unable to locate package | パッケージリストに対象パッケージがない | フィード設定、対象.NETバージョン、アーキテクチャを確認する |
Some packages could not be installed | 依存関係やリポジトリ混在の問題 | Ubuntu feed、Microsoft feed、backportsの混在を確認する |
Failed to fetch | ミラー同期中、ネットワーク、リポジトリ設定不備 | 時間を置くか、URL・署名鍵・プロキシを確認する |
公式ドキュメントでも、Ubuntuの.NET導入では利用するフィードの選択が重要で、複数のパッケージリポジトリから.NETパッケージを混在させないよう注意されています。Ubuntu feed、.NET backports、Microsoft feedのどれを使うかは、OSバージョン、必要な.NETバージョン、ほかのMicrosoft製品との関係で判断する必要があります。(Microsoft Learn)
運用担当者が見直すべきポイント
今回の更新を受けて、developers、cloud admins、solution architects、technical decision makersが確認すべきポイントは次の5つです。
OS検出を前提にしすぎていないか
source /etc/os-release は便利ですが、派生ディストリビューションでは「パッケージ提供元が期待するOS名」と「実行環境が名乗るOS名」が一致しないことがあります。
社内のセットアップスクリプトで次のような文字列を検索してください。
grep -R "packages.microsoft.com/config/\$ID/\$VERSION_ID" .
grep -R "source /etc/os-release" .
grep -R "/etc/os-release" .見つかった箇所では、派生OSを考慮した上書き変数を用意するか、対象OSを明示的に限定するのが安全です。
Linux Mintを正式なUbuntuとして扱っていないか
Linux MintはUbuntuベースのエディションを持ちますが、運用上は「Ubuntuと完全に同じ」とは扱わないほうが安全です。
今回の注記は、Linux MintでUbuntu向けの値を使う例を示していますが、これは「Linux MintがUbuntuとして公式サポートされた」という意味ではありません。あくまで、Microsoft packages serverのディレクトリ指定で派生元の値を使うというトラブルシューティング上の対処です。
パッケージフィードを混在させていないか
.NET SDKやRuntimeを入れる場合、Ubuntu標準フィード、Ubuntu backports、Microsoft feedが混在すると、バージョン解決やアップデートで問題が起きることがあります。Microsoft LearnのUbuntu向けガイドでも、複数リポジトリから.NETパッケージを混ぜないことが推奨されています。(Microsoft Learn)
確認には次のコマンドが使えます。
apt-cache policy dotnet-sdk-8.0
apt-cache policy dotnet-sdk-9.0
apt-cache policy aspnetcore-runtime-8.0出力に複数のリポジトリが並ぶ場合は、どのフィードを標準にするかを決めてから修正してください。
アーキテクチャ制限を確認しているか
404を解消しても、対象アーキテクチャにパッケージが提供されていなければインストールは成功しません。Debian向けの公式ドキュメントでは、Microsoft package feedで提供される.NETパッケージのアーキテクチャが.NETバージョンによって異なることが示されています。たとえば.NET 10ではx64とArm64、.NET 9と.NET 8ではx64のみという説明があります。(Microsoft Learn)
環境側では次を確認します。
dpkg --print-architecture
uname -mArm環境や特殊なCPUアーキテクチャでは、APTではなく install-dotnet.sh や手動インストールのほうが適切な場合があります。
CI/CDと開発端末で手順が分かれていないか
開発者のLinux Mint端末では回避できているのに、CI/CDのself-hosted runnerでは失敗する、といった差分も起きやすいです。
確認すべきなのは、次の3点です。
| 確認対象 | よくある差分 | 対応 |
|---|---|---|
| 開発端末 | GUIのソフトウェア管理ツール経由で.NETを導入している | CLI手順とフィードを揃える |
| self-hosted runner | 初期化スクリプトが古い | $ID / $VERSION_ID の読み替えを追加する |
| クラウドVM | イメージ更新後にOSバージョンが変わる | イメージビルド時にリポジトリURLをテストする |
移行準備としてやるべきこと
今回のGitHub公式ドキュメント更新を受けて、今すぐ大規模な移行が必要とは限りません。ただし、Linux Mintや派生OSを開発・検証環境に使っている組織では、次の順番で棚卸しするとトラブルを予防できます。
| 優先度 | 作業 | 目的 |
|---|---|---|
| 高 | .NET インストールスクリプトを検索する | 影響範囲を把握する |
| 高 | $ID / $VERSION_ID を使う箇所を特定する | 404リスクを見つける |
| 高 | Linux Mintなど派生OSの利用有無を確認する | 対象端末・runner・VMを絞り込む |
| 中 | フィード方針を文書化する | Ubuntu feed、backports、Microsoft feedの混在を避ける |
| 中 | ステージング環境で再実行する | 修正が既存端末に悪影響を与えないか確認する |
| 低 | エラー時のログを改善する | 将来の調査時間を短縮する |
ログには、少なくとも次の情報を出すようにしておくと原因切り分けが早くなります。
echo "Detected OS: ID=${ID}, VERSION_ID=${VERSION_ID}"
echo "Repository target: ${repo_id}/${repo_version}"
echo "Architecture: $(dpkg --print-architecture)"失敗しやすいポイント
/etc/os-release を編集してしまう
一時的にインストールを通すために /etc/os-release を書き換えるのは避けるべきです。OS識別に依存する他のツール、監視エージェント、セキュリティ製品、パッケージ管理に影響する可能性があります。
対応は、OSファイルの改変ではなく、インストールスクリプト側の変数上書きで行います。
Linux Mintのバージョン番号をUbuntuのバージョン番号として使う
Linux Mint 22だからといって、Microsoft packages serverに 22 を指定するとは限りません。公式更新の例では、Linux Mint 22はUbuntu 24.04ベースとして扱い、ubuntu と 24.04 を使う考え方が示されています。(GitHub)
404が直っただけで完了と判断する
リポジトリ設定ファイルを取得できても、目的の.NET SDKやRuntimeがそのフィード、OSバージョン、CPUアーキテクチャに提供されているとは限りません。
最後に必ず次を確認してください。
sudo apt-get update
apt-cache policy dotnet-sdk-8.0
apt-cache policy dotnet-sdk-9.0
dotnet --list-sdks
dotnet --list-runtimes.NETのインストール済みSDKやRuntimeは、公式ドキュメントでも dotnet --list-sdks と dotnet --list-runtimes で確認する方法が案内されています。(Microsoft Learn)
GitHub Actions利用者はどう考えるべきか
GitHub Actionsを使っている場合でも、影響を受けるかどうかはrunnerの種類で変わります。
標準的なGitHub-hosted runnerだけを使っている場合、この更新を理由にワークフローを変更する必要は通常ありません。一方で、Linux MintやUbuntu/Debian派生OSを使ったself-hosted runner、社内VM、クラウド上のカスタムイメージで.NETをAPTインストールしている場合は、今回の注記がそのまま実務上の確認ポイントになります。
ワークフロー内で次のような処理をしている場合は、見直し対象です。
- name: Install .NET packages
run: |
source /etc/os-release
wget https://packages.microsoft.com/config/$ID/$VERSION_ID/prod.list派生OSを使う可能性があるなら、runner側の環境変数でリポジトリ対象を明示するほうが安全です。
- name: Install .NET packages
env:
MS_REPO_ID: ubuntu
MS_REPO_VERSION: "24.04"
run: |
source /etc/os-release
repo_id="${MS_REPO_ID:-$ID}"
repo_version="${MS_REPO_VERSION:-$VERSION_ID}"
echo "Using Microsoft repo target: ${repo_id}/${repo_version}"今回の更新から得られる実務上の教訓
今回のGitHub公式ドキュメント更新は小さな追記ですが、運用面では重要です。Linuxのパッケージインストールでは、OSが返す識別子と、パッケージ提供側が用意しているディレクトリ体系が一致するとは限りません。
特に、開発端末ではLinux Mint、CIではUbuntu、検証環境ではDebian派生OSといった構成になっている組織では、「Linux向け手順」として一括りにせず、次のように分けて管理するのが現実的です。
| 管理単位 | 推奨される管理方法 |
|---|---|
| 公式Ubuntu/Debian | 公式ドキュメントの対象バージョン別手順を使う |
| Linux Mintなどの派生OS | 派生元のUbuntu/Debianバージョンを明示する |
| CI/CD runner | runnerイメージごとにリポジトリURLをテストする |
| 社内標準スクリプト | $ID / $VERSION_ID を上書き可能にする |
| 本番VM | フィード混在とアーキテクチャ制限を事前確認する |
まとめ：次に取るべき行動
GitHubの公式ドキュメント更新「Add note for derived Linux distros (Linux Mint) in package manager troubleshooting」で確認すべき点は、Linux Mintなどの派生ディストリビューションで、/etc/os-release の $ID と $VERSION_ID をそのままMicrosoft packages serverのURLに使っていないかです。
まず、社内スクリプトやCI/CD設定から packages.microsoft.com/config/$ID/$VERSION_ID を検索してください。該当箇所があり、実行環境にLinux Mintなどの派生OSが含まれる場合は、派生元のUbuntuまたはDebianの値を明示できるよう修正します。あわせて、利用する.NETパッケージフィード、CPUアーキテクチャ、既存パッケージの取得元を確認すれば、404だけでなく「パッケージが見つからない」「依存関係が解決できない」といった二次トラブルも防ぎやすくなります。
コメント