「パーティショニング」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
細 (→‎Master Boot Record: リンクを修正)
114行目: 114行目:
 
== パーティションスキーム ==
  
== パーティションスキーム ==
   
−
ハードドライブをパーティショニングするのに厳格なルールはありませんが、以下に一般的なガイダンスを記します。どうパーティショニングするかは、使用できるディスク容量の制限のほかに、求められる柔軟性・スピード・セキュリティなどの理由で決定されます。ユーザーの決定はコンピュータを使う癖や条件によって様々なものになりえます。Arch Linux と Windows OS のデュアルブートを考えているのなら、[[Windows と Arch のデュアルブート]]を読んでください。
 +
ハードドライブをパーティショニングするのに厳格なルールはありませんが、以下に一般的なガイダンスを記します。ディスクのパーティショニングスキームは、使用できるディスク容量の制限のほかに、求められる柔軟性、スピード、セキュリティなどの理由で決定されます。ユーザーの決定はコンピュータを使う癖や条件によって様々なものになりえます。Arch Linux と Windows OS のデュアルブートを考えているのなら、[[Windows と Arch のデュアルブート]]を読んでください。
   
  +
{{Note|
−
{{Warning|ブートローダのための領域を残しておくことを忘れないで下さい。MBR や GRUB-Legacy では問題になりませんでしたが、最近のパーティションスキームでは特別な、小さなパーティションが必要になることがあります。}}
  
  +
* 通常、[[UEFI]] システムでは [[EFI システムパーティション]]が必要です。
  +
* [[#GUID Partition Table|GPT]] でパーティショニングされた BIOS システムでは、[[GRUB]] をブートローダとして使う場合、[[BIOS ブートパーティション]]が必要です。
  +
}}
   
  +
{{Tip|[[Btrfs]] を使用している場合、サブボリュームはパーティションを模倣するために使用できます。[[Btrfs#サブボリュームをマウントする]] セクションを見てください。}}
−
=== シングル root パーティション ===
  
   
  +
=== シングルルートパーティション ===
−
このスキームが一番シンプルで、ほとんどの場合これで十分です。必要に応じて[[スワップ#スワップファイル|スワップファイル]]を作成することもでき、簡単にサイズを変更できます。一般的に、まず1つのパーティション {{ic|/}} で初めて、それから、RAID や暗号化、共有メディアパーティションなどの目的にあわせてパーティションを分割するのは道理にかなっています。GPT でパーティションされた BIOS システムに GRUB をインストールするときは追加の BIOS boot パーティションが必要になるので注意してください。
  
  +
  +
このスキームが一番シンプルで、ほとんどの場合これで十分です。必要に応じて[[スワップ#スワップファイル|スワップファイル]]を作成することもでき、簡単にサイズを変更できます。一般的に、まず1つのパーティション {{ic|/}} で始めて、それから、RAID や暗号化、共有メディアパーティションなどの目的にあわせてパーティションを分割するのは道理にかなっています。
   
 
=== パーティションを分割する ===
  
=== パーティションを分割する ===
  +
 
パーティションをパス毎に分割することで異なるファイルシステムとマウントオプションが使えるようになります。メディアパーティションなどの場合、オペレーティングシステム間で共有できます。
  
パーティションをパス毎に分割することで異なるファイルシステムとマウントオプションが使えるようになります。メディアパーティションなどの場合、オペレーティングシステム間で共有できます。
   
  +
パーティショニングの際に利用できるレイアウト例を以下に挙げています。以下のサブセクションでは、独立したパーティションに配置して {{ic|/}} 下のマウントポイントにマウントできるディレクトリのいくつかを詳細に説明しています。これらのディレクトリの内容に関する完全な説明は {{man|7|file-hierarchy}} を見てください。
−
=== マウントポイント ===
  
−
パーティションを分割すると以下のマウントポイントを選ぶことができます、実際の必要にあわせて決めてください。
  
   
 
==== / ====
  
==== / ====
   
−
root ディレクトリは階層のトップであり、プライマリファイルシステムがマウントされ他の全てのファイルシステムの幹になります。すべてのファイルとディレクトリは root ディレクトリ {{ic|/}} の下に表示されます、それらが異なる物理デバイスに保存されている場合でも同様です。root ファイルシステムには、システムのブート・リストア・リカバー・リペアに必要なものがなければなりません。そのため、{{ic|/}} 下の特定ディレクトリは分割パーティションになりえません。
 +
[[Wikipedia:ja:ルートディレクトリ|ルートディレクトリ]]はディレクトリ階層のトップです。このディレクトリでは主要なファイルシステムがマウントされ、他の全てのファイルシステムの幹になります。すべてのファイルとディレクトリはルートディレクトリ {{ic|/}} の下に現れます、それらが異なる物理デバイスに保存されている場合でも同様です。ルートファイルシステムには、システムの起動、修復、回復、修繕に必要なものがなければなりません。そのため、{{ic|/}} 下の特定のディレクトリは、分割されたパーティションになりえません。
   
−
{{ic|/}} パーティション、または root パーティションは必須の、一番重要なパーティションです。このパーティションで他の全てのパーティションを置き換えることができます。
 +
{{ic|/}} パーティション(ルートパーティション)は必須の、一番重要なパーティションです。このパーティションで他の全てのパーティションを置き換えることができます。
   
−
{{Warning|({{ic|/boot}} 以外の) 起動に必要なディレクトリは'''かならず'''同じパーティション {{ic|/}} か [[mkinitcpio|initramfs]] によってユーザースペースの初期にマウントされるパーティションに配置されなくてはなりません。起動に必要なディレクトリ: {{ic|/etc}} と {{ic|/usr}} [https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken]。}}
 +
{{Warning|({{ic|/boot}} 以外の)起動に必要なディレクトリは'''必ず''' {{ic|/}} と同じパーティション、あるいは [[initramfs]] によって初期ユーザ空間にマウントされるパーティションに配置されなくてはなりません。そのような起動に必須なディレクトリとしては {{ic|/etc}} と {{ic|/usr}} があります[https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken]。}}
   
  +
{{ic|/}} には伝統的に {{ic|/usr}} ディレクトリが含まれており、インストールされているソフトウェアの量によっては非常に肥大化することがあります。最近のハードディスクでは、ほとんどのユーザにとって 15 から 20 GiB あれば十分でしょう。スワップファイルをここに保存するつもりであれば、パーティションのサイズをもっと大きくする必要があるかもしれません。
−
====/boot====
  
   
  +
==== /boot ====
−
{{ic|/boot}} ディレクトリにはブートローダの設定ファイルや実行領域だけでなく、カーネルや ramdisk イメージも入ります。またカーネルがユーザースペースのプログラムを起動する前に使われるデータも保存されます。{{ic|/boot}} は通常のシステムオペレーションには必要ありませんが、起動中やカーネルアップグレードの時(initial ramdisk を再生成する時)だけ使われます。
  
   
  +
{{ic|/boot}} ディレクトリには、カーネルや RAM ディスクのイメージ、ブートローダの設定ファイルやブートローダのステージが含まれています。また、このディレクトリには、カーネルがユーザ空間のプログラムを実行し始める前に使用されるデータも格納されています。{{ic|/boot}} は通常のシステム運用では必要ありませんが、ブート時やカーネルのアップグレード(初期 RAM ディスクの生成)の際に必要になります。
−
ソフトウェア RAID0 (ストライプ) をインストールするには {{ic|/boot}} パーティションを分割して作る必要があります。
  
   
  +
{{Note|
−
{{Note|他のファイルシステムのドライバーを含んでいない UEFI ブートローダーを使用してブートする場合、[[ESP]] は {{ic|/boot}} にマウントすることが推奨されます。例えば [[EFISTUB]] や [[systemd-boot]] などのローダーが該当します。}}
  
  +
* {{ic|/boot}} を別のパーティションに分離する必要があるのは、{{ic|/}} 内の {{ic|/boot}} ディレクトリにアクセスする能力がブートローダに無い場合のみです。例えば、ブートローダがルートパーティションのファイルシステムをサポートしていない場合や、{{ic|/}} がスタックブロックデバイス(ソフトウェア [[RAID]]、[[dm-crypt|暗号化されたボリューム]]、[[LVM]] ボリュームなど)上に存在していて、ブートローダがそれに対するドライバを搭載していない場合などです。ブートローダの要件や能力に関する情報は [[Arch ブートプロセス#ブートローダー]] を見てください。
  +
* 使用する UEFI [[ブートローダー]]が他のファイルシステム用のドライバを搭載していない場合、[[EFI システムパーティション]]を {{ic|/boot}} にマウントすることが推奨されます。詳細は [[EFI システムパーティション#パーティションのマウント]] を見てください。
  +
}}
   
  +
[[EFI システムパーティション]]を {{ic|/boot}} として使用していない場合、{{ic|/boot}} の推奨サイズは 200 MiB です。[[EFI システムパーティション]]を {{ic|/boot}} として使用している場合、少なくとも 300 MiB 以上にすることが推奨されます。
−
====/home====
  
   
  +
{{Warning|[[ブートローダー]]がまだサポートしていない新しい機能がファイルシステムに追加されることがあります。これにより、互換性のない機能を無効化しない限り、そのファイルシステムが {{ic|/boot}} パーティションに適さなくなってしまいます。}}
−
{{ic|/home}} ディレクトリにはユーザー設定ファイル("ドットファイル"と呼ばれます)、キャッシュ、アプリケーションのデータ、メディアファイルが含まれます。
  
  +
  +
==== /home ====
  +
  +
{{ic|/home}} ディレクトリには、ユーザー固有の設定ファイル、キャッシュ、アプリケーションのデータ、メディアファイルが含まれます。
   
 
{{ic|/home}} を分割することで {{ic|/}} を別個にパーティションしなおすことができますが、分割してなくとも {{ic|/home}} に触れずに Arch を再インストールすることはできます - 他のトップレベルディレクトリは削除する必要があり、それから pacstrap を実行することができます。
  
{{ic|/home}} を分割することで {{ic|/}} を別個にパーティションしなおすことができますが、分割してなくとも {{ic|/home}} に触れずに Arch を再インストールすることはできます - 他のトップレベルディレクトリは削除する必要があり、それから pacstrap を実行することができます。
   
−
異なるディストリビューションのユーザー間で home ディレクトリを共有するべきではありません、なぜならソフトウェアのバージョンやパッチによって互換性がないことがあるからです。代わりに、メディアパーティションを共有したり、少なくとも、同じ {{ic|/home}} パーティションにある別の home ディレクトリを使うなどしてください。
 +
異なるディストリビューションのユーザー間で home ディレクトリを共有するべきではありません、なぜならソフトウェアのバージョンやパッチによって互換性がないことがあるからです。代わりに、メディアパーティションを共有したり、少なくとも、同じ {{ic|/home}} パーティションにある別の home ディレクトリを使うなどしてください。このパーティションのサイズは様々です。
   
−
====/var====
 +
==== /var ====
   
−
{{ic|/var}} ディレクトリにはスプールディレクトリ・ファイル、管理用のログデータ、[[pacman]] のキャッシュ、[[Arch Build System|ABS]] ツリーなどの可変データが置かれます。キャッシングやロギングなどに使われるため頻繁に読み書きされます。分割したパーティションに配置することで、ログなどによってディスク容量が不足するのを回避できます。
 +
{{ic|/var}} ディレクトリには、スプールディレクトリ・ファイル、管理用のログデータ、[[pacman]] のキャッシュなどの可変データが置かれます。キャッシングやロギングなどに使われるため頻繁に読み書きされます。分割したパーティションに配置することで、ログなどによってディスク容量が不足するのを回避できます。
   
 
{{ic|/usr}} を読み込み専用でマウントするための選択肢としても存在します。歴史的に、(インストールやシステムメンテナンスと対照的に)システムオペレーションでは {{ic|/var}} に置かれるものは全て {{ic|/usr}} に書き出されます。
  
{{ic|/usr}} を読み込み専用でマウントするための選択肢としても存在します。歴史的に、(インストールやシステムメンテナンスと対照的に)システムオペレーションでは {{ic|/var}} に置かれるものは全て {{ic|/usr}} に書き出されます。
160行目: 172行目:
 
{{Note|{{ic|/var}} には小さいファイルが多く入ります。もしパーティションを分割するなら、ファイルシステムタイプ(下を見て下さい)の選択ではこのことを考えて下さい。}}
  
{{Note|{{ic|/var}} には小さいファイルが多く入ります。もしパーティションを分割するなら、ファイルシステムタイプ(下を見て下さい)の選択ではこのことを考えて下さい。}}
   
  +
{{ic|/var}} には、他のデータに混じって [[pacman]] のキャッシュが含まれます。パッケージのアップグレードによってシステムが不安定なった際に、保存されている以前のバージョンのパッケージに[[ダウングレード]]しなければならなくなった場合に備えて、これらのパッケージを保管しておくと便利です。pacman のキャッシュは、システムが拡張されたりアップデートされたりするたびに大きくなります。しかし、スペースの問題が生じた際には、キャッシュを安全に削除できます。デスクトップのシステムでは、{{ic|/var}} に 8 から 12 GiB 確保すれば十分なはずです(ソフトウェアをどれだけインストールするかに依りますが)。
−
==== /tmp ====
  
   
  +
==== /data ====
−
systemd によって {{ic|tmpfs}} としてマウントされることで、デフォルトで分割パーティションになっています。
  
  +
  +
「データ」パーティションをマウントして、すべてのユーザが共有する様々なファイルを格納することができます。{{ic|/home}} パーティションをこの用途に使うこともできます。このパーティションのサイズは様々です。
   
 
==== スワップ ====
  
==== スワップ ====
   
−
[[スワップ]]パーティションは仮想メモリを提供します。[[スワップ#スワップファイル|スワップファイル]]を使うことも考えてください、パーティションを作るのに比べてパフォーマンスのオーバーヘッドがないばかりでなく、必要に応じてより簡単にリサイズできます。swap パーティションは''基本的に''オペレーションシステム間で共有することができますが、ハイバネーションが使われる場合はそうでありません。
 +
[[スワップ]]は、仮想メモリとして使用されるディスク領域を提供するファイル、またはパーティションです。スワップファイルとスワップパーティションのパフォーマンスは同等ですが、スワップファイルのほうが必要に応じてサイズを変更しやすいです。スワップパーティションは''基本的に''オペレーションシステム間で共有することができますが、ハイバネーションが使われる場合はそうでありません。
   
  +
歴史的に、スワップパーティションのサイズは物理 RAM のサイズの2倍にするという一般的なルールがありました。しかし、コンピュータがより多くのメモリを搭載するようになってから、このルールは時代遅れになりました。例えば、512 MiB の RAM を搭載する平均的なデスクトップマシンでは、通常「2倍ルール」は適切です。十分な量の RAM (1024 MiB 以上)が利用できる場合は、スワップパーティションを小さくしてもよいでしょう。
−
{{Note|スワップパーティションサイズについての古い法則は [[サスペンドとハイバネート|suspend-to-disk]] を使う場合はあてはまりません。サスペンドメソッドはデフォルトで利用できるメモリの 40% のイメージを使います。[[TuxOnIce]] では、atomic コピーは圧縮して通常約 70% だけ使います。[http://tuxonice.net/features]}}
  
   
  +
ハイバネート(suspend to disk)する場合、RAM と同じサイズのスワップパーティションを作成することが推奨されます。カーネルは、スワップ領域に収まるように suspend-to-disk イメージを圧縮しようとしますが、スワップ領域のサイズが RAM よりも大幅に小さい場合にハイバネートが成功する保証はありません。詳細は [[サスペンドとハイバネート#ハイバネーション]] を見てください。
−
====パーティションの大きさはどうすればいいですか?====
  
  +
  +
=== レイアウト例 ===
  +
  +
以下の例では、{{ic|/dev/sda}} をディスクの例として使い、1番目のパーティションとして {{ic|/dev/sda1}} が存在するとします。パーティショニングするディスクが [[NVMe]] ディスク(例えば、{{ic|/dev/nvme0n1p1}} から始まるパーティションを持つ {{ic|/dev/nvme0n1}})であったり、SD カードや eMMC ディスク(例えば、{{ic|/dev/mmcblk0p1}} から始まるパーティションを持つ {{ic|/dev/mmcblk0}})であったりすると、ブロックデバイスの命名規則が異なります。詳細は [[デバイスファイル#ブロックデバイスの名前]] を見てください。
   
 
{{Note|
  
{{Note|
  +
* UEFI ブートは "boot" フラグと関係ありません。UEFI ブートは NVRAM 上のブートエントリにのみ依存しています。[[Parted]] とそのフロントエンドは、パーティションが EFI システムパーティションであることを示すために GPT 上で "boot" フラグを使用します。
−
* 以下はただの推奨事項です。パーティションのサイズに関する厳格なルールは存在しません。
  
  +
* すべての必要なパーティションを同一のディスク上に置く必要はありませんし、すべてのディスクで同じ種類のパーティションテーブルを使用する必要もありません。
−
* 可能であれば、それぞれのファイルシステムに 25% の容量を加えて、フラグメンテーションを防いだり将来の拡張のために余剰を残して下さい。
  
 
}}
  
}}
   
  +
==== UEFI/GPT レイアウト例 ====
−
パーティションのサイズは個々人の好みによりますが、以下の情報が約に立つかもしれません:
  
  +
  +
{| class="wikitable"
  +
! インストールされたシステムでのマウントポイント
  +
! パーティション
  +
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|パーティションタイプ GUID]]
  +
! [[Wikipedia:GUID Partition Table#Partition entries (LBA 2–33)|パーティション属性]]
  +
! 推奨サイズ
  +
|-
  +
| {{ic|/boot}} または {{ic|/efi}}<sup>1</sup>
  +
| {{ic|/dev/sda1}}
  +
| {{ic|C12A7328-F81F-11D2-BA4B-00A0C93EC93B}}: [[EFI システムパーティション]]
  +
|
  +
| 少なくとも 300 MiB
  +
|-
  +
| {{ic|[SWAP]}}
  +
| {{ic|/dev/sda2}}
  +
| {{ic|0657FD6D-A4AB-43C4-84E5-0933C84B4F4F}}: Linux [[スワップ]]
  +
|
  +
| 512 MiB 以上
  +
|-
  +
| {{ic|/}}
  +
| {{ic|/dev/sda3}}
  +
| {{ic|4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709}}: Linux x86-64 root (/)
  +
|
  +
| デバイスの残りの領域
  +
|}
  +
  +
==== BIOS/MBR レイアウト例 ====
  +
  +
{| class="wikitable"
  +
! インストールされたシステムでのマウントポイント
  +
! パーティション
  +
! [[Wikipedia:Partition type|パーティションタイプ ID]]
  +
! [[Wikipedia:ja:ブートフラグ|ブートフラグ]]
  +
! 推奨サイズ
  +
|-
  +
| {{ic|[SWAP]}}
  +
| {{ic|/dev/sda1}}
  +
| {{ic|82}}: Linux [[スワップ]]
  +
| {{No}}
  +
| 512 MiB 以上
  +
|-
  +
| {{ic|/}}
  +
| {{ic|/dev/sda2}}
  +
| {{ic|83}}: Linux
  +
| {{Yes}}
  +
| デバイスの残りの領域
  +
|-
  +
| {{Grey|N/A}}
  +
| ''未割り当て領域''<sup>2</sup>
  +
| {{Grey|N/A}}
  +
| {{Grey|N/A}}
  +
| ディスクの末尾に少なくとも 16.5 KiB
  +
|}
  +
  +
==== BIOS/GPT レイアウト例 ====
  +
  +
{| class="wikitable"
  +
! インストールされたシステムでのマウントポイント
  +
! パーティション
  +
! [[Wikipedia:GUID Partition Table#Partition type GUIDs|パーティションタイプ GUID]]
  +
! [[Wikipedia:GUID Partition Table#Partition entries (LBA 2–33)|パーティション属性]]
  +
! 推奨サイズ
  +
|-
  +
| {{Grey|なし}}
  +
| {{ic|/dev/sda1}}
  +
| {{ic|21686148-6449-6E6F-744E-656564454649}}: [[BIOS ブートパーティション]]<sup>3</sup>
  +
|
  +
| 1 MiB
  +
|-
  +
| {{ic|[SWAP]}}
  +
| {{ic|/dev/sda2}}
  +
| {{ic|0657FD6D-A4AB-43C4-84E5-0933C84B4F4F}}: Linux [[スワップ]]
  +
|
  +
| 512 MiB 以上
  +
|-
  +
| {{ic|/}}
  +
| {{ic|/dev/sda3}}
  +
| {{ic|4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709}}: Linux x86-64 root (/)
  +
|
  +
| デバイスの残りの領域
  +
|}
   
  +
# ブートローダが、カーネルと initramfs のイメージのある {{ic|/efi}} のファイルシステム(とそこにあるファイル)にアクセスできる場合、ESP は {{ic|/efi}} にマウントすることができます。詳細は [[EFI システムパーティション#典型的なマウントポイント]] と [[Arch ブートプロセス#ブートローダー]]セクションにある警告を見てください。
−
; /boot &mdash; 200 MB : {{ic|/boot}} パーティションに必要な容量は約 100 MB です。ただし複数のカーネル・ブートイメージを使うことを考えると、200 から 300 MB がベターでしょう。
  
  +
# 512バイトセクタ33個(16.5 KiB)以上のパーティショニングされていない領域をディスクの末尾に作成します。これは、将来的に [[GPT fdisk#MBR と GPT の変換|GPT に変換できる]]ようにするためのものです。この領域は、バックアップ GPT ヘッダのために必要です。すべての MBR ディスクに対してこのようなパーティショニングされていない領域を確保することが推奨されます。
−
; / &mdash; 15-20 GB : root ファイルシステム ({{ic|/}}) には基本的に {{ic|/usr}} ディレクトリが含まれるので、必要な容量はインストールするソフトウェアの数によります。最近のハードディスクを使うユーザーのほとんどは 15-20 GB で十分だと思います。このパーティションにスワップファイルを保存する予定ならば、サイズをやや大きめにする必要があるでしょう。
  
  +
# BIOS ブートパーティションは、GPT ディスクから [[GRUB]] を BIOS ブートする場合にのみ必要です。{{ic|/boot}} とは関係ありません。このパーティションはファイルシステムでフォーマットしてはいけませんし、マウントしてもいけません。
−
; /var &mdash; 8-12 GB : {{ic|/var}} ファイルシステムには [[Arch Build System|ABS]] ツリーや [[pacman]] キャッシュなどのデータを収納します。パッケージのキャッシュを保持することはダウングレードをするときなどに役立つので、{{ic|/var}} はサイズが増えていく傾向があります。特に pacman のキャッシュはシステムを拡張したりアップデートするときに増加します。ただし、容量が足らなくなったときは問題なくキャッシュを削除可能です。デスクトップシステムでは {{ic|/var}} に必要な容量は 8-12GB ほどで、インストールされるソフトウェアの数によります。
  
−
; /home &mdash; [不定] : {{ic|/home}} ファイルシステムは一般的にユーザーのデータ(ダウンロードしたファイル・マルチメディアなど)を置くところです。デスクトップシステムでは、{{ic|/home}} はドライブの中で一番大きなファイルシステムにするのが普通です。
  
−
; swap &mdash; [不定] : 歴史的に、物理メモリの容量の2倍のスワップパーティションを用意するべきという一般法則がありました。より大容量のメモリがコンピュータに積まれるようになり、この法則はすでに現状にあてはまりません。メモリが 512 MB 以下のマシンでは、2倍ルールが基本的に適合します。大容量のメモリ(1024MB 以上)を積んでいるときは、スワップパーティションは小さく、または作らなくてもかまわないでしょう。2GB 以上の物理 RAM を持っているなら、スワップパーティションがないほうが一般的に良いパフォーマンスを発揮すると思われます。
  
−
: {{Note|スワップパーティション・ファイルにハイバネートするつもりならば、[[サスペンドとハイバネート#スワップパーティション(ファイル)のサイズについて]]を見てください。}}
  
−
; /data - [不定] : 全てのユーザーによって共有するファイルを置くために "data" パーティションをマウントしても良いでしょう。同じ目的で {{ic|/home}} パーティションを使ってもかまいません。
  
   
 
== ツール ==
  
== ツール ==

2022年8月3日 (水) 05:31時点における版

関連記事

パーティショニングとは二次記憶装置上に1つ、あるいは複数の領域を作成して、それぞれの領域を分離して管理できるようにすることです。

ディスク全体を1つのパーティションに割り当てることもできますし、複数のパーティションに割り当てることもできます(デュアルブートする場合やスワップパーティションを作る場合、オーディオファイルやビデオファイルなどのデータを論理的に分けておきたい場合に便利です)。パーティションスキームは、Master Boot Record (MBR) や GUID Partition Table (GPT) などのパーティションテーブルに格納されています。

パーティションテーブルはパーティショニングツールを使うことで作成したり変更したりできます。Arch Linux で利用できるパーティショニングツールは #パーティショニングツール セクションにリストアップされています。

通常、パーティションにはファイルシステムが直接含まれています。これは、パーティション上にファイルシステムを作成する(つまり、パーティションをフォーマットする)ことで可能です。あるいは、パーティションには LVM、ブロックデバイス暗号化、RAID を含ませることもでき、最終的にこれらは、ファイルを格納できるデバイスファイルを提供します(あるいは、デバイスをさらに積み重ねることもできます)。

ブロックデバイス(例えば ディスク、パーティション、LUKS デバイス、LVM 論理ボリューム、RAID アレイ)のうち、マウント可能なファイルシステムを直接含んでいるものは、ボリュームと呼ばれます。

パーティションテーブル

主に2種類のパーティションテーブルが利用できます。以下の #Master Boot Record (MBR) セクションと #GUID Partition Table (GPT) セクションで、どちらを選択すればよいかについての議論と共に説明されています。3つ目に、あまり一般的でない代替品としてパーティションレスディスクがあり、これも以下のセクションで説明されています。

ブロックデバイスのパーティションテーブルを表示するにはパーティショニングツールを使ってください。

ヒント: SATA ディスクに対しては parted /dev/sdX print か fdisk -l /dev/sdX を実行してください(/dev/sdX の部分は /dev/sda のようなブロックデバイスです)。NVMe ディスクに対しては /dev/nvme0n1、eMMC ディスクに対しては /dev/mmcblk0 です。ブロックデバイスの命名に関する詳細は デバイスファイル#ブロックデバイスの名前 を見てください。

Master Boot Record

Master Boot Record (MBR) は、ストレージデバイスの最初の512バイトです。これには、オペレーティングシステムのブートローダーとストレージデバイスのパーティションテーブルが含まれています。BIOS システムのブートプロセスで重要な役割を果たします。MBR の構造については、Wikipedia:Master boot record#Disk partitioning を参照してください。

ノート:
  • MBR はパーティションにありません。これは、デバイスの最初のセクター(物理オフセット0)にあり、最初のパーティションの前にあります。
  • パーティションレスデバイスまたは個々のパーティション内に存在するブートセクターは、代わりに volume boot record (VBR) と呼ばれます。

Master Boot Record (bootstrap code)

MBR の先頭440バイトは、bootstrap code 領域 です。BIOS システムでは、通常、MBR にブートローダーの最初のステージが含まれています。bootstrap code は、dd を使ってバックアップしたり、バックアップから復元したり、消去したりすることができます。

Master Boot Record (partition table)

MBR パーティションテーブル(またの名を DOS パーティションテーブル、MS-DOS パーティションテーブル)には、3つのパーティションタイプがあります:

  • Primary (プライマリ)
  • Extended (拡張)
    • Logical (論理)

プライマリパーティションは起動可能にすることができ、ディスクや RAID ボリュームごとに4つまで作成できます。MBR パーティションテーブルで5つ以上のパーティションが必要になった場合、プライマリパーティションのうち1つを拡張パーティションに置き換えて、その中に論理パーティションを作成する必要があります。

拡張パーティションは論理パーティションの入れ物と考えることができます。1つのハードディスクには2つ以上の拡張パーティションを格納することはできません。拡張パーティションはプライマリパーティションとしてもカウントされるので、ディスクに1つの拡張パーティションが存在している場合、追加できるプライマリパーティションは3つだけです(つまり、3つのプライマリパーティションと1つの拡張パーティション)。拡張パーティション内に存在できる論理パーティションの数に制限はありません。Windows とデュアルブートするシステムでは、Windows をプライマリパーティションに格納する必要があります。

sda1 から sda3 をプライマリパーティションとし、sda4 を拡張パーティションとするのが慣例です。sda4 上の論理パーティションは、sda5、sda6 などのようになります。

ヒント: MBR ディスクをパーティショニングする際、GPT に変換する時に備えて、少なくとも512バイトセクタ33個分(16.5 KiB)の未割り当て領域をディスクの末尾に確保することを検討してください。この空き領域は、バックアップ GPT ヘッダを格納するために必要になります。

GUID Partition Table

GUID パーティションテーブル (GPT) とは、パーティションスキームの1つであり、Unified Extensible Firmware Interface 規格の一部です。GPT では、パーティションとパーティションタイプを定義するためにグローバル一意識別子(GUID)が使われます(Linux の世界では UUID が使用されます)。GPT は Master Boot Record パーティショニングスキーム方式の後継として設計されました。

GUID Partition Table ディスクの先頭には、GPT を検出できないソフトウェアから保護するための protective Master Boot Record (PMBR) が存在します。通常の MBR のような protective MBR には、bootstrap code 領域が存在し、対応しているブートローダで BIOS/BPT ブートを行うために利用できます。

GPT か MBR の選択

GUID Partition Table (GPT) は新しい、現代的なパーティションスタイルです。古い Master Boot Record (MBR) システムを置き換えることを目指しています。GPT には、MS-DOS が使われていた時代にタイムスリップしてしまったような癖がある MBR に対してメリットがいくつかあります。フォーマッティングツールの最近の開発によって、GPT と MBR はどちらも信頼性、パフォーマンスを同じくらいの簡単さで実現できるようになりました。

ノート: GPT でパーティショニングされたディスクから BIOS ベースシステムで GRUB を起動させるには、BIOS ブートパーティションが必要です。

GPT か MBR を選択する際に考慮すべきポイントは:

  • レガシー BIOS を使って(32ビットと64ビットに関わらず) Windows とデュアルブートする場合、MBR スキームを使用する必要があります。
  • BIOS モードではなく UEFI モードで64ビット Windows とデュアルブートする場合、GPT スキームを使用する必要があります。
  • 古いハードウェア(特に、古いノートパソコン)上にインストールする場合、MBR を選択することを検討してください。そのハードウェアの BIOS が GPT に対応していないかもしれないからです(しかし、#古い BIOS をだまして GPT から起動させる に解決策があります)。
  • 2 TiB よりも大きいディスクをパーティショニングする場合、GPT を使う必要があります。
  • UEFI ブートでは常に GPT を使うことが推奨されます。一部の UEFI 実装は UEFI モードでの MBR からの起動をサポートしていないからです。
  • 上記のどれにも当てはまらない場合、GPT と MBR から自由に選んでください。GPT のほうがよりモダンなので、この場合、GPT を選ぶことが推奨されます。

MBR に対する GPT のメリットは:

  • GPT はユニークなディスク GUID と、各パーティションごとにユニークなパーティション GUID(PARTUUID)を提供します。これは、パーティションやディスクを参照するための、ファイルシステム依存に依存しない良い手段です。GUID は、systemd 対応の initramfs で利用できる Discoverable Partitions Specification の前提条件です。
  • GPT は、ファイルシステムに依存しないパーティション名を提供します(PARTLABEL)。
  • GPT では任意の数のパーティションを作成できます(パーティションテーブルに割り当てられた領域のサイズに依存します)。拡張パーティションや論理パーティションは必要ありません。デフォルトで、GPT には 128 個のパーティションを定義できるスペースが確保されています。パーティションテーブルにより多くのスペースを割り当てることで、より多くのパーティションを定義できるようになります(この機能をサポートしているツールは今の所 gdisk しか知られていません)。
  • GPT では、セクタ番号を格納するために64ビットの LBA を使用します(アドレシング可能な最大ディスクサイズは 2 ZiB です)。MBR では、ドライブごとに 2 TiB までしかアドレシングできません。[1]
  • GPT では、バックアップのヘッダとパーティションテーブルがディスクの末尾に格納されており、プライマリのヘッダが破損してしまった場合にバックアップを使って復元を試みることができます。
  • CRC32 checksum により、ヘッダとパーティションテーブルのエラーと破損を検出します。

#パーティショニングツール のセクションには、GPT や MBR のテーブルを作成/変更するためにどのツールを利用できるかを示す表があります。

ヒント: MBR と GPT は互いに変換することが可能です。gdisk#MBR と GPT の変換 を見てください。

パーティションレスディスク

この記事またはセクションは加筆を必要としています。
理由: Explain when one might want to use a partitionless disk (e.g. in VMs) and when not and why. (議論: トーク:パーティショニング#)

パーティションレスディスク(別名 superfloppy)とは、パーティションテーブルを持たないストレージデバイスのことであり、1つのファイルシステムがストレージデバイス全体を占めます。パーティションレスデバイスに存在するブートセクタは、volume boot record (VBR) と呼ばれます。

Btrfs パーティショニング

Btrfs はデータストレージデバイス全体を占有して、MBR や GPT パーティションスキームを置き換えることができます。詳しい説明は Btrfs#パーティショニング を見て下さい。

パーティションスキーム

ハードドライブをパーティショニングするのに厳格なルールはありませんが、以下に一般的なガイダンスを記します。ディスクのパーティショニングスキームは、使用できるディスク容量の制限のほかに、求められる柔軟性、スピード、セキュリティなどの理由で決定されます。ユーザーの決定はコンピュータを使う癖や条件によって様々なものになりえます。Arch Linux と Windows OS のデュアルブートを考えているのなら、Windows と Arch のデュアルブートを読んでください。

ノート:
ヒント: Btrfs を使用している場合、サブボリュームはパーティションを模倣するために使用できます。Btrfs#サブボリュームをマウントする セクションを見てください。

シングルルートパーティション

このスキームが一番シンプルで、ほとんどの場合これで十分です。必要に応じてスワップファイルを作成することもでき、簡単にサイズを変更できます。一般的に、まず1つのパーティション / で始めて、それから、RAID や暗号化、共有メディアパーティションなどの目的にあわせてパーティションを分割するのは道理にかなっています。

パーティションを分割する

パーティションをパス毎に分割することで異なるファイルシステムとマウントオプションが使えるようになります。メディアパーティションなどの場合、オペレーティングシステム間で共有できます。

パーティショニングの際に利用できるレイアウト例を以下に挙げています。以下のサブセクションでは、独立したパーティションに配置して / 下のマウントポイントにマウントできるディレクトリのいくつかを詳細に説明しています。これらのディレクトリの内容に関する完全な説明は file-hierarchy(7) を見てください。

/

ルートディレクトリはディレクトリ階層のトップです。このディレクトリでは主要なファイルシステムがマウントされ、他の全てのファイルシステムの幹になります。すべてのファイルとディレクトリはルートディレクトリ / の下に現れます、それらが異なる物理デバイスに保存されている場合でも同様です。ルートファイルシステムには、システムの起動、修復、回復、修繕に必要なものがなければなりません。そのため、/ 下の特定のディレクトリは、分割されたパーティションになりえません。

/ パーティション(ルートパーティション)は必須の、一番重要なパーティションです。このパーティションで他の全てのパーティションを置き換えることができます。

警告: (/boot 以外の)起動に必要なディレクトリは必ず / と同じパーティション、あるいは initramfs によって初期ユーザ空間にマウントされるパーティションに配置されなくてはなりません。そのような起動に必須なディレクトリとしては /etc と /usr があります[2]。

/ には伝統的に /usr ディレクトリが含まれており、インストールされているソフトウェアの量によっては非常に肥大化することがあります。最近のハードディスクでは、ほとんどのユーザにとって 15 から 20 GiB あれば十分でしょう。スワップファイルをここに保存するつもりであれば、パーティションのサイズをもっと大きくする必要があるかもしれません。

/boot

/boot ディレクトリには、カーネルや RAM ディスクのイメージ、ブートローダの設定ファイルやブートローダのステージが含まれています。また、このディレクトリには、カーネルがユーザ空間のプログラムを実行し始める前に使用されるデータも格納されています。/boot は通常のシステム運用では必要ありませんが、ブート時やカーネルのアップグレード(初期 RAM ディスクの生成)の際に必要になります。

ノート:

EFI システムパーティションを /boot として使用していない場合、/boot の推奨サイズは 200 MiB です。EFI システムパーティションを /boot として使用している場合、少なくとも 300 MiB 以上にすることが推奨されます。

警告: ブートローダーがまだサポートしていない新しい機能がファイルシステムに追加されることがあります。これにより、互換性のない機能を無効化しない限り、そのファイルシステムが /boot パーティションに適さなくなってしまいます。

/home

/home ディレクトリには、ユーザー固有の設定ファイル、キャッシュ、アプリケーションのデータ、メディアファイルが含まれます。

/home を分割することで / を別個にパーティションしなおすことができますが、分割してなくとも /home に触れずに Arch を再インストールすることはできます - 他のトップレベルディレクトリは削除する必要があり、それから pacstrap を実行することができます。

異なるディストリビューションのユーザー間で home ディレクトリを共有するべきではありません、なぜならソフトウェアのバージョンやパッチによって互換性がないことがあるからです。代わりに、メディアパーティションを共有したり、少なくとも、同じ /home パーティションにある別の home ディレクトリを使うなどしてください。このパーティションのサイズは様々です。

/var

/var ディレクトリには、スプールディレクトリ・ファイル、管理用のログデータ、pacman のキャッシュなどの可変データが置かれます。キャッシングやロギングなどに使われるため頻繁に読み書きされます。分割したパーティションに配置することで、ログなどによってディスク容量が不足するのを回避できます。

/usr を読み込み専用でマウントするための選択肢としても存在します。歴史的に、(インストールやシステムメンテナンスと対照的に)システムオペレーションでは /var に置かれるものは全て /usr に書き出されます。

ノート: /var には小さいファイルが多く入ります。もしパーティションを分割するなら、ファイルシステムタイプ(下を見て下さい)の選択ではこのことを考えて下さい。

/var には、他のデータに混じって pacman のキャッシュが含まれます。パッケージのアップグレードによってシステムが不安定なった際に、保存されている以前のバージョンのパッケージにダウングレードしなければならなくなった場合に備えて、これらのパッケージを保管しておくと便利です。pacman のキャッシュは、システムが拡張されたりアップデートされたりするたびに大きくなります。しかし、スペースの問題が生じた際には、キャッシュを安全に削除できます。デスクトップのシステムでは、/var に 8 から 12 GiB 確保すれば十分なはずです(ソフトウェアをどれだけインストールするかに依りますが)。

/data

「データ」パーティションをマウントして、すべてのユーザが共有する様々なファイルを格納することができます。/home パーティションをこの用途に使うこともできます。このパーティションのサイズは様々です。

スワップ

スワップは、仮想メモリとして使用されるディスク領域を提供するファイル、またはパーティションです。スワップファイルとスワップパーティションのパフォーマンスは同等ですが、スワップファイルのほうが必要に応じてサイズを変更しやすいです。スワップパーティションは基本的にオペレーションシステム間で共有することができますが、ハイバネーションが使われる場合はそうでありません。

歴史的に、スワップパーティションのサイズは物理 RAM のサイズの2倍にするという一般的なルールがありました。しかし、コンピュータがより多くのメモリを搭載するようになってから、このルールは時代遅れになりました。例えば、512 MiB の RAM を搭載する平均的なデスクトップマシンでは、通常「2倍ルール」は適切です。十分な量の RAM (1024 MiB 以上)が利用できる場合は、スワップパーティションを小さくしてもよいでしょう。

ハイバネート(suspend to disk)する場合、RAM と同じサイズのスワップパーティションを作成することが推奨されます。カーネルは、スワップ領域に収まるように suspend-to-disk イメージを圧縮しようとしますが、スワップ領域のサイズが RAM よりも大幅に小さい場合にハイバネートが成功する保証はありません。詳細は サスペンドとハイバネート#ハイバネーション を見てください。

レイアウト例

以下の例では、/dev/sda をディスクの例として使い、1番目のパーティションとして /dev/sda1 が存在するとします。パーティショニングするディスクが NVMe ディスク(例えば、/dev/nvme0n1p1 から始まるパーティションを持つ /dev/nvme0n1)であったり、SD カードや eMMC ディスク(例えば、/dev/mmcblk0p1 から始まるパーティションを持つ /dev/mmcblk0)であったりすると、ブロックデバイスの命名規則が異なります。詳細は デバイスファイル#ブロックデバイスの名前 を見てください。

ノート:
  • UEFI ブートは "boot" フラグと関係ありません。UEFI ブートは NVRAM 上のブートエントリにのみ依存しています。Parted とそのフロントエンドは、パーティションが EFI システムパーティションであることを示すために GPT 上で "boot" フラグを使用します。
  • すべての必要なパーティションを同一のディスク上に置く必要はありませんし、すべてのディスクで同じ種類のパーティションテーブルを使用する必要もありません。

UEFI/GPT レイアウト例

インストールされたシステムでのマウントポイント パーティション パーティションタイプ GUID パーティション属性 推奨サイズ
/boot または /efi1 /dev/sda1 C12A7328-F81F-11D2-BA4B-00A0C93EC93B: EFI システムパーティション 少なくとも 300 MiB
[SWAP] /dev/sda2 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux スワップ 512 MiB 以上
/ /dev/sda3 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/) デバイスの残りの領域

BIOS/MBR レイアウト例

インストールされたシステムでのマウントポイント パーティション パーティションタイプ ID ブートフラグ 推奨サイズ
[SWAP] /dev/sda1 82: Linux スワップ No 512 MiB 以上
/ /dev/sda2 83: Linux Yes デバイスの残りの領域
N/A 未割り当て領域2 N/A N/A ディスクの末尾に少なくとも 16.5 KiB

BIOS/GPT レイアウト例

インストールされたシステムでのマウントポイント パーティション パーティションタイプ GUID パーティション属性 推奨サイズ
なし /dev/sda1 21686148-6449-6E6F-744E-656564454649: BIOS ブートパーティション3 1 MiB
[SWAP] /dev/sda2 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F: Linux スワップ 512 MiB 以上
/ /dev/sda3 4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709: Linux x86-64 root (/) デバイスの残りの領域
  1. ブートローダが、カーネルと initramfs のイメージのある /efi のファイルシステム(とそこにあるファイル)にアクセスできる場合、ESP は /efi にマウントすることができます。詳細は EFI システムパーティション#典型的なマウントポイント と Arch ブートプロセス#ブートローダーセクションにある警告を見てください。
  2. 512バイトセクタ33個(16.5 KiB)以上のパーティショニングされていない領域をディスクの末尾に作成します。これは、将来的に GPT に変換できるようにするためのものです。この領域は、バックアップ GPT ヘッダのために必要です。すべての MBR ディスクに対してこのようなパーティショニングされていない領域を確保することが推奨されます。
  3. BIOS ブートパーティションは、GPT ディスクから GRUB を BIOS ブートする場合にのみ必要です。/boot とは関係ありません。このパーティションはファイルシステムでフォーマットしてはいけませんし、マウントしてもいけません。

ツール

パーティショニングツール

以下のプログラムは、デバイスのパーティションテーブルとパーティションを作成/操作するために使用されます。使用する正確なコマンドはリンク先の記事を見てください。

この表は、あなたのニーズにあうユーティリティを選ぶ際に役立ちます:

MBR GPT
対話的 fdisk
parted 		fdisk
gdisk
parted
疑似グラフィック cfdisk cfdisk
cgdisk
非対話的 sfdisk
parted 		sfdisk
sgdisk
parted
グラフィカル GParted
gnome-disk-utility
partitionmanager 		GParted
gnome-disk-utility
partitionmanager
警告: デバイスをパーティションするときは、使用するパーティションテーブルにあったパーティショニングツールを使って下さい。互換性のないツールを使用するとテーブルが破壊され、既存のパーティションやデータが読み込めなくなる可能性があります。

fdisk

fdisk とその関連するユーティリティは fdisk の記事で説明されています。

GPT fdisk

gdisk とその関連するユーティリティは gdisk の記事で説明されています。

GNU Parted

これらのツールは GNU Parted の記事で説明されています。

  • GNU Parted — ターミナルパーティショニングツール。
https://www.gnu.org/software/parted/parted.html || parted
  • GNOME Disks — GNOME のためのディスク管理ユーティリティ。
https://wiki.gnome.org/Apps/Disks || gnome-disk-utility
  • GParted — ディスクのパーティションをグラフィカルに管理するGTK パーティションエディタ。
https://gparted.sourceforge.io/ || gparted
  • KDE Partition Manager — ディスクデバイス、パーティション、そしてファイルシステムを管理する KDE のためのユーティリティプログラム。
https://kde.org/applications/system/org.kde.partitionmanager || partitionmanager

バックアップ

リカバリ

  • gpart — 破壊された MBR パーティションテーブルの内容を推測するユーティリティ。使用法は gpart(8) man ページで説明されています。
https://github.com/baruch/gpart || gpart
  • GPT fdisk — (ディスクの先頭にある)プライマリ GPT ヘッダを(ディスクの末尾にある)セカンダリ GPT ヘッダから復元できるパーティショニングツール(その逆も可)。
https://www.rodsbooks.com/gdisk/ || gptfdisk
  • TestDisk — MBR と GPT の両方の失われたパーティションを復元できるユーティリティ。
https://www.cgsecurity.org/index.html?testdisk.html || testdisk

パーティションアライメント

経験則として、パーティションの開始位置とサイズをメビバイト単位に揃えるというものがあります。Advanced Format#パーティションのアライメント を見てください。

警告: パーティションのアライメントを誤ると、dm-crypt/LUKS で 4096 バイトのセクタを使用できなくなります。

GPT カーネルサポート

カーネル構成の CONFIG_EFI_PARTITION オプションは、カーネルでの GPT サポートを有効にします(名前は EFI PARTITION ですが)。このオプションはカーネルに組み込まれている必要があり、ロード可能なモジュールとしてコンパイルされてはなりません。このオプションは、GPT ディスクがデータストレージのみに使用され、起動には使用されない場合でも必要です。このオプションは、すべての Arch の 公式にサポートされているカーネル でデフォルトで有効になっています。カスタムカーネルの場合は、CONFIG_EFI_PARTITION=y を実行してこのオプションを有効にします。

トラブルシューティング

古い BIOS をだまして GPT から起動させる

一部の古い BIOS (2010年以前のもの) は、ブートセクターを解析しようとし、ブート可能な MBR パーティションが含まれていない場合はブートを拒否します。これは、このディスクでGPTを使用する場合に問題になります。これは、 BIOS の観点から、タイプee の起動不可能な MBR パーティションが1つだけ含まれているためです(つまり、保護 MBR パーティション) fdisk -t mbr /dev/sda を使用して、保護MBRエントリを起動可能としてマークできます。これは一部の BIOS で機能します。ただし、 UEFI 仕様では、保護 MBR パーティションエントリを起動できないように禁止されており、 UEFI ベースのボードはレガシーブートモードでもこれを考慮します。したがって、これは、最新の UEFI ベースのボードと起動可能な MBR パーティションの検索を要求する古い BIOS の両方で起動することになっている GPT ベースの USB フラッシュドライブを作成する場合に重要です。 fdisk や gdisk などの従来のツールを使用してこの問題を解決することはできませんが、両方の種類の BIOS に適した偽の MBR パーティションエントリをバイトシーケンスとして手動で作成することはできます。

以下のコマンドは、2番目の MBR パーティションスロットを上書きし、タイプ0 (つまり未使用) の起動可能なパーティションを追加して、デバイスの最初のセクターのみをカバーします。 GPT や、通常は保護 MBR パーティションを含む最初の MBR パーティションエントリには干渉しません。 

# printf '\200\0\0\0\0\0\0\0\0\0\0\0\001\0\0\0' | dd of=/dev/sda bs=1 seek=462

最終的に次のようになります: 

# fdisk -t mbr -l /dev/sda
Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors
Disk model: ST3250820AS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors   Size Id Type
/dev/sda1           1 488397167 488397167 232.9G ee GPT
/dev/sda2  *        0         0         1   512B  0 Empty

Partition table entries are not in disk order.

ファームウェアRAIDが有効なときにドライブが表示されない

SATA や NVMe ドライブがファームウェアセットアップで表示されるのに、Linux (例えば fdisk -l) に表示されない場合、コントローラがファームウェア RAID モードになっている可能性があります。

NVMe の場合、journal に以下のように表示されるはずです。 

kernel: ahci 0000:00:17.0: Found 1 remapped NVMe devices.
kernel: ahci 0000:00:17.0: Switch your BIOS from RAID to AHCI mode to use them.

解決方法は、ファームウェアセットアップ画面を開いて SATA コントローラオペレーションモード を RAID から AHCI に変更することです。設定は異なる名前になっていたり、コントローラごとやポートごとの設定があるかもしれないことに注意してください。

警告: Windows とデュアルブートをしている とき、コントローラのモードを変更する前に準備が必要です。How to Enable AHCI in Windows 8 and Windows 10 after Installation を参照してください。
ノート: NVMe では単語の意味が通りませんが、設定は普通 SATA と同じです。製造者は、NVMe コントローラの "SATA オペレーションモード" が "AHCI" にセットされていることを "ファームウェア RAID を使わないネイティブのオペレーティングモードを使う" と単純に解釈します。[3][4][5]

参照

「https://wiki.archlinux.jp/index.php?title=パーティショニング&oldid=26695」から取得