Friday, March 6, 2015

UEFI iPXE boot into debian results in grub shell



For a bit of context, I'm a sysadmin student, trying to expand my network knowledge since it's not my strongest point.



Currently, I'm experimenting with PXE. A few days ago, I set up a few ESXi Virtual Machines, one being a DHCP and TFTP server, and the other two being BIOS and UEFI clients. I managed to boot a debian through PXE, on both BIOS and UEFI machines.




I heard about iPXE and the possibilities it brings (such as booting on HTTP, iSCSI, ...) and decided to give it a go. For now, I'm still trying to boot my local debian netboot installer, I thought I'd test out remote files after making sure the installation was correct.






At this point, this is what my DHCP conf looks like (minus anything not really of interest) :



option arch code 93 = unsigned integer 16;
class "pxe-clients" {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";

option tftp-server-name "192.168.0.5";
next-server 192.168.0.5;
if option arch = 00:00 {
if exists user-class and option user-class = "iPXE" {
filename = "pxelinux.0";
} else {
filename = "undionly.kpxe";
}
} elsif option arch = 00:02 or option arch = 00:06 or option arch = 00:07 or option arch = 00:08 or option arch = 00:09 {
if exists user-class and option user-class = "iPXE" {

filename = "bootnetx64.efi";
} else {
filename = "ipxe.efi";
}
} else {
filename = "UNKNOWN_VCI";
}
}



192.168.0.5 is the LAN IP of the DHCP/TFTP server.



As for my TFTP server's root directory :



root@vmpxe:/srv/tftp# ls -l
total 968
lrwxrwxrwx 1 root root 37 Sep 22 14:01 bootnetx64.efi -> debian-installer/amd64/bootnetx64.efi
drwxrwxr-x 3 root root 4.0K Sep 22 00:21 debian-installer
-rw-r--r-- 1 root root 896K Sep 22 16:00 ipxe.efi
lrwxrwxrwx 1 root root 47 Sep 22 00:21 ldlinux.c32 -> debian-installer/amd64/boot-screens/ldlinux.c32

lrwxrwxrwx 1 root root 33 Sep 22 00:21 pxelinux.0 -> debian-installer/amd64/pxelinux.0
lrwxrwxrwx 1 root root 35 Sep 22 00:21 pxelinux.cfg -> debian-installer/amd64/pxelinux.cfg
-rw-r--r-- 1 root root 64K Sep 22 16:00 undionly.kpxe
-rw-rw-r-- 1 root root 64 Sep 22 00:21 version.info


Again, I insist on the fact that before iPXE everything worked fine on both architectures.
The only changes I made were to download the undionly.kpxe and ipxe.efi files from iPXE's website, and edit the DHCP conf to wrap the filename settings in the if exists user-class and option user-class = "iPXE" {...} else {...} conditions.



Now, the BIOS machine does PXE -> iPXE -> Debian's netboot installer. Everything works fine.




However, the UEFI machine does PXE -> iPXE -> grub shell.



I tried to tcpdump the process but that yielded nothing: all the traffic appears normal and expected. It does not differ greatly from what I had before iPXE.



Any idea what might be happening here ?






EDIT : Further tcpdump testing show that without iPXE, my EFI machine sends RRQ packets for the bootloader and a bunch of other files which, I assume, are referenced by the bootloader itself. However, with iPXE, only the bootloader I only see the bootloader.




So I guess the correct question is : what happens with iPXE for it not to retrieve all those files that are correctly downloaded by a standard PXE ?


Answer



not related to your problem but



for booting EFI64



} elsif option arch = 00:02 or option arch = 00:06 or option arch = 00:07 or option arch = 00:08 or option arch = 00:09 {



should be changed to




} elsif option arch = 00:07 or option arch = 00:09 {



Regarding your question if you boot bootnetx64.efi that's what you get; a Grub screen.



see here:
http://lists.ipxe.org/pipermail/ipxe-devel/2015-December/004532.html



EDIT:
When you load pxelinux.0 depending on its version it will retrieve dynamic components plus pxelinux.0 menu definition. when you load iPXE you do not have those extra files loaded.



No comments:

Post a Comment

linux - How to SSH to ec2 instance in VPC private subnet via NAT server

I have created a VPC in aws with a public subnet and a private subnet. The private subnet does not have direct access to external network. S...