3

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 ?

2
  • Nitpicky but such things do leave an impression if done wrongly - it is ESXi (ESX integrated), not eSXI. Originally it was called ESX (Elastic Sky X).
    – mzhaase
    Sep 23, 2016 at 10:50
  • @mzhaase : Indeed. I've been typing iPXE too much in google the past few days, the capitalization starts being engraved in my brain I guess. ^^
    – kRYOoX
    Sep 23, 2016 at 10:55

1 Answer 1

1

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.

5
  • Interesting. But how come if I remove the iPXE layer i get the actual Debian installer ? I realise that the installer is a customized grub screen but I can go through the full install without any problem. It's only when I set up the iPXE layer that I get this Bash-like grub shell. As if it failed to retrieve anything beyond the bootloader.
    – kRYOoX
    Sep 23, 2016 at 10:31
  • I was inspired by your answer to compare precisely what happens with and without iPXE. See the EDIT in my post.
    – kRYOoX
    Sep 23, 2016 at 10:45
  • see my answer edit
    – Pat
    Sep 23, 2016 at 12:21
  • Sorry if it's me being a little thick, but I still don't get it. Booting debian WITH iPXE on a BIOS machine works. So apparently, iPXE does not lack the capacity to load up secondary files requested by the bootloader. Also, booting debian WITHOUT iPXE on an EFI machine works. So I assume the way I configured my DHCP and TFTP server does not prevent this process either. Why would the combination iPXE + EFI suddenly make this process broken, loading only the bootloader and nothing else ?
    – kRYOoX
    Sep 23, 2016 at 13:24
  • because BIOS and UEFI NBPs are completely different applications that not always do exactly the same. i.e. pxelinux.0 can chainload to a different BIOS NBP but syslinux.efi is today unable to chainload to an UEFI NBP. If I were you I'd run away from iPXE and I'd stick to standard PXE. you asked why? well if you consider the gained time for HTTP transfer a kernel and a initrd it is not worth the hassle of dealing with it.
    – Pat
    Sep 23, 2016 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .