☰

LVM-on-LUKSで/bootを使用して暗号化されたDebianインストールを起動します。

tag-icon • tag-icon kernel dual-boot lvm grub luks
LVM-on-LUKSで/bootを使用して暗号化されたDebianインストールを起動します。

grub2ブートローダ設定があり、残りのシステムは暗号化パーティション（LVM-on-LUKS）にあります。 LUKSコンテナの内部には、Kali SanaとDebian 8という2つのオペレーティングシステムと共有スワップパーティションがインストールされています。

これは、フルディスク暗号化でKaliをインストールし、Debian用のスペースを確保することによって設定されました。 grubのインストールはKaliで提供されています。

私はDebian用の2番目の/bootパーティションを作成する方が簡単になることを完全に知っています。しかし、設定された方法を考えると、Debian ブートローダにはスペースが残っておらず、スペースを作成するためにすべてのサイズを変更するのは痛いでしょう。

だからこれは私がgrubでやるべきことです：

  • 暗号化されたパーティションをマウントします（すでにこれを行いました）。
  • Debianのinitramfsとカーネルを起動します（ここで問題が発生します）。

私はこれを調べた後、/boot/grub/custom.cfgファイルを編集してこれを試しました。すべての編集の後、私は実行しsudo grub-mkconfigますsudo update-grub。その後、再起動して起動したことを確認しました。 LUKSコンテナの復号化は可能ですが、initramfsまたはカーネルを見つけることはできません。

これは私のcustom.cfgファイルです。注：私はこれが何をしているのかとてもあいまいです。これはおそらく完全に間違っているようです。

menuentry "Debian 8 Jessie"{
  insmod luks
  insmod lvm
  cryptdevice=UUID=ffe7a64d-e552-4db9-b0f3-1e42be118059:cryptolvm
  set root=/dev/Outsider-vg/Outsider-debianroot
  linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/Outsider-vg/Outsider-debianroot
  initrd /boot/initrd.img-3.16.0-4-amd64
}

上記の注意：cryptdevice=UUID=ffe7a64d-e552-4db9-b0f3-1e42be118059:cryptolvm最初は、set root=/dev/sda5このバージョンのファイルはコンテナの復号化を許可しません。私はそれをどのように機能させるかを既に知っており、それを変更するのが役立つことを確認するために前後に見ています。

私が言及したことがあります。このリンクこのファイルを編集するのに役立ちます。

デフォルトでは、LUKSパーティションの復号化後にgrubが正しいinitramfsファイルとvmlinuzファイルを指すようにする構文を知る必要があります。論理ボリュームの下にありますOutsider--debianroot。私の唯一の本当の問題は、何をすべきかわからないということです。

ちょっとあいまいで申し訳ありません。問題の一部は、私が探しているものがわからないということです。答えはありませんが、custom.cfgの編集に関する包括的なガイドを教えてくれてありがとう。詳細が必要な場合はお知らせください。

編集：追加調査で以下を発見しました。

デフォルトでは、GrubにLVMのルートディレクトリへの正しいパスを提供する必要があります。ファイルシステムを調べたところ、2つの可能なパスが見つかりました：/dev/mapper/volumeGroup-volumeNameと/dev/volumeGroup/volumeName。上記の例では、/dev/mapper/Outsider--vg-Outsider--debianrootとです/dev/Outsider-vg/Outsider-debianroot。

このディストリビューションを起動するには、正しいルートディレクトリのパスが何であるかを知る必要があります。どちらも正確で、どちらも一緒に使用する必要がありますが、別のパスがないため、それらを使用する必要があります。どんなアイデアがありますか？

また、これら2つのパスの違いは何ですか？それらはそれぞれ何を指すか。/dev/mapper/volumeGroupこれらとの違いは何ですか/dev/volumeGroup？

編集2：/dev/volumeGroup/volumeName最終的な構文によると、これが正しいパスだと思います。このチュートリアル。私はこれを実験し、再度報告する。

注：この問題を解決したら、直接行って整理します。

答え1

次のものが必要です。

menuentry 'Debian' --class debian --class gnu-linux --class gnu --class os {
  load_video
  set gfxpayload=keep
  insmod gzio
  insmod ext2
  insmod fat
  echo  'Loading Linux ...'
  linux /boot/vmlinuz-3.16.0-4-amd64 cryptdevice=UUID=ffe7a64d-e552-4db9-b0f3-1e42be118059:cryptolvm root=/dev/Outsider-vg/Outsider-debianroot rw
  echo  'Loading initial ramdisk ...'
  initrd /boot/initrd.img-3.16.0-4-amd64
}

insmod part_gptただし、grub.cfgにすでに追加されている必要があることに注意してください。lvmそしてluksそれは必要ありません。 grubはカーネルが処理するLinuxイメージのみをロードします（適切なカーネルフックが必要です）。

答え2

Linuxにデバイスマッパーサブシステムがある前は、2.4.x以前のカーネルシリーズにLinux LVMバージョン1がありました。最新バージョンはバージョン2です。

LVM v1 は特別な/dev/vgName/lvNameスタイルパスを使用します。

デバイスマッパーサブシステムとLVM v2が導入されたとき、新しいLVMは以前のバージョンと逆互換する必要があるため、レガシーパス名を実際のデバイスへのシンボリックリンクとして維持しました。

現在LVM v2はデバイスマッパーを使用しているため、「実際の」デバイスはその規則に従います/dev/dm-<number>。これは、低レベルのデバイスマッパーユーザースペースツール（たとえば）には簡単ですが、dmsetup人にとっては不便であるため、すべてのサブシステム（マルチパス、ソフトウェアRAID）、ディスク暗号化、LVM v2などは、関連デバイスを指すシンボリックリンクでより人間におなじみの名前を保ちます/dev/dm-*。これらのリンクは通常下にありますが、/dev/mapper/以前のバージョンとの互換性のために例外がある可能性があります。

したがって、現在のLVMデバイス命名スキームは通常、デバイスへのシンボリックリンク/dev/mapper/vgName-lvNameとして実装されていますが、スキーマを「公式」名として使用します。/dev/dm-<number>しかし、シンプルさと利便性のために、伝統的なLVMv1スタイルの命名スキームは依然として残ります。公式システムとレガシースキームの両方が同じ方法でシンボリックリンクで実装されているため、実質的な違いはありません。

唯一の例外はinitramfs内にあり、単純化のために起動スクリプトは1つの特定の形式のLVMデバイス名のみを処理するように設計できます。その場合は、展開文書に明示的に言及する必要があります。

（複数のデバイスノードが特定のメジャー/マイナー番号の組み合わせを使用できるようにするいくつかのカーネル/バージョンがありましたが、udevこれは確かに貴重なものよりも多くの問題であり、競合状態やその他の不満の可能性を開きます。現代のシステムは通常、各カーネル/バージョンを作成します。デバイスの下に実際のデバイスノードがあり/devます。

関連情報