コンテンツにスキップ

パーティションチートシート

2025/3/9時点のpartitioning-cheatsheetの翻訳

警告: Apple_APFS_Recovery パーティションは絶対に削除しないでください。

diskutil で `Apple_APFS_Recoveryと表示されるディスクの最後のパーティションには重要なシステム回復コンポーネントが含まれています。 ** 誤ってこのパーティションを削除してしまうと、macOS のアップグレードは機能しなくなり、システムに関するその他の問題は起動不能のままとなり、工場出荷時の復元と完全なワイプが必要となります。** マシンを完全にワイプせずにこのパーティションを復元するのは、非常に面倒です。どんなことがあっても、このパーティションはいじらないでください。

Asahi Linux のインストーラーにはパーティション削除コードが一切含まれておらず、また未加工のパーティションテーブルにアクセスすることもないため、インストーラーが単独でこのような事態を引き起こすことはあり得ません。このような状況に陥った場合、（Linux や macOS/recoveryOS から）知らないうちに自分でパーティションを 削除してしまったか、Appleのバグが原因です。

注意: 私たちは近いうちにインストーラにアンインストール/クリーンアップのオプションを追加する予定ですが、定義上、常に Asahi Linuxのバニラインストールという共通のケースに対してのみ動作が保証される簡易ツールです。もし自身でパーティション管理を したり、他のディストリビューションをインストールする場合は、正しくクリーンアップするためにはこのような手動での方法を 知っておく必要があります。

はじめに

macOS でのパーティション管理は混乱しやすいです。これが説明の助けになれば幸いです。

注意: 近いうちにインストーラにアンインストール/クリーンアップのオプションを追加する予定ですが、定義上、常に Asahi Linuxのバニラインストールと いう共通のケースに対してのみ動作が保証される簡易ツールです。もし自身でパーティション管理を したり、他のディストリビューションをインストールする場合は、 正しくクリーンアップするためにはこのような手動での方法を知っておく必要があります。

注意：Asahi Linuxを削除する場合、macOS をデフォルトの起動OSとして設定し直す必要があります。 macOS自体のシステム設定から行うか、 スタートアップオプションで Option キーを押しながら選択することで可能です。先にやっておかなくてもパソコンが壊れることはありませんが、 設定するまでは自動起動ができなくなるでしょう。スタートアップオプションの画面に正常に入れない場合は、ダブルタップ （電源ボタンを押す→離す→押し続ける）で起動してみてください。

ディスクユーティリティは使わないでください

macOS に同梱されているグラフィカルなディスクユーティリティは、1つ以上の APFS コンテナがあり、未パーティション領域がなく、すべての パーティションが正しい順序で並んでいて、外部パーティションがない、という些細な場合のみかろうじて機能します。FAT32/HFS パーティションの作成など、 表向きは『対応している』ことであっても、バグがあります。使わないでください。混乱させ、ありえない数字を表示し、間違ったことをします。 これは適切なディスク管理ツールとして意図されたものではありません。最も単純なタスクや状況しか処理できず、それ以外は完全に崩壊する、 薄っぺらなユーザーインターフェイスのフロントエンドなのです。

コマンドラインの diskutil は奇妙なインターフェースを持っており、理解するのが 難しいですが、少なくとも通常は正しく動作します。

全てがうまくいかなくなったら

Apple Silicon機器はbrick(訳注:起動不能,いわゆる文鎮化)できませんが、システムリカバリーを壊すと起動不能になることがあります。 これを解決するには、別のマシンを接続し、特別なDFUリカバリ手順を使ってUSB経由で復元する必要があります。 手元に別のMac(Intel動作)がある場合は、Appleの 公式文書に従ってください。ない場合は、代わりにidevicerestoreを使用することができます。そのための 簡単なガイドを紹介します。

OSのリカバリを壊してしまった場合、電源ボタンを押しながらでもブートループに陥ることがあります。この場合、マシンをシャットダウンし、電源ボタンを素早くダブルタップホールド(double-tap-hold) (押して、放して、押し続ける)をして起動してください。ノートパソコンの場合、起動ループから強制的にシャットダウンすることが できない場合があります。このような場合は、ループサイクル中にAppleロゴが消えた時点から3秒を数え、2連続で押して(double tap)してください。 これでシステムリカバリに入り、完全なDFUフラッシュを使わずにそこから修正することができます。

Apple Silicon の物理ディスクレイアウト
  • NVMe ドライブには名前空間があります。macOSでは disk0、Linuxでは nvme0n1 が主なものです。
  • 他のものは、カーネルパニックログなどに使用。これはかなり低レベルのものなので、気にする必要なし。これはNVMeのことで『ローレベルパーティション』みたいなもの。あまり深く考えないで
  • プライマリ名前空間はGPTパーティションテーブルとしてフォーマットされ、最近のほとんどのLinux/Windows/Intel Macシステムと同じ
  • GPTには、従来のパーティション（FAT32、HFS+、Linux...）またはAPFSコンテナが含まれる
  • APFSコンテナには、ディスク領域を共有する複数の論理ボリュームが含まれる
  • 各 Apple Silicon 機器は、2つの特別なシステム APFS コンテナ、ディスク上の最初のもの（iBoot システムコンテナ）およびディスク上の 最後のもの（システムリカバリー）を保持。これらは決して触らないように。これらの間にあるパーティションの作成/削除のみを行う

警告: Apple のツールの中には GPT パーティションテーブル内の未ソートパーティションを好まないものがあります。最初と最後のパーティションは そのままにしておく必要があります。なので、Linux からのほとんどのディスク管理操作は GPT にパーティションを追加してしまい、順番を 狂わせてしまいます。必ず修正してください。Linux の fdisk コマンドでは、x (エキスパートモードへ) → f (パーティションの順序を修正) → r (メインメニューへ) → w (変更を書き込んで終了) という手順で行うことができます。

macOS ディスク管理の基本

disk0はNVMeドライブです。disk0sN はその中の GPT パーティションです。N は安定したものではなく、macOS カーネルによって動的に 割り当てられます。GPT の物理的なスロットインデックスには 対応していませんし、ドライブ内のパーティションデータの物理的な順序にも対応していません。 パーティションを作成するときはいつでも、N は異なる番号に割り当てることができ、再起動時にすべての番号を変更することができます。

diskN (N >= 1) はディスクイメージや外部ディスクの可能性もありますが、より可能性が高いのは APFS コンテナ でしょう。 これはAppleがサブボリュームを表現するために考え出したハックです。このようなディスク内の『パーティション』は実際のパーティションではなく、 1つのAPFSコンテナ内のボリュームを表しているだけです。コンテナ自体は disk0 内の物理パーティションに存在します。つまり、APFSの操作では、 例えばdisk0s2とdisk1は同じ意味になり、前者はコンテナを物理パーティションで参照し、後者は仮想（合成）ディスク番号で参照することになります。

複数の macOS インストールで 1 つの APFS コンテナを共有することができます。各 OS は、System ボリュームと Data ボリュームの 2 つの 対になるサブボリュームからなる ボリュームグループ を持ちます。追加のボリュームがあり、Preboot、Recovery、VM、Updateです。 これらは、そのコンテナ内のすべてのOSで共有されます。必ずしもすべてが存在するわけではありません。

macOSのインストールはそれぞれ、recoveryOSの独自のコピーを持っています。それから、グローバルなシステムリカバリーOSと、（まれに）追加の システムフォールバックリカバリーOSがあります。

Asahi Linux のインストール

Asahi Linuxの場合、同じコンテナにmacOSと一緒にインストールすることはありません。なぜなら、そうするとLinux用のAPFS（まだ安定しておらず、 メインライン化もされていない）を使う必要があるからです。Linux用の通常のGPTパーティションを作成するだけです。Asahi LinuxもmacOSと 同じように、APFSコンテナにボリュームグループとしてインストールし、実際に起動できるようにする必要があります。これが『スタブmacOS』と 呼ばれるもので、Appleの世界とLinuxの世界を繋ぐものです。ブートローダパーティションとでも思ってください。このために macOS とコンテナを 共有することもできますが、エラーの可能性が低くなり削除も簡単になるので、そうしないことにしていますし、どのみちディスクのパーティションは既に切ってあります。

インストーラは(通常の Asahi Linux = Arch Linux ARM インストールの場合)3つのパーティションを作成します:

  • 2.5GB APFS コンテナ、マシンを起動するのに必要な iBoot/macOS の断片と recoveryOS のコピーが含まる
  • m1n1 stage 1 はここにインストール
  • 500MBのEFIシステムパーティション
  • m1n1 ステージ2、U-Boot、GRUB コアイメージはここ
  • Linux ext4 パーティションが残りの領域を埋める
  • GRUBモジュールとLinuxカーネル/initramfsはここ

アンインストールするには、この3つをすべて削除する必要があります。

Asahi Linux は、従来の UEFI システムとは異なり、インストールするインスタンスごとに EFI System Partition を作成するのが特徴です。 これを処理するために、OS がインストール/起動する正しい ESP を見つけるための特注のメカニズムがあります。これは、各 ESP が 2.5G スタブに 論理的に結びついており、すべてを 1 つのユニットとして扱い、ネイティブのブートピッカーを使って異なる OS (つまり ESP) を選択できるように すると、OS 管理が容易になるためです。2.5GB の APFS スタブコンテナとEFI システムパーティションとその後に作成されるルート/...パーティションを、 Apple Silicon システム内のオープンソース OS 用の論理的な『コンテナ』と考えるべきでしょう。ある意味、m1n1+U-Boot はあなたのマシンを UEFI システムに変え、インストールするたびに Apple Silicon Mac の中に新しい『仮想 UEFI 環境』 を作ることになります（注：これは VM ではありません）。

Asahi Linuxインストーラでパーティションを一覧表示

diskutil は非常にバロック的で、インストールされているOSを列挙するのは苦痛です。そこで、Asahi Linuxインストーラ自身が、最も重要なディスク情報を 理解しやすい形式に凝縮しようとします。通常通り実行し(curl https://alx.sh | sh)、この情報を見るだけなら何もせずに終了させることもできます。

以下は、Asahi Linuxをインストールした直後、まだインストールの第二段階を完了する前の例です:

Partitions in system disk (disk0):
  1: APFS [Macintosh HD] (380.00 GB, 6 volumes)
    OS: [B ] [Macintosh HD] macOS v12.3 [disk3s1, D44D4ED9-B162-4542-BF50-9470C7AFDA43]
  2: APFS [Asahi Linux] (2.50 GB, 4 volumes)
    OS: [ *] [Asahi Linux] incomplete install (macOS 12.3 stub) [disk4s2, 53F853CF-4851-4E82-933C-2AAEB247B372]
  3: EFI (500.17 MB)
  4: Linux Filesystem (54.19 GB)
  5: (free space: 57.19 GB)
  6: APFS (System Recovery) (5.37 GB, 2 volumes)
    OS: [  ] recoveryOS v12.3 [Primary recoveryOS]

  [B ] = Booted OS, [R ] = Booted recovery, [? ] = Unknown
  [ *] = Default boot volume

これが示すもの:

  • 1つのAPFSコンテナ（380GB）には、1つのmacOS 12.3インストール（「Macintosh HD」）を構成する6つのボリューム（リストされていない）が含まれる。注：『Macintosh HD』は実際にはシステムサブボリュームの名前で、これは macOS 自身がボリュームを表示する方法
  • もし、同じコンテナで他の macOS インストールがスペースを共有している場合、それは同じパーティションにある別の OS: 行として表示
  • disk3s1 はこの macOS システムの ボリューム であり、disk3 がこの APFS コンテナパーティションを表す仮想ディスクであることを意味
  • UUID はこの OS のボリュームグループ ID で、この OS の主要な識別子 (例えば、機器が見つけて起動する方法、bputil プロンプトでそれを選択する方法、Preboot と Recovery サブボリューム内の関連サブディレクトリ名、その他)
  • 4つのボリュームを含む1つのAPFSコンテナ（2.5GB）は実際にはAsahi Linuxブートローダーのスタブで、macOS 12.3をベースバージョンとして使用し、名前は 『Asahi Linux 』
  • インストールが完了していれば、m1n1ステージ1のバージョンが表示されるはず。しかし、そうではないので、電源ボタンを押して再起動し、インストールの第二段階を完了するまで、incomplete installと表示
  • disk4s2 はこのスタブのシステムの ボリューム で、つまり disk4 はこの APFS コンテナパーティションを表す仮想ディスク
  • EFIシステムパーティション(FAT32)
  • Linuxファイルシステムパーティション（今回はext4ですが、特定のFSは特定/表示されない）
  • いくつかの空き領域（パーティションされていない） - インストーラはこれを独自の 『パーティション』 として表現していることに注意
  • 代わりに diskutil は、物理ディスクの順番に従い直前のパーティションのパーティション識別子で空き領域を参照しようとするが、これは言うまでもなく非常に紛らわしく、エラーが発生しやすい。それ自身の番号を与えることがより理にかなっていると思っている
  • システムリカバリーパーティション（常に最後に存在）は、2つの APFS ボリュームを含み、recoveryOS（バージョン 12.3）のインスタンスが1つインストールされている
  • これに触れたくないですが、recoveryOSのバージョンを知ることは有用であるためこれを表示。フォールバックバージョンもあるかもしれない

現在、Macintosh HD OS ([B ]) で起動しているが、デフォルトの起動OSはAsahi Linux ([ *]) に設定されていることを知らせていることに注意して ください。もし、recoveryOSから起動した場合は、[R*] (デフォルトブートOSの一部であるrecoveryOSを起動)と表示されますが、最終的にシステムリカバリーへフ ォールバックした場合は、最後の行で [R ] recoveryOS... から起動マークが表示されます。

Asahi Linux のインストーラは iBoot システムコンテナパーティションを表示しませんが、システムリカバリーパーティションは表示されることに注意 してください。どのシステムリカバリーバージョンがあるかはわかります（ただし、何もできません）。また、物理ディスクパーティション番号も表示されません。

diskutil でパーティションの一覧を表示

diskutil listを使用します。上記と同じ設定だと、このようになります。

/dev/disk0 (internal):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                         500.3 GB   disk0
   1:             Apple_APFS_ISC ⁨⁩                        524.3 MB   disk0s1
   2:                 Apple_APFS ⁨Container disk3⁩         380.0 GB   disk0s2
   3:                 Apple_APFS ⁨Container disk4⁩         2.5 GB     disk0s5
   4:                        EFI ⁨EFI - ASAHI⁩             500.2 MB   disk0s4
   5:           Linux Filesystem ⁨⁩                        54.2 GB    disk0s7
                    (free space)                         57.2 GB    -
   6:        Apple_APFS_Recovery ⁨⁩                        5.4 GB     disk0s3

/dev/disk3 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +380.0 GB   disk3
                                 Physical Store disk0s2
   1:                APFS Volume ⁨Macintosh HD⁩            15.2 GB    disk3s1
   2:              APFS Snapshot ⁨com.apple.os.update-...⁩ 15.2 GB    disk3s1s1
   3:                APFS Volume ⁨Preboot⁩                 887.6 MB   disk3s2
   4:                APFS Volume ⁨Recovery⁩                798.7 MB   disk3s3
   5:                APFS Volume ⁨Data⁩                    157.1 GB   disk3s5
   6:                APFS Volume ⁨VM⁩                      20.5 KB    disk3s6

/dev/disk4 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +2.5 GB     disk4
                                 Physical Store disk0s5
   1:                APFS Volume ⁨Asahi Linux - Data⁩      884.7 KB   disk4s1
   2:                APFS Volume ⁨Asahi Linux⁩             1.1 MB     disk4s2
   3:                APFS Volume ⁨Preboot⁩                 63.6 MB    disk4s3
   4:                APFS Volume ⁨Recovery⁩                1.8 GB     disk4s4

これは、まずdisk0に存在する物理パーティションを順番に表示しています。

  • disk0 (タイプ "GUID_partition_scheme" として表示) は実際にはディスク全体 (500GB) を表しす
  • disk0s1 は iBoot システムコンテナ (タイプ Apple_APFS_ISC) で、インストーラーの出力には表示されない
  • これは実際にはもっとサブボリュームのあるAPFSコンテナですが、diskutil自身はその詳細も隠す
  • このコンテナにはシステムクリティカルな情報がたくさん入っているので、いじらない方がいい
  • disk0s2は最初のAPFSコンテナで、macOSのボリューム 『Macintosh HD』を格納
  • 『Container disk3』と表示されているのは、これが仮想/合成されたディスク disk3 として表示されていることを示す
  • disk0s5 は Asahi Linux のブートローダスタブ
  • パーティションインデックスの順番がおかしい！ 論理的には disk0s2 の後にあり、GPT でもその位置に存在。このパーティション番号は何の意味もなく、macOSがその日に割り当てたいと思ったものを使用
  • これは仮想ディスク disk4
  • disk0s4 は FAT32 EFI System Partition (タイプは EFI で、名前は EFI - ASAHI で表示: これらは切り捨てられるから)
  • disk0s7 はLinuxのルートパーティション（タイプは Linux filesystem と表示）
  • 次に空き容量
  • disk0s3はシステムリカバリーパーティション（タイプ Apple_APFS_Recovery ）
  • 本当に、これはいじらないで。これはOSが壊れたときにローカルで復旧する唯一の方法

この後、2つのAPFSコンテナがボリュームに分割され、それぞれが仮想ディスクとして存在することがわかります。disk3 と disk4 です。実際には、さらに2つあります。disk1 は iBoot システムコンテナ (バックは disk0s1) で、disk2 はシステムリカバリー (バックは disk0s3) ですが、これらは diskutil 出力では 隠されています。しかし、これらは diskutil の出力には表示されません。この番号付けはあなたにとって異なるかもしれませんし、実際にそうなることを忘れないでください。

これらのコマンドをやみくもにコピー＆ペーストしないでください

以下のすべての例では、上記の出力からディスク/パーティション番号を使用しています。自身のシステムに適した番号に置き換える必要があります。 これらはあなたにとって異なるものでしょう。警告されています。

diskutil でパーティションを削除する

パーティションの削除は、APFS パーティションと非 APFS パーティションで 異なる 動作をします。

APFS コンテナの削除

Asahi Linux* の APFS コンテナを削除するには、以下のいずれかの形式を使用します:

diskutil apfs deleteContainer disk4

diskutil apfs deleteContainer disk0s5

最初のものは仮想ディスクで、2番目のものは物理パーティションで識別されます。正しい番号を使用している限り、これらは全く同等であり同じ結果になります。

他のパーティションの削除

EFIとLinuxのパーティションを削除するには、次のようにします:

diskutil eraseVolume free free disk0s4
diskutil eraseVolume free free disk0s7

これが『eraseVolume free free』と呼ばれているのは、diskutilの驚くほど直感的なインターフェースが、パーティションの削除という概念を 『空き領域としてフォーマットする』と表現しているからです（APFSを除く）。はい、本当です。

APFS コンテナのサイズ変更

Asahi Linuxを削除した後、再度インストールすることも可能です（インストーラのリサイズオプションを使用する必要はありません）。しかし、再びmacOSを 大きくしてディスクのサイズいっぱいまで使いたい場合は、以下のどちらかを使います。

diskutil apfs resizeContainer disk0s2 0

diskutil apfs resizeContainer disk3 0

ここでも、物理パーティション識別子または論理ディスク番号を使用できます。これらは等価です。0 は、パーティションの後にある利用可能な空き領域を すべて埋めるようにサイズを変更することを意味します。もし、任意のサイズに拡張/縮小したい場合は、100GBのように指定します。

このコマンドを実行すると、macOSのターミナルが一瞬フリーズすることがありますので、ご注意ください。慌てずに数分間実行させてください。

Storage system verify or repair failed (ストレージシステムの検証または修復に失敗しました)

APFS のリサイズ操作中にこのエラーが発生した場合、APFS ファイルシステムが潜在的に破損していることを意味します。この問題は Apple の APFS ドライバのバグが原因であり、Asahi Linuxでは発生しません（APFS パーティションには全く触れません）。この問題を解決するには、 recoveryOSで起動し（macOS からは動作しません）、以下のコマンドを実行してください（上記のように、disk0s2 を APFS コンテナディスク名に置き換えてください）:

diskutil repairVolume disk0s2

もしこれが『encrypted and locked volumes(暗号化されロックされたボリューム)』について文句を言うなら、システム内の FileVault で保護された macOS ボリューム全てに対して diskutil apfs unlockVolume <diskName> を実行する必要があります。diskutil apfs list を実行し、 FileVault: Yes (locked) を探し、それらを特定してください。システムボリュームはスキップしてかまいません（ロック解除が必要なのはデータボリュームだけです）。 それから diskutil repairVolume 操作をもう一度実行してください。

最後に、修復が正常に完了してからリサイズ操作を再試行してください。

これでもボリュームの修復がうまくいかず、リサイズ操作にも失敗する場合は、残念ながら macOS ボリュームを完全に消去して再フォーマットする（すべてのデータを失う） 以外に解決策はありません。Asahi Linu xプロジェクトでは、Apple 独自のシステムドライバやツールのバグフィックスやサポートを提供することはできません。 APFS の破損を引き起こす再現可能な方法を見つけた場合は、Apple に直接報告してください。

付録:EFIパーティションのマウント

EFIパーティションをマウントする方法は2つあります。1つ目はこちらです:

diskutil list
diskutil mount disk0s4
mount
cd /Volumes/...

2つ目はこちらです:

mkdir /Volumes/efi
mount -t msdos /dev/disk0s4 /Volumes/efi