FOG BIOS And EFI Coexistence
-
There’s another guy that had this issue… he said he just commented out the code for the picture…
But then he ran into a ton of other issues too. He had built his own ROM for his NIC.
-
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?
-
Newer computers are slowly ceasing even supporting BIOS.
-
Also UEFI can boot much faster, and has smarter support of the firmware interface.
-
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
-
[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.
-
There’s also 32bit efi files in the i386-efi folder.
-
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?
-
Yeah, that could rule out other issues.
-
[quote=“need2, post: 47117, member: 21891”]There’s also 32bit efi files in the i386-efi folder.[/quote]
I never even thought of that…
-
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)
-
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.
-
@need2
Documentation / screen shots please. -
Oh but of course.
-
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.
-
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.
-
Just created this article:
https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
-
I should buy you a beer.
-
@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!?
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@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.
