ブートパーティションをlvmベースのパーティションに配置することは推奨されないことをどこかで読みました。しかし、とにかくそれをやっています。その後、私がこれで直面した唯一の問題は、新しいLinuxディストリビューションをインストールして、lvmにブートパーティションを配置したときに、grubがそれを検出できないことです。 grub-mkconfig
コマンドは通常、grub.cfg
ファイルの生成を間違えます。しかし、これがlvmベースのブートパーティションで唯一の問題である場合は、問題ないと思います。私はそれを修正する方法を知っているので、目的のブートパーティションに適切なアドレスを指定してブートすれば、すべてがうまくいきます。
それで、lvmが問題を引き起こす可能性のあるものはこれ以外にありますか?なぜなら、私の意見では、lvmは非常に柔軟であり、システムの速度を低下させなかったからです。
これはパフォーマンスの問題ではなく、トラブルシューティングと問題の修正です。 /boot
はbootstrap場所です-システム内の他のすべてのものから始まるいくつかのファイルがあります。
また、問題(grub configなど)を修正するために、そこにアクセスする必要がある場合もあります。
これを行う必要がある場合は、ファイルシステムの一般的な分母の種類を最小限にして、可能な限り簡単にするのが便利です。ドライブを取り外して別のボックスに入れて、設定ファイルを編集する必要があります。
あなたがこの位置にいる場合、あなたはしないでくださいそれを読むことができるようにするためだけにLVMを生命に「こだわる」必要があることを望みます:).
私が言うように、grubがLVMを検出できない場合は/boot
ファイルシステムandgrub-mkconfig
は通常grub.cfg
の生成を間違えますが、これは理由のようですこの構成を回避し、grubがより適切にサポートするものに切り替えるのに十分です。 「目的のブートパーティションに適切なアドレスを指定するだけ」と言っても、「アドレス」が何を意味するのか、または回避策として正確に何をしているのかはわかりませんが、正直なところ、恐ろしく壊れやすいハックのように聞こえます。
ブートローダーは基本的で実質的に必要な機能として、単純なディスクパーティション上の単純なファイルシステムにアクセスし、そこから次のステージをロードできます。それが本当に必要なことのすべてです。 LVMのようなコンテナーの解析やプリブート環境での複数のディスクのジャグリングなど、ブートローダーのより多くの機能は、grubで複製する必要があるより多くのLinux(カーネル)機能を意味します(より多くのコード、より多くのバグ)が、正確には決してなりません両方の環境で同じように動作し(混乱が増し)、全体的に複雑になります。ブートストラップについては、シンプルな方が良いです。
LVMの「/」ファイルシステム内の「/ boot」ディレクトリをFedoraで長年使用しており、問題が発生したことはありません。
「/」がボリュームグループの単一の物理ディスクに存在する単一の物理ディスクを作成するように注意する必要があります。この物理ドライブに「vgmain」ボリュームグループがあり、残りのすべてに「vgdata」があります。トラブルシューティングの状況でドライブを別のコンピューターに運ぶ必要がある場合、これは重要です。 LVMが複数の物理ドライブで構成されている場合、LVMは機能しません。しかし、それが1つだけで構成されている場合はそうなります。
しかし、私はこのトラブルシューティングの状況を経験する必要はありませんでした。
最新のFedoraインストールでは、それを自動的に行うことはできません。インストール中に「/ boot」を通常のパーティションに配置し、通常どおりに起動して、コンテンツを手動でLVM「/」ファイルシステムに移動する必要があります。 LVM“ /”の下のプレーンディレクトリとして“/boot”、古いブートパーティションとして“/boot2”のように再構成したことを確認してから、“ grub install/dev/sda”または同様のものを作成します。再起動してから「/ boot2」ファイルシステムを削除し、使用できるようにパーティションをLVMに戻します。