前言

我們產品是支持UEFI安裝的，在很多款機器上都正常的安裝。今日在浪潮服務器和技嘉服務器上都遇到一次，可以安裝，但是無法正常啟動。

所以我們必須要解決此問題，來支持更多的硬件。

基礎知識

EFI的全稱是，Extensible Firmware Interface ， UEFI是Unified EFI。

我們以安裝好的Linux系統為例，如何查看我們機器使用的是UEFI還是Legacy呢？

答案是查看如下文件是否存在：

/sys/firmware/efi

下面的輸出分別是以Legacy和UEFI模式的情況下，各自的輸出情況。

# 沒有efi 目錄，Legacy模式

root@node243:/sys/firmware# ll

total 0

drwxr-xr-x 4 root root 0 Jul 2 11:16 ./

dr-xr-xr-x 12 root root 0 Jul 2 11:15 ../

drwxr-xr-x 5 root root 0 Jul 2 16:43 acpi/

drwxr-xr-x 12 root root 0 Jul 2 16:43 memmap/

# 有efi 目錄， UEFI模式

root@node245:/sys/firmware# ll

total 0

drwxr-xr-x 5 root root 0 Jul 2 16:33 ./

dr-xr-xr-x 12 root root 0 Jul 2 11:29 ../

drwxr-xr-x 5 root root 0 Jul 2 16:43 acpi/

drwxr-xr-x 5 root root 0 Jul 2 16:33 efi/

drwxr-xr-x 16 root root 0 Jul 2 16:43 memmap/

在我們的系統盤上，有單獨的一個分區，是boot 分區：

root@node245:/sys/firmware# parted /dev/sda print

Model: AVAGO MR9361-8i (scsi)

Disk /dev/sda: 16.0TB

Sector size (logical/physical): 512B/4096B

Partition Table: gpt

Disk Flags:

Number Start End Size File system Name Flags

1 262kB 538MB 538MB fat32 EFI boot, esp

2 538MB 103GB 102GB ext4

3 103GB 131GB 27.6GB linux-swap(v1)

4 131GB 16.0TB 15.9TB

在fstab中也會有相應的條目：

root@node245:/sys/firmware# cat /etc/fstab

# /etc/fstab: static file system information.

#

# Use 'blkid' to print the universally unique identifier for a

# device; this may be used with UUID= as a more robust way to name devices

# that works even if disks are added and removed. See fstab(5).

#

#

# / was on /dev/sda2 during installation

UUID=efc5dbbf-8eb5-45ba-94b0-ce5253ed5d8d / ext4 errors=remount-ro 0 1

# /boot/efi was on /dev/sda1 during installation

UUID=92A1-DB43 /boot/efi vfat defaults 0 1

# swap was on /dev/sda3 during installation

UUID=59a84533-d365-4e06-8a55-a2fa63b7e82e none swap sw 0 0

如何查看我們的引導項呢：

這個efibootmgr我們系統默認自帶，如果安裝模式是EFI的話。其中該命令會自動的顯示當前所有啟動項，包括啟動順序。

BootCurrent表示我們當前的系統是哪個啟動項。因此我們當前的系統是：

Boot0000* grubHD(1,200,100600,3a92c3e7-adc5-4fcc-8197-ac21b84b601d)File(\EFI\grub\grubx64.efi)

對于我們的系統來講，EFI分區占據sda的第一個分區：

root@node245:/sys/firmware# lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sda 8:0 0 14.6T 0 disk

├─sda1 8:1 0 512.8M 0 part /boot/efi

├─sda2 8:2 0 95.4G 0 part /

├─sda3 8:3 0 25.7G 0 part [SWAP]

└─sda4 8:4 0 14.4T 0 part

其中 HD(1,200,100600, 3a92c3e7-adc5-4fcc-8197-ac21b84b601d)

1 : partition number

200 : partition offset

100600 : partition size

3a92c3e7-adc5-4fcc-8197-ac21b84b601d : partition GUID:

root@node245:/sys/firmware# ll /dev/disk/by-partlabel/

total 0

drwxr-xr-x 2 root root 180 Jul 2 17:35 ./

drwxr-xr-x 9 root root 180 Jul 2 11:29 ../

lrwxrwxrwx 1 root root 10 Jul 2 11:29 EFI -> ../../sda1

....

root@node245:/sys/firmware# ll /dev/disk/by-partuuid

...

lrwxrwxrwx 1 root root 10 Jul 2 11:29 3a92c3e7-adc5-4fcc-8197-ac21b84b601d -> ../../sda1

....

緊接著的是如下內容

File(\EFI\grub\grubx64.efi)

這指定了我們的OS bootloader 這個文件的類型如下：

root@node245:/boot/efi/EFI/grub# file grubx64.efi

grubx64.efi: PE32+ executable (EFI application) x86-64 (stripped to external PDB), forMS Windows

一般來講，正常安裝好的系統，某個啟動條目后面都有File指定某個文件，我們本次探索技嘉設備，安裝好了之后并不能正確的啟動，我們發現，啟動條目后面并沒有指定對應的File：

我們看到，上面輸出中，并沒有指定File，我們懷疑這也是為什么技嘉設備不能正常啟動的原因，盡管我們在/boot/efi/EFI/grub/存在 grubx64.efi文件。

Fallback Path (回退路徑)

debian幫助文檔中提到，一些機器的EFI可能存在bug：

Weak EFI implementation only recognizes the fallback bootloader

某些比較脆弱的EFI實現，并不能認識我們的bootloader，導致啟動的時候，他會查找默認的回退路徑。

UEFI 規范定義了一種“回退”路徑 (Fallback path)，用于啟動此類啟動管理器項，其工作原理類似于 BIOS 驅動器啟動：它會在標準位置查找某些啟動裝載程序代碼。但是其中的細節和 BIOS 不同。

當嘗試以這種方式啟動時，固件真正執行的操作相當簡單。固件會遍歷磁盤上的每個 EFI 系統分區(按照磁盤上的分區順序)。在 ESP 內，固件將查找位于特定位置的具有特定名稱的文件。在 x86-64 PC 上，固件會查找文件 \EFI\BOOT\BOOTx64.EFI。固件實際查找的是 \EFI\BOOT\BOOT{計算機類型簡稱}.EFI，其中，“x64”是 x86-64 PC 的“計算機類型簡稱”。文件名還有可能是 BOOTIA32.EFI (x86-32)、BOOTIA64.EFI (Itanium)、BOOTARM.EFI(AArch32，即32位ARM)和 BOOTAA64.EFI(AArch64，即64位ARM)。然后，固件將執行找到的第一個有效文件(當然，文件需要符合UEFI規范中定義的可執行格式)。

回到我們的情況，技嘉的機器可能只認 /boot/efi/EFI/BOOT/BOOTx64.EFI 這個回退路徑，因此昨晚我和勝國，將我們自己的文件 /boot/efi/EFI/grub/grubx64.efi 拷貝到了 回退路徑，這樣，之前不能啟動的路徑就可以自如的啟動了。

所以對于我們的問題，比較正確的處理方法是，grub-install執行完畢后， efibootmgr -v

grep grubx64.efi ，如果可以找到我們的File，那么什么也不做，如果找不到，則執行緊急補救不錯，即cp我們的文件到回退路徑。

efibootmgr

這個工具非常有用，可以創建新的啟動項：

創建新的啟動項

–create (-c) 表示要創建條目

–part (-p) 用于提供ESP所在的分區號

–disk (-d) 用于提供ESP所在的磁盤名稱

–label (-L) 用于提供條目名稱

–loader (-l) 用于提供要加載的EFI image

刪除某啟動項

可以使用-B參數刪除某個啟動項：

-b | --bootnum XXXX

Modify BootXXXX (hex)

-B | --delete-bootnum

Delete bootnum

改變啟動順序

-o | --bootorder XXXX,YYYY,ZZZZ

Explicitly set BootOrder (hex). Any value from 0 to FFFF is accepted so long as it corresponds to an existing Boot#### variable, and zero padding is not required.

出現在前面的啟動項，啟動優先級要高。

啟用禁用啟動項：

efibootmgr -a -b X ==> 啟用標號為X的啟動項

efibootmgr -A -b X ==> 禁用標號為X的啟動項

參考文獻

總結

以上是生活随笔為你收集整理的linux uefi无法启动文件,解决UEFI安装无法启动的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。