☰

新しいブートパーティションの準備

tag-icon • tag-icon boot uefi
新しいブートパーティションの準備

既存の問題のうち、これパーティションを拡大しようとしていることを除いて、私がやっていることと最も似ているように見えますが、/boot/と/boot/efiが別のパーティションにマウントされる理由と心配せずに進む方法がわかりません。

これまでに新しいパーティションを作成し、ここにマウントして/newBootタスクを実行したので、sudo rsync -a /boot/ /newBoot/切り替えたい新しいパーティションにすべての関連ファイルがあるとします。

$ lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid
NAME                        FSTYPE   SIZE FSUSED LABEL   PARTLABEL          MOUNTPOINT UUID                                   PARTUUID
sda                                  7.3T                                                                                     
└─sda1                      crypto   7.3T                                              4dffc196-9926-43d9-a7c8-38898681f402   85b3a656-4886-4b37-b9c1-2acb0158587a
...
nvme0n1                            931.5G                                                                                     
├─nvme0n1p1                 vfat     512M   5.3M         EFI System Partition
│                                                                           /boot/efi  FD0E-EECA                              587cf214-f068-4879-a833-9dffa5ec6e3d
├─nvme0n1p2                 ext2     488M 313.7M                            /boot      606a1976-d1c2-4246-a256-a8afddb04f84   2e10e277-560f-4f5e-abce-1dce5187a7f0
...
└─nvme0n1p4                 vfat     1.5G        NEWBOOT newboot                       530D-4828                              ea886018-714f-46fb-8f21-785c74543891
$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004
Boot0004* ubuntu    HD(1,GPT,587cf214-f068-4879-a833-9dffa5ec6e3d,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
$ sudo efibootmgr -c -L ubuntuNew -l \\EFI\\UBUNTU\\SHIMX64.EFI
$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004
Boot0000* ubuntuNew HD(1,GPT,85b3a656-4886-4b37-b9c1-2acb0158587a,0xffff,0x3a3535ca9)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0004* ubuntu    HD(1,GPT,587cf214-f068-4879-a833-9dffa5ec6e3d,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)

それで、現在のフォルダに2つのパーティションが含まれている理由を理解していませんが、/boot1つも機能する必要があると思いますか？少なくとも上にリンクされている質問について選択した答えは読まれましたか？

今何が欠けていますか？/etc/fstab？

$ cat /etc/fstab 
...
UUID=606a1976-d1c2-4246-a256-a8afddb04f84 /boot           ext2    defaults        0       2
...
UUID=FD0E-EECA  /boot/efi       vfat    umask=0077      0       1
...

lsblkそして、（@ oldfredのおかげで）によると、efibootmgr -v新しい最初のブートオプションはになり、そうではsda1ありませんnvme0n1p4。sda1それは外付けドライブであり、確かにそれから起動したくありません。なぜデフォルトですか？ ？

  • 新しいパーティションから起動したときに行われない変更は何ですか？
  • 再起動する前にfstabを変更する必要がありますかUUID？/boot
  • 別のパーティションが必要ですか/boot/efi？

ベストアンサー1

/bootとを/boot/efi別々のファイルシステムとして扱うのは冗長ですが、次のようになります。

  • 非常に古いBIOSベースのシステムでは、/bootBIOSの制限を避けるために別々のパーティションが必要になることがあります。
  • UEFIを起動するすべてのシステムには、/boot/efiESPパーティションまたはそれに対応するパーティションが必要です。これは、ファームウェアがそこでブートローダファイルを見つけることを期待しているからです。
  • 個別の暗号化されていない暗号化を使用すると、GRUBが理解しているより制限された暗号化セットの代わりに、ルートファイルシステムでサポートされているすべての暗号化方法を/boot使用できます。cryptsetup

最新の Debian/Ubuntu のデフォルトのパーティション化には 2 つの別々のパーティションがあるため、デフォルトの構成では可能な限り広い範囲のシステムをカバーできます。

コメントで oldfred が述べたように、UEFI は GPT パーティションテーブルでパーティションの一意の GUID が使用する ESP パーティションを識別します。このGUIDはLinuxではPARTUUIDと呼ばれます。lsblk -o +partuuid表示します。

あなたのefibootmgr注文はほぼ正確です。正しいディスクでubuntuNewブートオプションを作成するには、次のものを使用する必要があります。

sudo efibootmgr -c -d /dev/nvme0n1 -L ubuntuNew -l \\EFI\\UBUNTU\\SHIMX64.EFI

efibootmgrPARTUUID自体を見つけて、自動的に使用して新しい開始項目を作成します。ディスクを指定するだけです（ディスクに複数のEFIシステムパーティションがない場合）。

shimx64.efiがロードされると、grubx64.efiDebian / Ubuntuベースのシステムで構成されますgrub.cfg。grubx64.efiファイルには、ディレクトリを含むファイルシステムのファイルシステムUUIDを識別する数行しか含まれていません/boot（別々のパーティションかルートファイルシステムの通常のファイルシステムか）。 。目次）。したがって、Debian / Ubuntuシステムはいつも/boot/grub/grub.cfgシステムがBIOSを使用しているかUEFIを使用しているかにかかわらず、「デフォルト」GRUB構成ファイルがあります。これは、さまざまな世代のシステムが多い場合に便利です。

/boot/grub2/grub.cfg参考までに、RedHat 7と8には、/boot/efi/EFI/redhat/grub.cfgUEFIシステムだけでなくBIOSスタイルシステムにも実際のGRUB設定があります。

しかし、/boot、合計をマージしたい場合は、注意が必要なことがいくつかあります/boot/efi。

  • 指定されたブートローダパスは、efibootmgrESPファイルシステムのルートに基づいています。最初にパスはで始まるので、/boot/efiLinuxの観点からは\\EFI\\UBUNTU\\SHIMX64.EFIを意味します。/boot/efi/EFI/UBUNTU/SHIMX64.EFIUBUNTUのみを使用している場合は、/bootUBUNTUディレクトリを1レベル上に移動するか、ブートローダパスを\\EFI\\EFI\\UBUNTU\\SHIMX64.EFI。
  • /bootGRUBがそこからカーネルとinitramfsファイルをロードできるように理解できるものでなければなりません。 Ubuntu用のGRUBのUEFIバージョンはext2とvfatを明確に理解しているため、ext2とvfatを単一のvfatパーティションに/bootマージしてもGRUBには問題ありません。/boot/efiファームウェアはそのパーティションからSHIMX64.EFIとGRUBX64.EFIを読み取る必要があり、通常のUEFIファームウェアはext2を認識しないため、ext2は使用できません。
  • 起動時に/bootLinuxカーネルではなくGRUBのみが必要です。/bootこれをマウントできず、システムはまだ正常に起動します。ただし、/bootカーネルの更新が正しく行えるようにマウントされたままにしておく必要があります。 （またはアンインストールして非表示にするには、カーネル/etc/kernel/pre*.d/アップデートをインストールする前に自動的にインストールし、特定/etc/kernel/post*.dのカーネルパッケージのインストールと削除が完了した後に再度アンインストールするスクリプトを追加できます。）

要件が何であるかが確かにわからない場合、ブートローダはしばしば「怖くて危険な」と見なされます。一方、一般的にはかなり独立しているため、ブートローダ関連の問題は一般的に修正するのが難しくありません。外部メディアからシステムを起動する最初の障害を克服した後、問題を解決できます。それ。機能しないブートローダを持つシステムが「緩和」されているとは言えません。ちょっとした外的な助けが必要です。

おすすめ記事