RE: iPXE efi chainloading grub2 pxe efi file

[Rivard, Matthew T]

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:address@hidden 
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:address@hidden
> 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:address@hidden
>> Sent: Tuesday, October 13, 2015 11:14 PM
>> To: Rivard, Matthew T; The development of GNU GRUB; 
>> address@hidden; 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:address@hidden
>>> Sent: Thursday, September 17, 2015 8:52 PM
>>> To: Rivard, Matthew T; address@hidden
>>> 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
>>>> address@hidden
>>>> https://lists.gnu.org/mailman/listinfo/help-grub
>>>>
>>>
>>
>