ISC DHCPD, specifically, v4.1.1 running on RHEL6.6x64 The code block needed is adding to the top of the config file: "allow bootp;"
Then in the subnet (I call them scopes since I have a wide variety of different dhcps setup in our lab and there's more windows units than linux), A bootp specific range needed to be added: range dynamic-bootp 10.0.100.1 10.0.100.254; Without these two lines, grub won't get a DHCP address after being chainloaded by ipxe when you perform net_bootp efinetX (X represents the adapter number, e.g efinet0, efinet1, etc....). -----Original Message----- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 11:24 AM To: Rivard, Matthew T; The development of GNU GRUB Subject: Re: iPXE efi chainloading grub2 pxe efi file 14.10.2015 21:09, Rivard, Matthew T пишет: > Just going by these definitions of bootp and dhcp here: > https://technet.microsoft.com/en-us/library/cc781243%28v=ws.10%29.aspx > > The net_bootp only works with a bootp enabled scope on the dhcp server after > chaining from iPXE to grub2. Without a "bootp" scope setup on the dhcp, > calling net_bootp on the adapter fails to get an IP address. > What is "bootp enabled scope"? Do you refer to Windows DHCP server? Could you give link to manual that describes this setting? > So, I guess I could more clearly word that the bootp protocol works when > calling net_bootp, but standard dhcp isn't. > Could you make available network traces from both working and non-workign attempts? > > -----Original Message----- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Wednesday, October 14, 2015 11:04 AM > To: Rivard, Matthew T; The development of GNU GRUB > Subject: Re: iPXE efi chainloading grub2 pxe efi file > > 14.10.2015 19:56, Rivard, Matthew T пишет: >> Sorry, I thought I had replied back to this. >> >> I found a work around by calling net_bootp on the adapters (I wrote a manual >> block of 64 potential devices given that that's not an unrealistic number of >> adapter ports to be found in a server in our lab), and setting a bootp range >> on our DHCP server for that purpose. Since there's no command in grub to >> simply tell it to do a standard DHCP on the adapters, > > Huh? net_bootp does standard DHCP on adapters (do not be confused by name). > What do you mean by this? > >> this has been the only feasible workaround to make them play together nicely. >> >> Ironically, executing the chainload from iPXE via embedded script vs their >> shell has solved the issue with it hanging if multiple adapters have IP >> addresses in grub when loading off to a Linux Kernel. >> >> >> >> -----Original Message----- >> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] >> Sent: Tuesday, October 13, 2015 11:14 PM >> To: Rivard, Matthew T; The development of GNU GRUB; >> ipxe-de...@lists.ipxe.org; edk2-devel-01 >> Subject: Re: iPXE efi chainloading grub2 pxe efi file >> >> [Redirecting to grub-devel where similar problem is being discussed >> right now and trying iPXE/EDK2 as well] >> >> 18.09.2015 22:59, Rivard, Matthew T пишет: >>> Thanks, its loading the menu now, however, I appear to be hitting >>> the same problem I was going from grub to ipxe. The adapters are >>> there, but won't autoconfigure, >> >> Exclusive SNP open used by iPXE quite likely tears down PXE information, so >> GRUB has nothing to autoconfigure card from. >> >>> and if I try to manually set an IP address, I see the debugging data start >>> spewing from ipxe (which appears to be still running underneath grub) >>> before the system eventually halts. >>> >> >> Well, now we have two *applications* each holding exclusive open on adapter. >> I do not know details about iPXE but if there is any remote chance it does >> background polling we are back at square one. >> >> Unfortunately I do not really see what we can do in this case (iPXE >> => >> GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case >> though. OTOH I do not know what happens long term. GRUB calls other image >> (let's say iPXE) passes control to it. Now firmware continues to queue >> packets for GRUB MNP instance, which GRUB never consumes. Does not really >> look good either. >> >> In principle the same is true for GRUB pure if it is left sitting in >> menu/CLI for a long time. And for every other active MNP instance. >> >>> I'll try your rollback, but was it mean to come out in the email as a long >>> hash string? >>> >> >> Did you have chance to test it? >> >>> >>> -----Original Message----- >>> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] >>> Sent: Thursday, September 17, 2015 8:52 PM >>> To: Rivard, Matthew T; help-g...@gnu.org >>> Subject: Re: iPXE efi chainloading grub2 pxe efi file >>> >>> 18.09.2015 03:05, Rivard, Matthew T пишет: >>>> I've got a good working EFI Grub2 efi Bootloader that works fine when its >>>> directly handed off to by the DHCP for PXE, however, if I attempt to >>>> chainload it from iPXE snponly.efi, it goes straight to the grub command >>>> prompt. >>>> >>>> I've tried embedding the grub.cfg file via -c on the grub-mkimage command, >>>> but it spews out the grub file as a stream of "command not found prompts" >>>> and then still goes to the grub command line. >>>> >>> >>> Embedded config is processed very early, before normal.mod is loaded, so >>> only commands available at rescue prompts are present. >>> >>>> If I try embedding all of the modules directly into grub.efi during >>>> mkimage, along with the config file, it then throws a grub_divmod64_full >>>> not found error. >>>> >>> >>> Embedding all modules in grub.efi is usually wrong (not all modules can be >>> loaded concurrently) either. >>> >>> Try creating standalone image with grub-mkstandalone. This image contains >>> all grub modules in memory disk (as cpio archive) and grub is configured >>> with $prefix pointing to this disk. You can also add own files, in >>> particular put grub.cfg in memory disk. >>> >>>> What is the ideal way to chain load my grub.efi file from iPXE so that it >>>> works the same as if it was the direct handoff from the DHCP/TFTP server? >>>> >>>> Unfortunately, in order to allow for selecting either our EFI WDS Server >>>> or our EFI Linux Server, I have to use iPXE first, as chainloading >>>> snponly.efi from grub2 ends up with iPXE snp not being able to enumerate >>>> anything from the PCI Bus. >>>> >>> >>> Hmm ... this actually sounds like exclusive SNP open (used by both >>> iPXE and GRUB) messes something up. For testing you could try to >>> revert >>> 49426e9fd2e562c73a4f1206f32eff9e424a1a73 (and >>> f348aee7b33dd85e7da62b497a96a7319a0bf9dd which depends on it) to see if it >>> makes any difference. >>> >>>> Using git pulls for both that were from yesterday. >>>> >>>> Matt R. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Help-grub mailing list >>>> help-g...@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/help-grub >>>> >>> >> > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
