Unkown character appears; UEFI boot "ipxe.efi�"



  • Hello together,

    i found a strange behaviour that is nowhere (at least i found nothing) noticed.

    I’ve got a Dell Optiplex 7010 which has two boot option for PXE; UEFI or Legacy.
    When booting with legacy, the bootfile “undionly.kpxe” will be send over from dhcp which is then searched on tftp server. Perfect.

    UEFI bootfile “ipxe.efi”
    The problem is: dhcp server send the right file, but the tftp-server got a wrong request:
    TFTP go the message

    somehow “�” get into the bootfilename.
    I have now checked the dhcp setting for the third time. But everyting looks fine.
    Infoblox is used as dhcp.

    I then checked with Wireshark what the DHCP really sends.
    wireshark dhcp testing

    Could it be that Dell got a firmware bug for uefi booting?
    I testet now 3 different Dell modells, everytime the same result.

    I hope I made a mistake somewhere, otherwise…

    Bonus question: I am not able to start VirtualBox in UEFI PXE mode
    I installed the expansion pack and also checked “efi”.
    But PXE does not boot. Does anyone know what the problem is here?

    -> Not possible Link
    -> second “proof” Link

    Thanks for your time.


  • Moderator

    Well lets do the easy part first.

    1. The 7010s will not pxe boot in uefi mode. There is an issue where iPXE will just hang initializing devices and never continues. The 7010 was the first version of the optiplex’s to support pxe booting in uefi mode. There is no option because its a Dell firmware issue and they will not fix it on such an old model. So what can you do? The easiest is to leave the computer in uefi mode, but through the F12 boot menu boot into pxe booting in bios mode. You can image a uefi computer just fine with FOG in bios (legacy) mode. On the next reboot the target computer will switch to its default uefi mode. So the first boot into OOBE/WinSetup will be uefi.

    2. From your pcap I need to see the actual binary codes being sent. The key to look for is an ascii null character (0x00) after the i in “.efi” If this is not an ascii null then on some computers you will have a failed boot. You typically see this issue on router/switch implementations of dhcp. Windows and linux dhcp servers operate correctly.

    Here is what I’m talking about
    null_char.png
    If the text string is not terminated with a null character some pxe implementations will get confused and grab more characters than in the actual name.



  • @george1421
    Thank you very much, thats all i need to know.


  • Moderator

    @symrex said in Unkown character appears; UEFI boot "ipxe.efi�":

    infoblox

    Ugh, not this again… It must be popular for universities (guess)? (I’m kind of kidding here about the ugh)

    Ok the short answer is you can’t use infoblox to supply useful pxe boot information. The best way to get around this is to install dnsmasq on your FOG server to supply pxe boot information using the proxydhcp protocol.

    I have a tutorial for this: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

    Now the only gotcha is that dnsmasq will only respond to systems on the same subnet as your FOG server. To allow dnsmasq to function across your vlans, you will need to update your dhcp-helper/dhcp-relay service on your router. You need to add the FOG server’s IP address as the last dhcp server in the dhcp-relay list. DNSMASQ using my configuration will only supply pxe boot info and nothing else. The other advantage of using dnsmasq is that it will dynamically switch between bios and uefi boot files based on the target computer. Where infoblox only has static mapping, where you can only boot uefi or bios systems depending on what you set dhcp option 67 to.



  • @george1421 said in Unkown character appears; UEFI boot "ipxe.efi�":

    hat is your dhcp server?

    infoblox


  • Moderator

    @symrex What is your dhcp server?



  • Thank for your fast answer. @george1421

    Yeah that’s a bummer. Also found this article.
    But as you said, i will boot PXE in legacy and use uefi.

    0000 8e 74 ff fb b3 07 b8 ca 3a a4 3a f6 08 00 45 00 .t…:.:…E.
    0010 00 48 70 a3 00 00 40 11 86 d7 8d 2d b4 57 8d 2d .Hp…@…-.W.-
    0020 b4 78 04 3b 00 45 00 34 3e 69 00 01 75 6e 64 69 .x.;.E.4>i…undi
    0030 6f 6e 6c 79 2e 6b 70 78 65 ff 00 6f 63 74 65 74 only.kpxe…octet
    0040 00 74 73 69 7a 65 00 30 00 62 6c 6b 73 69 7a 65 .tsize.0.blksize
    0050 00 31 34 36 38 00 .1468.

    or

    tÿû³¸Ê:¤:öEHp£@×-´W-´x;E4>iundionly.kpxeÿoctettsize0blksize1468

    Binary
    thats the last two character in binary:
    11111111 00000000


  • Moderator

    Well lets do the easy part first.

    1. The 7010s will not pxe boot in uefi mode. There is an issue where iPXE will just hang initializing devices and never continues. The 7010 was the first version of the optiplex’s to support pxe booting in uefi mode. There is no option because its a Dell firmware issue and they will not fix it on such an old model. So what can you do? The easiest is to leave the computer in uefi mode, but through the F12 boot menu boot into pxe booting in bios mode. You can image a uefi computer just fine with FOG in bios (legacy) mode. On the next reboot the target computer will switch to its default uefi mode. So the first boot into OOBE/WinSetup will be uefi.

    2. From your pcap I need to see the actual binary codes being sent. The key to look for is an ascii null character (0x00) after the i in “.efi” If this is not an ascii null then on some computers you will have a failed boot. You typically see this issue on router/switch implementations of dhcp. Windows and linux dhcp servers operate correctly.

    Here is what I’m talking about
    null_char.png
    If the text string is not terminated with a null character some pxe implementations will get confused and grab more characters than in the actual name.


Log in to reply
 

322
Online

7.2k
Users

14.4k
Topics

135.6k
Posts