ブートパーティションをlvmベースのパーティションに置くことはお勧めできません。しかし、とにかく私はそれをします。もしそうなら、私が持っている唯一の問題は、時々新しいLinuxディストリビューションをインストールし、ブートパーティションをlvmに入れたときにgrubがそれを検出しないことです。このgrub-mkconfigコマンドはファイルを生成するときにエラーを生成しますgrub.cfg。しかし、これがlvmベースのブートパーティションの唯一の問題であれば大丈夫だと思います。私は問題を解決する方法を知っているので、ブートする予定のブートパーティションの正しいアドレスを提供するだけで、すべてがうまく機能します。
それでは、この他にもlvmが問題を引き起こしますか？私の考えでは、lvmが非常に柔軟でシステム速度を低下させないからです。
答え1
これはパフォーマンスの問題ではなく、トラブルシューティングと解決の問題です。/boot起動場所です。システムの他のすべてを起動するファイルがある場所です。
時には問題を解決する必要があるかもしれません（例：grubの設定や同様の問題）。
これを行う必要がある場合は、最小の共通分母型のファイルシステムを使用してできるだけ簡単にすることが便利です。たとえば、構成ファイルを編集するには、ドライブを取り外して別のボックスに挿入する必要があります。
あなたがこの場所にいるなら、いいえLVMを読む前に鮮やかに「ファジー」したいです:)
答え2
私は長年Fedoraの/bootLVMファイルシステム内のディレクトリを使用してきましたが、/問題はありませんでした。
/単一の物理ディスクをボリュームグループの単一の物理ディスクにするには注意が必要です。vgmainその物理ドライブ用のボリュームグループと、他のすべてのドライブvgdata用の別のボリュームグループがあります。
問題の解決中にハードドライブを別のコンピュータに取り込む必要がある場合は、これが重要です。 LVMが複数の物理ドライブで構成されている場合は機能しません。しかし、それが一人の人で構成されている場合は、それです。
しかし、この種のトラブルシューティングの状況を経験したことはありません。
最新のFedoraインストールでは、これを自動的に実行することはできません。/bootインストール中に通常のパーティションに入れて正常に起動し、手動でコンテンツをLVMファイルシステムに移動する必要があります/。/bootLVMの下の通常のディレクトリのように見えるように内容を再構成/し、/boot2以前のブートパーティションのようにgrub install /dev/sd?正しいパスで構成されていることを確認してください。再起動して/boot2ファイルシステムを削除した後で使用できるように、パーティションをLVMに再度含めます。
答え3
私が言ったように、grubがLVM/bootファイルシステムを検出できない場合そして grub-mkconfig通常、ビルド時にエラーが発生します。grub.cfgこれは、この構成を回避し、より良いグラブサポートを持つ構成に切り替えるのに十分な理由があるようです。 「意図したブートパーティションに正しいアドレスを提供してください。
基本的でほぼ必要な機能により、ブートローダは単純なディスクパーティション上の単純なファイルシステムにアクセスし、そこから次の手順をロードできます。それが実際にすべきすべてです。 LVMなどのコンテナの構文解析やプリブート環境での複数のディスク処理などのブートローダのより多くの機能は、より多くのLinux（カーネル）機能をgrubに複製する必要があることを意味します（より多くのコード、より多くのバグ）。しかし、完全に正確ではありません。より混乱した環境とより複雑な環境全体の両方で同じように動作します。ブートストラップについては単純なほど良いです。