☰

UEFIブートは/ dev / sdaでは実行されませんが、回復DVDでは機能します。

tag-icon • tag-icon rhel uefi boot-loader hyper-v
UEFIブートは/ dev / sdaでは実行されませんが、回復DVDでは機能します。

RHEL 7.9を実行する第1世代の仮想マシンを搭載したWindows 10ノートブックにHyper-Vがインストールされています。 UEFIブートを使用してGen 2 VMで実行するように更新しようとしています。

Gen 2仮想マシンへの移行中は、UEFIブートコードを/ bootパーティションにインストールする必要があります。

私に必要な次のパッケージをインストールしました。

grub2-efi-x64.x86_64         (1:2.02-0.07.el7_9.9)
shim-x64.x86_64              (15-11.el7)
grub2-efi-x64-modules.noarch (1:2.02-0.07.el7_9.9)
shim-unsigned-x64.x86_64     (15-9.el7)

efibootmgr -v以下を表示します。

ここに画像の説明を入力してください。

ご覧のとおり、いくつかの他の設定を試してみましたが、efibootmgrそのうち何も機能しないようです。

VM起動設定：

ここに画像の説明を入力してください。

したがって、理論的には\EFI\redhat\shimx64.efi、仮想マシンはから/boot/efi/EFI/redhat/shimx64.efi起動する必要があります。

ここに画像の説明を入力してください。

df -hリカバリDVDから起動するときのI/boot以降のインストールを表示します/dev/sda1。chroot /mnt/sysimage

/bootパーティションのスクリーンショットに示すように、カーネルの有効なinitramfsファイルがあるようです（まだ到達していないと思います）。

ここに画像の説明を入力してください。

また、グラブの設定をリセットしてみました。

grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

ファイルgrub.cfgにはカーネルバージョンの観点から見ると正しく見えるメニュー項目が含まれていますが、grubメニューを見たことがないのでまだここまで届いていないと思います。 UEFIブートローダの問題のようですが、解決策がわかりません。

DVDを取り外してコンピュータを起動すると、Hyper-Vはネットワークアダプタに到達するまで起動順序を下げます。

ここに画像の説明を入力してください。

結局、Hyper-Vは次のことを示しました。

ここに画像の説明を入力してください。

私は何が間違っていましたか？

リカバリDVDから起動し、grubメニューのコマンドラインに移動してをc実行すると、インストールさconfigfile (hd0,gpt1)/efi/EFI/redhat/grub.cfgれているLinux OSを起動できます。

mount | grep -i "boot"オペレーティングシステムから起動すると、以下が表示されます。

/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

答え1

UEFIには「ブートブロック」のようなものがないことを理解する必要があります。UEFIファームウェアはファイルシステムを理解します。そしてファイルのロード。

ブート*.efiファイルは、UEFIファームウェア（またはハイパーバイザー）が理解しているファイルシステムに存在する必要があります。 UEFI仕様にはファームウェアのみが必要です。〜しなければならない他の種類のファイルシステムについて学びます。可能必要に応じて追加できます。

ただし、RHEL 7.xのデフォルトのファイルシステムタイプはXFSであり、HyperVの仮想ファームウェアにはXFSファイルシステムのサポートは含まれていません。

したがって、システムディスクに小さなパーティションを追加し（512Mで十分であれば、それより小さい場合は十分です。最新のディスクでは、ディスクを1 GB未満のパーティションに分割することはファイン管理だと思います）、次の種類に設定する必要があります。システムディスクがMBRパーティションであるかのようにパーティションテーブル0xefまたはGPTパーティションを使用している場合は、選択したパーティションツールを使用してパーティションタイプをESP（= EFIシステムパーティション）に設定します。次に、mkfs.fatそのパーティションで実行し、/boot/efi現在の内容を新しいパーティションに移動できる場所にマウントし、新しいパーティションを/boot/efi。

後でこのefibootmgrコマンドを使用して以前の試行をクリアしてgrub2-install再実行して、正しいUEFIブート変数エントリを自動的にビルドできます。またはefibootmgr、必要に応じて自分で行うこともできます。表示される起動エントリのUUID文字列は、インストールefibootmgr -vするFAT32パーティションのPARTUUIDと一致する必要があります/boot/efi。 （ を利用して確認できますlsblk -o +PARTUUID。）

答え2

上記の答えは現在非常に優れていますが、問題の根本原因を適切に強調しません。

infodumpを読むと、Linux形式の/bootパーティションしかありませんが、UEFIシステムを起動するのに十分ではありません。

ディスクが UEFI で指定した起動可能なディスクレイアウトと一致しません。

前述のように、UEFIを使用すると、ブートローダの設定方法の新しい世界に入り、要件は以前のBIOSアプローチとはまったく異なります。 UEFIは新しいパーティションテーブル形式を使用し、ファイルシステム（！）を理解します。

これは、UEFIファームウェアがディスクをUEFI起動可能ディスクとして認識し、次回から起動するための最も簡単な基本要件です。

  1. ディスクはGPTパーティションスキームを使用してパーティションを分割する必要があります。
  2. ディスクのどこかに、GPTパーティションテーブルに次のものが必要です。一つとまったく一つredhat anacondaのような自動化された単純化設定には、いわゆるESPと呼ばれるべきパーティションがあります。EFI System Partitionこれは通常、約512MBのGP​​Tパーティションです。
  3. パーティションはファイルシステムでフォーマットする必要があり、そのドライバはUEFIファームウェアに配置する必要があります（つまり、VMエミュレーションUEFIチップでもマザーボードチップの内部UEFIインストールに「インストール」）。
  4. すべてのUEFIインストールで、UEFI仕様に従って常に必須でインストールする必要がある唯一のUEFIファイルシステムドライバはFAT32です。つまり、ESPフォーマットの最も安全な（/唯一の）オプションです。
  5. 指定されたESPパーティションには\EFI\BOOT\BOOTx64.EFI特別なUEFI EXE（64ビットシステムの場合）があり、有効な実行可能ブートローダexeである必要があります。
  6. このファイルが見つからない場合は、さまざまなパスを確認できますが、EFIVARはefibootmgrエディタとして使用されるカスタムブートローダexeパスですべてのパスをオーバーライドできます。

設定には、ファイルシステムがマウントされたsda1パーティションが1つしかないようです。xfs/boot

もちろん、UEFIにはXFSドライバがインストールされていないため、パーティションを読み取ることはできません。 XFSドライバを使用してもESPタイプでない限り、パーティションから起動できません。

を追加するのを忘れたので、これが最善の推測ですfdisk -l。

最新のUEFIでは、LinuxはESPをインストールしませんが、/boot/boot/efiのように/boot内のより深い場所にインストールされます!

修正方法は比較的簡単です。パーティションテーブルがGPTタイプであることを確認し（grub行によると、すでにGPTタイプである）、新しいパーティションを追加してFAT32でフォーマットし、パーティションテーブルがGPTタイプではないことを確認する必要がESP typeあります。一般タイプの/boot場合として表示されます。ESP/bootLinux filesystem

GPTスキームでは、パーティションタイプはUUIDです（ただし、パーティションタイプUUIDとパーティション識別UUIDを混同しないでください！）。したがって、ESPはEFI System (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)正確なタイプですLinux filesystemが、いくつかのタイプの1つLinux root (x86-64) (4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709)です。 Linuxタイプ/boot。

これで、UEFIはESPにのみ興味を持ち、ESPを見つけることができる限り、そこで見つけたすべてのUEFI exeを実行します。この「魔法の」exeは「ブートローダ」と呼ばれたプログラムです。実際のオペレーティングシステムをロードする必要があります。

これで、ブートローダの「インストール」がexeをFAT32形式のESPにコピーするのと同じくらい簡単になったため、ブートローダのインストールプロセスはユーザーにとって「簡単になりました」。 UEFI exeはWindows PE exeから派生したよく知られた形式なので、ブートローダの作成も簡単になりました。その結果、選択できるブートローダが増えました。

いくつかの例は次のとおりです。

  • 再検索
  • システム起動
  • ゴムブーツ
  • システムLinux
  • Linux(!!!)
  • そして…ワーム

はい、そうです。 EFIスタブ（ほとんど）でコンパイルされた最新のLinuxカーネルは、フル機能のUEFIブートローダです。実際、中間ジャンクなしでESPから直接起動します。したがって、すでにUEFIからLinuxに直接簡単に起動できます。

残念ながら、ここで言及されているすべてのブートローダのうち、grubはおそらく最悪です。この否定できない品質のため、選ぶ市販のLinuxディストリビューションの95％（これらの動作はLinuxエコシステムで一般的です）です。

この選択の理由はしばしば非常にトリッキーです。それはおそらく、起動時にgrubが提供する廃止されたカーネル選択メニュー、およびメニューに表示される新しいカーネルインストールをパッケージ管理に統合するためにディストリビューションでスクリプトを完成するのにかかった時間のためです。船から。

したがって、ESPが準備され、正しくフォーマットされており、正しくLinuxで直接起動できるようになっても、「grub問題」と呼ばれる2番目の大きなLinux起動問題が引き続き発生します。

GRUB は UEFI の前にリリースされ、UEFI と同じ方法で古い BIOS の多くのブート問題を解決します。 UEFIはマザーボードに直接プリロードされて提供されることを除いて、デフォルトではWindows 98レベルのオペレーティングシステムの独自バージョンであることに注意する必要があります。また、非常に複雑です。

同様に、GRUBは既存のパーティションにプリインストールされた独自の特殊ミニOSです/boot（UEFIと同様に独自のファイルシステムドライバがあり、UEFIと同様に独自のシェルがあり、UEFIと同様に他の愚かな機能もあります）。誰もそれらを使用して扱う方法を知らないか覚えていません)。これを放棄することができますが、カーネルパッケージの更新（yum / dnfを介して）と組み合わせた自動カーネル更新をしたい場合は、それを修正する必要があります。

したがって、あなたの場合、ブートチェーンはUEFI（OS）-> GRUB（OS）-> LINUX（OS）と同じでなければなりません。

したがって、上記のUEFI前提条件を変更したら、GRUB前提条件を変更する必要があります。 UEFIがESPから起動できるように、GRUBをESPに正しくインストールし、その後Linuxを起動するように設定する必要があります。

これで、Linux/ツリーで動作するためにESPをインストールする場所はディストリビューションによって大きく異なります/boot/efi。

したがって、rm -rfディレクトリを/boot空にするように設定し、vfatドライバを使用してフォーマットされた空のESPをそのディレクトリ（/boot/efi）にマウントする必要があります。これが完了したら、インストールにchrootを適用し、ローカルGRUBにUEFIモードで "/ dev / sda / esp"でインストールを再構築するように強制する必要があります/boot/efi。

これはディストリビューションによって異なり、grub のバージョンによって異なり、次の値になります。

grub-install /dev/sdX
update-grub

到着

grub-install --target=x86_64-efi /dev/sdbX
grub-install --recheck /dev/sdX

chrootの内部から。

正しく実行した場合は、以前に空であったESPパーティションにGRUBインストールファイルが表示され、UUIDを介して同様のものを指す\EFI\redhat\shimx64.efi新しいEFIVARが表示されることがあります。ESP

efbootmgr追加されたエントリを確認できるように、grubの再構築/再インストールの前に未使用のブートefvarをすべて削除することをお勧めします。

完了すると、再起動後にgrubカーネルの起動メニューが表示されます。

この質問に関連する良い夜の読書を提案します。

https://en.wikipedia.org/wiki/GUID_Partition_Table

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface

http://www.rodsbooks.com/efi-bootloaders/

答え3

将来の訪問者のために何をすべきかを正確に文書化します。他の回答に記載されている詳細がないと、はるかに難しくなります。

私のHyper-Vコンピュータを「第1世代」から「第2世代」に切り替えています。主な違いは、ブートメカニズムがBIOSにブートセクタをメモリに直接ロードしてそれを実行させる検証済みの方法で、UEFIファームウェアが「ESP」または「BOOT」パーティションを見つけてEFIをロードできるようにすることです。そこのドキュメントから起動します。

UEFIブートでは、UEFIファームウェアはパーティションを起動可能としてマークする必要があり、UEFIファームウェアはFAT形式のパーティション以外には何も認識できません。 Hyper-VはMicrosoft製品なので、NTFSでフォーマットされたパーティションから起動する方法もわかっています。

Red Hat Enterprise Linux 7は、デフォルトでUEFIファームウェアで読み取れないXFSファイルシステムを使用します。

だから私が取ったアクションは次のとおりです。

  1. マイファイルシステムをバックアップします/boot。私の仮想マシンには、次のようにマウントされたセカンダリVHDXディスクが接続されているので、/dataそれをバックアップの場所として使用します。

    mkdir /data/old_boot
cp --archive /boot /data/old_boot

  2. ファイルシステムをlsblk含むデバイスを確認するために使用されます。/boot

    > lsblk

    NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda             8:0    0   129G  0 disk
├─sda1          8:1    0   499M  0 part /boot
└─sda2          8:2    0 126.5G  0 part
  ├─rhel-root 253:0    0    50G  0 lvm  /
  ├─rhel-swap 253:1    0   7.9G  0 lvm  [SWAP]
  └─rhel-home 253:2    0  68.6G  0 lvm  /home
sdb             8:16   0   512G  0 disk /data

  3. parted既存のパーティションを削除するには/boot：

    > parted /dev/sda
print
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 139GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name       Flags
 1      1049kB  524MB  523MB  xfs          primary    
 2      525MB   136GB  136GB               Linux LVM  lvm

    上記でコマンドを実行しpartedてprintパーティションのリストを表示するので、/dev/sda削除するパーティションは次のようになります。/dev/sda1サイズの違いは、1GB = 1,000,000,000バイトを使用し、1GB = 1,073,741,824バイトを使用するためです。lsblkpartedpartedlsblk

    このコマンドはシェル内で実行され、parted実際にパーティションを削除します。

    rm 1

  4. 新しいパーティションを作成し、UEFIファームウェアに起動しようとしているパーティションであることを知らせるために、またはefiフラグを割り当てます。boot

    > parted
(parted) mkpart primary fat32 1 524
(parted) print
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 139GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name       Flags
 1      1049kB  524MB  523MB  fat32        primary    
 2      525MB   136GB  136GB               Linux LVM  lvm

    フラグ設定boot:

    (parted) set 1 boot on
(parted) print
Model: Msft Virtual Disk (scsi)
Disk /dev/sda: 139GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name       Flags
 1      1049kB  524MB  523MB  fat32        primary    boot
 2      525MB   136GB  136GB               Linux LVM  lvm

    ご覧のとおり、bootフラグがパーティション番号1に設定されました。

  5. 次に、新しいパーティションをフォーマットします。

    > mkfs.fat -F 32 /dev/sda1

  6. /etc/fstab正しい項目が表示されていることを確認する必要があります。Timed out waiting for deviceそれ以外の場合は、LinuxがDependency failed for /boot。以下では、ブートデバイスのパーティションUUIDが必要ですlsblk。

    > lsblk -o +PARTUUID
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT   PARTUUID
sda             8:0    0   129G  0 disk
├─sda1          8:1    0   499M  0 part /boot        93be2242-cfa5-4759-86a8-e563092da88d
└─sda2          8:2    0 126.5G  0 part              484a1ac4-eba0-49b4-9910-b6471462d8b0
  ├─rhel-root 253:0    0    50G  0 lvm  /
  ├─rhel-swap 253:1    0   7.9G  0 lvm  [SWAP]
  └─rhel-home 253:2    0  68.6G  0 lvm  /home

    私の場合、パーティションUUIDは93be2242-cfa5-4759-86a8-e563092da88dあなたのものでした。〜するこれらの識別子は設計上普遍的に一意であるため、互いに異なります。

    /etc/fstab次に、ファイルにデバイスの正しいパーティションUUIDが含まれていることを確認します/boot。

    > cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Mon Jan 16 22:52:23 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/rhel-root   /                       xfs     defaults        0 0
/dev/sda1               /boot                   vfat    defaults        0 0
/dev/mapper/rhel-home   /home                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0

    上記の例では、デバイスが何であるかを/boot知ることができ/dev/sda1、代わりにシステムが起動する前にこの行があることを確認する必要がありますPARTUUID=93be2242-cfa5-4759-86a8-e563092da88d。/dev/sda1使った肉変更を加えるが、気に入らないエディタを試してみてください。変更したら、次のようになります。

    #
# /etc/fstab
# Created by anaconda on Mon Jan 16 22:52:23 2017
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/rhel-root   /                       xfs     defaults        0 0
PARTUUID=93be2242-cfa5-4759-86a8-e563092da88d /boot                   vfat    defaults        0 0
/dev/mapper/rhel-home   /home                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0

  7. /boot前のパーティションからファイルを回復するには、次のコマンドを使用しますcp。

    > cp --archive /data/old_boot /boot

  8. グラップ構成の更新：

    > grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

  9. 必要なUEFIブートコンポーネントをインストールします。

    > yum reinstall grub2 grub2-efi-x64 grubby shim-x64

  10. efibootmgr.efiブートファイルを指すエントリを作成するために使用されます。

    > efibootmgr -c -d /dev/sda -p 1 -l '\efi\EFI\redhat\shimx64.efi' -L 'Red Hat Enterprise Linux'

    efibootmgr次に、UEFIブートオプションのリストを確認します。

    > efibootmgr -v
BootCurrent: 0006
Timeout: 0 seconds
BootOrder: 0000
Boot0000* Red Hat Enterprise Linux      HD(1,GPT,93be2242-cfa5-4759-86a8-e563092da88d,0x800,0xf9800)/File(\efi\EFI\redhat\shimx64.efi)

これで再起動でき、Linuxが正しく起動します。

関連情報