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. So, I guess I could more clearly word that the bootp protocol works when calling net_bootp, but standard dhcp isn't. -----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
