RE: iPXE efi chainloading grub2 pxe efi file

[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.   

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: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
>>>
>>
>