4. FOG BIOS And EFI Coexistence

FOG BIOS And EFI Coexistence

  • N
    Moderator

    This is a thread for documenting my travels in making a system that lets FOG boot both BIOS and EFI based computers. Input from others is welcomed.

    I am aware that if you have a Linux based DHCP there are other methods out there that make this more approachable, but the purpose of my work here will be for those who use a Windows DHCP or other DHCP that they cannot modify.

    Currently I am working on using DnsMasq to allow FOG to boot on the network without having to specify a boot file in the DHCP server. This would allow me (in theory) to eventually serve different boot files to different detected architectures. The problem with specifying a boot file in the DHCP is that the file would need to be compatible with all architectures you intend to support, and mixing EFI and BIOS support is (currently) impossible.

    I do have BIOS based devices able to talk to the FOG server which is running DnsMasq, without any network boot related settings specified in my Windows DHCP. The device then is handed off to FOG’s boot process, then boots however is relevant.

    EFI based devices are not receiving any network boot information at the moment. I have tried a few different devices, so I know it is not just one’s issue. I am continuing to work on this.

    Current /etc/dnsmasq.d/ltsp.conf is as follows, mostly taken from the FOG wiki:
    [CODE]port=0

    log-dhcp

    tftp-root=/tftpboot

    dhcp-boot=undionly.kpxe,<FOG-IP>,<FOG-IP>

    dhcp-option=17,/images

    dhcp-option=vendor:PXEClient,6,2b

    dhcp-no-override

    pxe-prompt=“Press F8 for boot menu”, 3

    pxe-service=X86PC, “Boot BIOS”, undionly.kpxe, <FOG-IP>
    pxe-service=IA64_EFI, “Boot IA64”, snponly.efi, <FOG-IP>
    pxe-service=IA32_EFI, “Boot IA32”, i386-efi/snponly.efi, <FOG-IP>
    pxe-service=X86-64_EFI, “Boot x8664EFI”, snponly.efi, <FOG-IP>

    dhcp-range=<FOG-IP>,proxy[/CODE]

    Notes:
    [LIST]
    []Replace <FOG-IP> with the FOG server’s IP address in the form of x.x.x.x
    [    ]I may have more architectures specified than needed, and the delay in boot and quoted messages are just for my debugging. Once in deployment the delay is probably fine as 1 or 0, and no messages should be needed.
    [*]Whatever files you specify to boot with the pxe-service parameter, you will need to make a copy of that ends in ‘.0’ . Don’t ask me why DnsMasq requires this.
    [/LIST]

    0

  • @Uncle-Frank You’re amazing! What you posted is very similar to what I came up with in a thread, but I haven’t gotten around to testing it.

    If you get dnsmasq to work with co-existence then you’re like… everyone’s hero… for real. Because if we can get a rock-solid dnsmasq config for all types of booting - then for 95% of fog setups out there, we’ve eliminated the need to change DHCP. Fog can then come with dnsmasq setup by default and it JUST WORK without further setup.

    In my opinion, Linux DHCP is far superior to Windows DHCP… but dnsmasq would be the ultimate solution if we could just get it to work.

    0
  • S
    Developer

    @need2 said:

    Yeah I really would love to find a way to package something into FOG as well. Unfortunately a lot of current UEFI systems I’ve been working with seem to really hate on the methods that are used to load the extra PXE data onto an existing DHCP Server’s response.

    I just came across this post: http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q1/009216.html

    I am trying to get in contact with him to see why WDS seams to work with proxyDHCP.

    Any new findings on this? I just updated Wayne’s article to include isc-dhcp config for BIOS/UEFI but I guess this is not the preferred way to go, right!?

    1 1 Reply
  • N
    Moderator

    I should buy you a beer.

    1

  • Just created this article:

    https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence

    3
  • N
    Moderator

    Yeah I really would love to find a way to package something into FOG as well. Unfortunately a lot of current UEFI systems I’ve been working with seem to really hate on the methods that are used to load the extra PXE data onto an existing DHCP Server’s response.

    0
    S
     1 Reply
  • Senior Developer

    I really wish we could get this working with a proxyDHCP or native dhcp systems. Maybe a third party utility rather than all requiring linux-dhcp and/or Windows Server 2012 or higher for user class support.

    1
  • N
    Moderator

    Oh but of course.

    0

  • @need2
    Documentation / screen shots please.

    0
  • N
    Moderator

    I finally have all of our licenses in order, so I should be able to push forward with creating the new DHCP as early as next week. Thank you everyone for your input.

    0 1 Reply
  • Developer

    we have it working here with Windows DHCP 2012 - as Junkhacker said really is simple process just create the vendor class then setup the DHCP policy and specify bootfile (option 67 and don’t need to specify option 66 in the policy as it will pick this up from already defined option in the scope)

    1

  • [quote=“need2, post: 47117, member: 21891”]There’s also 32bit efi files in the i386-efi folder.[/quote]

    I never even thought of that…

    0
  • N
    Moderator

    Yeah, that could rule out other issues.

    0
  • J

    I am at home now and can only resume testing in 3 days.

    I downloaded ipxe.efi twice and calculated the checksum for both files.
    I compared the md5-hash with the file on in my tftpfolder and it was trice the same…
    No errors there…

    I tested the ipxe.efi ROM on 2 different machines (intel NUC DC3217IYE and a Lenovo [SIZE=13px][FONT=Ubuntu][COLOR=#555555]ThinkPad Edge E540).[/COLOR][/FONT][/SIZE]Both time, the boot was interrupted as described above.

    I will test snp.efi and snponly.efi in 3 days but I still got the feeling I’m doing something wrong.
    Or is it a coincidence both machines refused to boot from the ipxe?

    Would it help to try a legacy boot from ipxe.kpxe to test the ROM in non-uefi mode?

    0
  • N
    Moderator

    There’s also 32bit efi files in the i386-efi folder.

    0

  • [url]http://fogproject.org/wiki/index.php/Filename_Information[/url]

    .efi files are for UEFI, everything else is for BIOS.

    There are ipxe.efi, snp.efi, and snponly.efi that you can try.

    0
  • J

    Is there a way to find out what NIC’s are supported by ipxe.efi?
    Or a manual to build my own ROM for the NIC?

    What’s the difference between:
    [LIST]
    []intel.efi
    [    ]intel.[B]kk[/B]pxe
    []intel.[B]k[/B]pxe
    [    ]intel.pxe
    [/LIST]
    Can I failover between computers?
    First try ipxe.efi
    Then try intel.efi
    Then try undionly.kpxe
    …
    I can test the hell out of FOG if you want me to ;)

    0
  • N
    Moderator

    Also UEFI can boot much faster, and has smarter support of the firmware interface.

    0

  • Newer computers are slowly ceasing even supporting BIOS.

    0
  • J

    I can comment out the picturecode allright (if I would know in what file to comment :) )

    But I don’t think I’m smart enough to build my own ROM for that NIC.
    Especially since I have at least 5 different computertypes in my network and I would have to build one ROM to rule them all…

    That being said, do we really need uefi (now)?
    I can install 8.1 with legacy boot enabled, right?

    Or am I missing the big picture again? :)

    0
Log in to reply
 

444
Online

6.2k
Users

13.6k
Topics

128.0k
Posts