Grubはどこにインストールされますか？また、別のLinuxインストール用に新しいGrubが必要ですか？
現在、ArchとWindowsでgrubをインストールして構成しています。別のパーティションに別のArchインストールを作成します。
新しくインストールしたディストリビューションにgrubを再度インストールして構成する必要がありますか、それとも古いディストリビューションを使用できますか？
古い（現在の観点から見て）古いgrubを引き続き使用する場合は、新しいArchのインストールが認識されるように再度構成する必要があると思います。
現在のパーティションを（古いArchインストールで）フォーマットするとどうなりますか？
grubは引き続き機能しますか（つまり、修正するにはlive-cdを起動する必要があります）？
要約すると、grubは、OSとは独立して一般的な場所にインストールされていますか、それともいくつかの場所（私の現在のArchインストール）に関連付けられていますか。
チュートリアルは次のコマンドを提供します：grub-mkconfig -o /boot/grub/grub.cfgこれにより、grubは特定のLinuxインストールに関連付けられていると思います。ただし、grub-installコマンドは、ディレクトリを指定しません。
そして、GRUBが現在のインストールに関連付けられている場合、私のコンピューターはGRUBをチェックするパーティションをどのようにして知るのでしょうか？そうでなければ、それが「一般」だった場合、なぜ特定 Archインストールにパッケージとして「インストール」する必要があるのでしょうか？
命名規則：
GRUB（その一部）はMBRに残ります。
GRUB（残りの部分）は、
/boot/grubからロードされるいくつかのファイルです（例：GRUBで背景として表示される素敵な画像はMBRに保存されません）
ノート：
答えはMBRのセットアップを考慮しています。GRUBは他のセットアップで使用できます。
EFIの設定では物事が複雑になります。GRUBを使用できますが、カーネル自体を独自のEFIスタブとして使用することもできます。
GRUB（その一部）はMBRにインストールされます。 MBRはディスクの最初の512バイトです。 MBRはディスクのパーティションテーブルでも使用されるため、GRUB自体の容量は512バイトよりも若干少なくなります。
MBR内のGRUB（その一部）は、ディスクの別の部分からより完全なGRUB（残り））をロードします。 GRUB MBR（grub-install）へのインストール。MBRGRUBは、通常、/bootに常駐するディスク上の対応するものを見つける必要があるため、メイン= GRUB常駐は、パーティションテーブルから遠すぎることはできません（多くの場合、512MBですが、異なる場合があります）。
/bootを独自のパーティションとして持つと非常に便利です。これは、ディスク全体のGRUBをそこから管理できるためです。
どういう意味ですか：
GRUBは、ディスクから1つだけGRUB（残りの部分））をロードできます。
ディスク上の特定のGRUB（残りの部分））は、マシン上のすべてのOSを見つけるように構成する必要があります。
コマンドgrub-mkconfig -o /boot/grub/grub.cfgは、すべてのパーティションをスキャンしてすべてのOSを指すos-proberを生成するgrub.cfgを実行します（検出できる場合）。
したがって、/bootを使用して複数のパーティションがある場合（または同等のMS Windowsのパーティションを知りませんが、os-proberは知っています）、os-proberはそれらを検出し、それに応じてgrub.cfgを作成します。 grub-installを実行すると、MBRでGRUB（その一部）が現在のgrub.cfgで現在実行中のOSのGRUBを指す）にインストールされます。
これは何を意味するのでしょうか：
システム全体で必要なのは、単一のGRUB=だけです。
（異なるMBRがあるため）異なるディスク上に異なるGRUBを置くことができますが、これは、ディスクを削除する場合にのみ意味があります。
単一のGRUBインストールからすべてのOSのブートを管理できます。
単一のディスクでは、常に単一のOSからのみ
grub-installを実行する必要があります。これは重要です。それ以外の場合は、構成を上書きし続けます。
ただ明確にするために、あなたは grub2 を使用しています、正しいですか？
Grub2が独自のブートパーティションにインストールされている場合は、何も変更する必要はありません。そうでない場合（これは非常に奇妙なことです）、技術的にはgrub.cfgを保持し、ディストリビューションに/etc/grub.dも保持することができます。
ただし、/bootは独自のパーティションである必要があります。 mountを実行して次のようなものが表示された場合：
/dev/sda1 on /boot type ext4 (rw,relatime,seclabel,stripe=4,data=ordered)
Grub2が本来のパーティションにインストールされているはずです。通常、新しいディストリビューションをインストールするとき、ウィザードは通常、インストールプロセスをガイドし、該当する場合は、どのパーティションにどのOS-esが含まれているかを把握します。 Archでのプロセスは少し面倒ですが、非常に 十分に文書化されています です。
恐怖が続く場合
ダウンロード GParted 、それをUSBスティックに入れ、そこから起動して、/bootパーティションをマウントします。
次に、単にrootとして（またはSudoを使用して）実行します。
grub-mkconfig -o /boot/grub/grub.cfg
Grub2はパーティションを自動検出し、それに応じて動作する必要があります。
（現時点では、Grub2がOS-esを検出するためにパーティションをすべてマウントする必要があるかどうかはわかりません）
その間にWindowsをインストールしようとした場合、Windowsがブートローダーを上書きした可能性があります。これを修正するには、単にrootとして（またはSudoを付けて）実行します。
grub-install /dev/sdX
ここで、/dev/sdXは、ブートパーティションが存在するドライブです。
説明の少し：
Grub2はステージ2 ブートローダー です。これはオペレーティングシステムではないことを意味しますが、プライマリパーティションの最初の446バイトに収まる単純なチェーンローダーよりもはるかに複雑です（最初のセクターの残りはパーティションテーブル、フラグなどです）。
MBRには、/bootパーティションにあるGrub2コードを実行するためのコードのみが含まれています。次に、Grub2は chainloads を別のパーティションに（たとえば、独自のブートローダーをインストールするため、Windowsをブートするために）挿入しますが、コード（memtestなど）を実行したり、アクセスしたりできます。カーネルとモジュールのイメージ（vmlinuz）を実行します。
注意すべき重要な点は、どちらの場合でも、カーネルが実行を開始するか、別のパーティションがチェーンロードされると、Grub2がメモリからアンロードされることです。
Grubは特定のOSに関連付けられていません。プライベートパーティションに常駐できますが、通常はメインファイルシステムに沿ってインストールされます。ただし、システムを起動できるようにするには、システムについて知る必要があります。そのため、新しいOSのインストールやカーネルのアップグレードなど、マシンに存在するシステムに重要な変更があった場合は、Grubを更新する必要があります。存在する唯一のGrubを削除すると、システムは起動しません。 1台のマシンに多数のGrubが存在する可能性がありますが、メインまたはアクティブなのは1つだけです。 Grub以外にも、（Grubの代わりに）使用できる他のブートローダーがあります。 Windowsには独自のブートローダーがあり、マシン全体のメインローダーとして設定できます。