PXE 和 GRUB - 如何排除故障?

PXE 和 GRUB - 如何排除故障?

我正在努力设置网络启动,并让它在一个主板上工作,但它似乎不太适用于另一块主板;我没有看到足够的输出来找出原因。

因此,“PXE 服务器”上的设置是 DHCP 和 TFTP 驻留在同一服务器上,并且 DHCP 配置为:

root@vogon:/etc/dhcp# cat dhcpd.conf
option domain-name "somewhere.com";
option domain-name-servers 192.168.50.9, 8.8.8.8;
allow booting;
allow bootp;

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

subnet 192.168.50.0 netmask 255.255.255.0 {
  range 192.168.50.10 192.168.50.190;
  option routers 192.168.50.1;
  option broadcast-address 192.168.50.255;
  next-server 192.168.50.9;
  #filename "debian-installer/amd64/bootnetx64.efi";
  filename "grubx64.efi";
}

TFTP 用作/srv/tftp根目录,并且grubx64.efi会读取,/debian-installer/amd64/grub/grub.cfg因为我使用的是 debian 11 发行版中的引导加载程序:

root@vogon:/srv/tftp# cat debian-installer/amd64/grub/grub.cfg
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
set gfxpayload=text
set timeout=-1

menuentry 'Debian 11'{
    set background_color=black
    linux    /debian/11/amd64/linux priority=low vga=788 ---
    initrd   /debian/11/amd64/initrd.gz
}

menuentry "Ubuntu 20.04" {
        linux /ubuntu/20.04/amd64/linux only-ubiquity ip=dhcp ---
        initrd /ubuntu/20.04/amd64/initrd.gz
}

我已使用此设置在配备 AMD Ryzen 9 5950X CPU 的 ROG Strix X570-F Gaming 主板上成功安装了 Debian 11 和 Ubuntu 20.04。我/var/log/syslog从 tftp 服务器看到以下内容:

Jul  8 13:33:33 vogon in.tftpd[45602]: RRQ from 192.168.50.161 filename grubx64.efi
Jul  8 13:33:33 vogon in.tftpd[45602]: tftp: client does not accept options
Jul  8 13:33:33 vogon in.tftpd[45603]: RRQ from 192.168.50.161 filename grubx64.efi
Jul  8 13:33:34 vogon in.tftpd[45604]: RRQ from 192.168.50.161 filename /debian-installer/amd64/grub/x86_64-efi/command.lst
Jul  8 13:33:34 vogon in.tftpd[45605]: RRQ from 192.168.50.161 filename /debian-installer/amd64/grub/x86_64-efi/fs.lst
Jul  8 13:33:34 vogon in.tftpd[45606]: RRQ from 192.168.50.161 filename /debian-installer/amd64/grub/x86_64-efi/crypto.lst
Jul  8 13:33:34 vogon in.tftpd[45607]: RRQ from 192.168.50.161 filename /debian-installer/amd64/grub/x86_64-efi/terminal.lst
Jul  8 13:33:34 vogon in.tftpd[45608]: RRQ from 192.168.50.161 filename /debian-installer/amd64/grub/grub.cfg
Jul  8 13:33:37 vogon in.tftpd[45609]: RRQ from 192.168.50.161 filename /ubuntu/20.04/amd64/linux
Jul  8 13:33:40 vogon in.tftpd[45610]: RRQ from 192.168.50.161 filename /ubuntu/20.04/amd64/initrd.gz

然而,使用另一块主板,ASUS ProArt Z690-CREATOR WIFI Intel Z690 PCIe 5.0 ATX 和 Intel Core i9 12900KS 特别版 16 核 Alder Lake Unlocked CPU,我只在日志中看到以下内容:

Jul 12 10:49:00 vogon in.tftpd[58652]: RRQ from 192.168.50.136 filename grubx64.efi
Jul 12 10:49:00 vogon in.tftpd[58652]: tftp: client does not accept options
Jul 12 10:49:00 vogon in.tftpd[58653]: RRQ from 192.168.50.136 filename grubx64.efi

以及文本“欢迎使用 GRUB!”在客户端屏幕上。该文本仅在引导加载程序中找到,grubx64.efi因此看起来它实际上开始运行,但从未继续寻找其他文件。

对于我可以采取哪些措施来进一步解决此问题有什么建议吗?

答案1

option boot-size您的 dhcpd 配置中似乎没有该行。某些 UEFI 实现要求此选项用于指示 UEFI PXE 引导加载程序文件的大小,以便 UEFI 固件能够提前为其分配正确的内存量。

添加选项(指定正确的大小)不会造成任何损害,并且可能有助于某些 UEFI 实现。因此,请运行du -B 512 /srv/tftp/grubx64.efi以确定文件的大小grub64.efi(以 512 字节块为单位),然后添加

option boot-size <size in blocks>;

subnet在您文件的声明中dhcpd.conf

定义该boot-size选项显然是早期版本 UEFI 规范中 PXE 启动的要求,但如果后续版本将其设为可选,或者如果某些固件作者刚刚选择编写一个 PXE 启动文件下载例程,我不会感到惊讶使用 TFTPtsize选项请求 TFTP 服务器在开始之前告知传入文件传输的总大小(如果该选项可用)。

如果添加该option boot-size行没有帮助,并且固件没有为您提供任何有用的诊断信息,那么您可能需要转储 TFTP 流量并对其进行分析(例如使用wireshark)以验证整个文件是否已传输。在 PXE 引导服务器上,您可能会执行以下操作:

tcpdump -i eno1 -Knpvv -s0 -w pxe-tftp.cap udp

然后在 tcpdump 运行时尝试 PXE 引导,然后按Ctrl+C停止 tcpdump。您可能无法在 tcpdump 中仅过滤 TFTP 数据包,因为 TFTP 服务器可能会分配不同的端口用于向客户端发送数据,并且您无法提前知道该端口是哪个端口。

在 Wireshark 中打开转储后,只需tftp在过滤器表达式栏中输入,您将只看到您感兴趣的 TFTP 数据包。然后右键单击数据包列表窗口中显示的任何 TFTP 数据包,并确保Protocol Preferences-> Trivial File Transfer Protocol->Reassemble fragmented TFTP files被选中。现在您可以找到每个 TFTP 文件传输的最后一个数据包(应该有用地标记),在数据包分析窗口中(last)打开分支,并看到类似以下的行:Trivial File Transfer Protocol

[nn TFTP Fragments (nnnnn bytes): ...]

(nnnnn bytes)部分将告诉您文件传输的总大小。如果它与传输文件的实际大小不匹配,您可能已经找到原因了。不过,修复它可能需要固件更新。

相关内容