From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZmQQA-00039V-Ls for mharc-grub-devel@gnu.org; Wed, 14 Oct 2015 14:05:02 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmQPL-00035q-ND for grub-devel@gnu.org; Wed, 14 Oct 2015 14:04:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmQPA-0000Nh-CT for grub-devel@gnu.org; Wed, 14 Oct 2015 14:04:05 -0400 Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:35838) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmQPA-0000NB-13 for grub-devel@gnu.org; Wed, 14 Oct 2015 14:04:00 -0400 Received: by lffy185 with SMTP id y185so16514489lff.2 for ; Wed, 14 Oct 2015 11:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=HTTHVkrKcfez3iFxqbGggOoKEd0gmXZ2zLq7obrVyl8=; b=BUoiesHD1VvPGO4hWYW1mjJzZAmvJZcUx63fsA+40uOT03XqGRqCIY0176I46qwnXL LRoJ4t3zIZwjPlR1Z27ujprMq+Vb4RlRZixa2nsZom/hOS7RSuEPR9XPhEk/RwPif55V pmcWmQG8lcPtV3VbLSlDJ7DQj5T8/tIPeLvMSJ9/LE15cwOn87xZagi+iAyiPqBULMUM IvVQecge2CkiVmuyRQw+6GW0bLHf5AUHvferYk8HXATWflRJTQDO9LEq/ZjmEaG2mAFv F1OeLPEMf2V4HJDM2Ehxg/+sGoUr0/+NayhCYPytcAeDlSbvIoTzumLXZnWkEVOJk0Rf 50WA== X-Received: by 10.25.154.5 with SMTP id c5mr1538761lfe.103.1444845839104; Wed, 14 Oct 2015 11:03:59 -0700 (PDT) Received: from [192.168.1.43] (ppp91-76-142-206.pppoe.mtu-net.ru. [91.76.142.206]) by smtp.gmail.com with ESMTPSA id ba7sm1473590lbc.48.2015.10.14.11.03.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 11:03:58 -0700 (PDT) Subject: Re: iPXE efi chainloading grub2 pxe efi file To: "Rivard, Matthew T" , The development of GNU GRUB References: <55FB8A5F.6040404@gmail.com> <561DF29D.70702@gmail.com> From: Andrei Borzenkov Message-ID: <561E990D.90205@gmail.com> Date: Wed, 14 Oct 2015 21:03:57 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c07::232 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 18:04:16 -0000 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:arvidjaar@gmail.com] > Sent: Tuesday, October 13, 2015 11:14 PM > To: Rivard, Matthew T; The development of GNU GRUB; ipxe-devel@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:arvidjaar@gmail.com] >> Sent: Thursday, September 17, 2015 8:52 PM >> To: Rivard, Matthew T; help-grub@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-grub@gnu.org >>> https://lists.gnu.org/mailman/listinfo/help-grub >>> >> >