Wanted thoughts on DHCPv6 for eventual DHCPv6 boot.
With RFC5970 existing, is iPXE planning to start making a go of it, or
waiting for Intel to further specify implications for PXE?
If proceeding to implement DHCPv6 netboot, for DUID behavior, will
Running RHEL6 as KVM HOST and replaced the e1000 rom with iPXE. iPXE runs
fine on first VM boot, but if I let the VM boot into RHEL6 guest and then
reboot from RHEL, iPXE hangs with 'PMM+3FFCAD20' as the last thing printed.
(usually has +3FF8Ad00 after when it works).
The gPXE 0.9.7 rom RHEL6
Additionally, if I go to SeaBIOS 0.6.1, it hangs on firstboot in the same
place.
On Fri, Feb 11, 2011 at 10:57 AM, Jarrod Johnson
jarrod.b.johnson+i...@gmail.com wrote:
On Fri, Feb 11, 2011 at 10:43 AM, Michael Brown
mbr...@fensystems.co.ukwrote:
On Friday 11 Feb 2011 15:35:10 Jarrod
I was considering writing a patch for elilo to call iPXE's PXE_FILE_OPEN and
friends. I was wondering if anyone had already done this. Ultimately, I'm
looking to have snponly.efi+elilo work in much the same way
undionly.pxe+pxelinux can work (since iPXE can't load a linux kernel
directly when in
Probably useless 'advice', but if MS would kindly detect the existance of
and use iPXE's http/ftp capable APIs, that'd be the best solution.
On Wed, Jun 8, 2011 at 5:15 AM, tom.lauw...@ext.ec.europa.eu wrote:
Dear iPXE developers,
I'm having the following problem with iPXE; I'm using the
and without
knowing what confuses vmware's boot loader, I'd be likely to induce the same
behavior anyway.
On Wed, Aug 10, 2011 at 3:13 PM, Geoff Lywood glyw...@vmware.com wrote:
- Original Message -
From: Jarrod Johnson jarrod.b.john...@gmail.com
To: ipxe-devel@lists.ipxe.org, Geoff Lywood
Thanks, the magic worked and I sent a revised patch on the elilo side to
their list. Much saner looking.
On Wed, Aug 17, 2011 at 7:13 AM, Michael Brown mbr...@fensystems.co.ukwrote:
On Tuesday 16 Aug 2011 22:03:07 Jarrod Johnson wrote:
I have patched elilo to use IPXE exported capabilities
I know there are faster ways (e.g. replacing the VM's nic rom), but I was
wondering why chainloading ipxe from their virtualized e1000 produces
something excruciatingly slow. There are a few milliseconds of traffic,
then exactly one second of silence, then a few milliseconds of traffic, then
So normally I'd do a typical PXE boot of WinPE to install to a new san, but
in this case I have a little complexity that prevents that at the moment.
So I used tgtd to give me two luns, a blank drive as lun 1 and a windows
install ISO as lun 2.
I tried hooking it as 0x80 for the hard drive and
FYI, it's been in our tree for a while and I think I mentioned it before,
but as a reminder, I have the iPXE protocol exported for other efi
applications to use (mostly thanks to Geoff Lywood for initial pass back in
gPXE days). In conjunction with an elilo patch I submitted to their list
and
Trying to understand precisely the intent of txbuf in the SNP-GetStatus
part of the uefi spec broke by brain, but it seems I'm in good company
judging by vendor behavior and iPXE comments...
So snpnet polls *until* null txbuf (which is the opposite of the use cases
that efi_snp was looking at).
to work, the second being less picky when I
realized that iPXE and probably others do very odd things with txbuf that
would have caused my first change to have infinite transmit loops.
On Sat, Jan 14, 2012 at 12:39 PM, Jarrod Johnson
jarrod.b.johnson+i...@gmail.com wrote:
Trying to understand
There are at least two SNP implementations that potentially do not play
well with snpnet.c expectations (iPXE's own and some versions of at least
one vendor's implementation). iPXE returns a pointer that has nothing to
do with the data transmitted. Another vendor fails to ever return a null
in
declare that interrupts are not coming.
On Sun, Feb 12, 2012 at 8:11 AM, Michael Brown mbr...@fensystems.co.ukwrote:
On Saturday 04 Feb 2012 15:24:13 Jarrod Johnson wrote:
So I'm faced with a few situations where a device makes it appear that it
supports interrupts, but undinet_isr_trigered
:
On Saturday 11 Feb 2012 20:41:36 Jarrod Johnson wrote:
In the same way iPXE exports its capabilities under BIOS in a way that
pxelinux.0 exploits to get better protocols than tftp, export
capabilities
as a UEFI protocol so that other efi binaries may use it instead of tftp.
Can be used together
On Wed, Feb 15, 2012 at 4:35 PM, H. Peter Anvin h...@zytor.com wrote:
On 02/13/2012 07:01 AM, Jarrod Johnson wrote:
In my tests, the patch with better error handling seems to work without
a problem.
My modified elilo and esxi5 bootloader both made it through boot with
command line
I also want to suggest that if there is IPv6 support, it should pay
attention to rfc 6355 as well as rfc 5970. RFC 6355 has been embraced by
UEFI and Microsoft and it makes IPv6 a bit more feasible.
On Tue, Apr 3, 2012 at 2:49 AM, Robin Smidsrød ro...@smidsrod.no wrote:
On 02.04.2012 16:45,
Eager to try it out. Is this only BIOS style boot or does it also do it as
snponly.efi?
On Tue, Sep 18, 2012 at 2:46 PM, Michael Brown mbr...@fensystems.co.ukwrote:
On Tuesday 18 Sep 2012 19:08:32 Andrew Bobulsky wrote:
If you can help it, please don't ever stop making iPXE the absolute
For me, snponly.efi no longer successfully boots, e.g. elilo.efi:
Filename: http://${next-server}/tftpboot/xcat/xnba/nodes/n1.uefi^M
http://10.240.0.7/tftpboot/xcat/xnba/nodes/n1.uefi... ok
http://10.240.0.7/tftpboot/xcat/elilo-x64.efi... ok
Could not boot: No such device
So prior to the commit, snponly latched onto the device as provided from
loaded image. The switch to last_opened_snpdev() seems to not be
working.
On Wed, Apr 10, 2013 at 1:21 PM, Jarrod Johnson
jarrod.b.john...@gmail.comwrote:
This was working for me, but broke as of
fc87adb commit
...
On Wed, Apr 10, 2013 at 1:33 PM, Jarrod Johnson
jarrod.b.john...@gmail.comwrote:
So prior to the commit, snponly latched onto the device as provided from
loaded image. The switch to last_opened_snpdev() seems to not be
working.
On Wed, Apr 10, 2013 at 1:21 PM, Jarrod Johnson
The only thing I'm smart enough to do is go back to
db014f3c23be19e11964d48f2bcb25b54a9bf722. I tried doing various things to
make the snponly 'net0' work despite not being in the PCI device list, but
the quick things I thought to try didn't work and I don't have the time to
do what I think would
vendor is one way or
another.
On Thu, Apr 11, 2013 at 6:52 PM, Michael Brown mbr...@fensystems.co.ukwrote:
On Thursday 11 Apr 2013 14:26:27 Jarrod Johnson wrote:
I'm presuming either something got skipped and snponly 'net0' device
should
have been subjected to magic from efi_pci.c or else
Some care would need to be taken to avoid
recursion.
On this, I think the correct answer would be for the IPXE protocols, check
and uninstall if already there prior to installing new instance of the
protocol. No new device handle needed, just replace the relevant protocols
and leave any ohter
I think my patch to revert shows approximately the best strategy when
dealing with existing SNP device. Do not create a new device, just install
the ipxe protocols relevant to enhancing image load onto the existing one
and ignore the lower level ones that really only make sense when IPXE is
pointing at the NIC, resmbling the way PXE would look without
actually doing PXE.
On Thu, Apr 11, 2013 at 6:52 PM, Michael Brown mbr...@fensystems.co.ukwrote:
On Thursday 11 Apr 2013 14:26:27 Jarrod Johnson wrote:
I'm presuming either something got skipped and snponly 'net0' device
should
have
Did they try to reproduce with the exact same flash procedure as you? Do
you have any other adapters in the system that they may not have had?
The thing I think most likely is that you ran out of option rom space. In
x86 BIOS, it is a very limited area, and quite possibly switching the intel
to
I restored snponly.efi function with a PoC patch:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870
I haven't gotten around to cleaning it up, it could be much better.
On Fri, May 3, 2013 at 8:19 AM, Michael Brown mbr...@fensystems.co.ukwrote:
On
If micahel doesn't get around to it in the next few days, I'll try to
neaten up the ugly edges. To enumurate the ugly edges of that patch if
someone else wants to take a swing:
The 'if (1)' is a placeholder for a function to check loaded image for SNP
protocol support. The snponly snpbus_probe
Since the discission died, I hope to polish up the patch I mentioned
earlier to restore snponly.efi (
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/19447d9c39e06c3d5aabd198736cd23d8e40c870),
I think I'll just go ahead and flesh out the 'if (1)' placeholder and
suggest it be considered
FYI, in the xcat branch, we don't send RST. In our case it was because TCP
services pounding randomly on IPs would cause ipxe to get neighbor table
entries preventing it from talking to intended servers.
On Wed, Jul 10, 2013 at 2:20 PM, Michael Brown mbr...@fensystems.co.ukwrote:
On Wednesday
Meant to send this on list
-- Forwarded message --
From: Jarrod Johnson jarrod.b.john...@gmail.com
Date: Thu, Jul 11, 2013 at 7:27 PM
Subject: Re: [ipxe-devel] iPXE Boot
To: Russ, Danny L. (KSC-ESC-622)[QinetiQ North America - ESC]
danny.r...@nasa.gov
Currently, xCAT is using
Meant to post to list. In short, snponly.efi can be chainloaded from a PXE
boot in UEFI as an application (
https://git.ipxe.org/vendor/xcat/ipxe.git/shortlog) It has a patch not yet
accepted into ipxe main.
However, you mentioned going from .iso. That needs an extra step. Either
an
happen to hit at least a handful of the servers every mass boot attempt).
On Thu, Jul 11, 2013 at 7:21 PM, H. Peter Anvin h...@zytor.com wrote:
On 07/11/2013 04:20 PM, Jarrod Johnson wrote:
FYI, in the xcat branch, we don't send RST. In our case it was because
TCP services pounding randomly
patch, and build snponly.efi, but it seems
not recognized my nics.
xCAT Network Boot Agent
iPXE 1.0.3-130715(f411d) -- Open source ..
Features: HTTP HTTPS iSCSI DNS TFTP EFI
No more network devices
xNBA initialising devices... ok
Thanks,
yixuan
On Fri, Jul 12, 2013 at 7:33 AM, Jarrod
https as well.
So ftp issue seems present for me.
Thanks,
yixuan
On Mon, Jul 15, 2013 at 9:16 PM, Jarrod Johnson
jarrod.b.john...@gmail.com wrote:
In my experience in chainbooting ipxe, I've found the underlying nic to
influence things significantly.
Additionally, xCAT patches esxboot
If trying to use snponly.eif, the following two patches will help:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/73d1ff05b058a2507fda0119825715fa2253d722
and
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/f411dcea1ce12ddcdfafa3fa2a89566a16f86bce
I still have been meaning to make
I noticed that IPv6 was getting some attention and was wondering if some
behind the scenes work was going to be getting it more usable (e.g.
automatic addressing from route advertisements, dhcpv6, specifying global
and link local ipv6 addresses as [] in urls, ability to statically set ipv6
Well, I always do ipxe, then pxelinux, then vmware loader when not uefi
booting.
Since pxelinux.0 comes down using http as does it's config and that config
is loaded straight, I'm not too bothered...
cat /tftpboot/xcat/xnba/nodes/n4
#!gpxe
#netboot esxi5.1-x86_64-hypervisor
set 209:string
I was digging in and just wanted to confirm, there's currently no viable
get_noise provider for SSL to work when compiled as efi?
For reference, I am hitting:
http://git.ipxe.org/ipxe.git/blob/master:/src/crypto/entropy.c#l123
Working backwards my guess was that the only get_noise that would be
Note that with elilo, I patched it to take advantaged of the download
protocol that ipxe provides. It was straightforward for a project that
heavily embraces efi protocols like elilo does.
grub2 has no way to take advantage of ipxe protocol in theory today. They
have their own homegrown ip
Could you try with
http://sourceforge.net/projects/xcat/files/yum/xcat-dep/elilo-xcat-3.14-4.noarch.rpm/downloadthat
version of elilo with elilo config written to boot the image?
e.g.:
default=xCAT
delay=0
image=/tftpboot/xcat/netboot/centos6.4/x86_64/kvm//kernel
label=xCAT
I guess I'm embarking upon trying to provide two stubbed out things in efi.
time: Straightforward enough, use the GetTime() runtime service
entropy. For now ignore the 2.4 RNG since I have no way of testing it,
just port forward the rtc logic:
-call efi_currticks (defined in efi_timer.c)
Seeking comments on:
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/89e0b3c8bab8685c7b81dbffdcca05360de8547f
It seems to pass the checks that DRBG throws at it for now.
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
).
On Fri, Nov 1, 2013 at 12:49 PM, Michael Brown mc...@ipxe.org wrote:
On 31/10/13 22:28, Jarrod Johnson wrote:
Seeking comments on:
https://git.ipxe.org/vendor/**xcat/ipxe.git/commitdiff/**
89e0b3c8bab8685c7b81dbffdcca05**360de8547fhttps://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff
console redirection, the system gets
further. I'm wondering if the serial output was lagging and it is crashing
at the next block generation
On Fri, Nov 1, 2013 at 1:54 PM, Michael Brown mc...@ipxe.org wrote:
On 01/11/13 17:49, Jarrod Johnson wrote:
So my console logging catches 2984 samples
So I found a bug, it's probably easy to fix but I've about burned out my
brain making TLS work in EFI mode.
assert(((cert-extensions.subject_alt_name.names))-prev != NULL) failed
at net/tls.c line 2449
assert(((cert-extensions.subject_alt_name.names))-next != NULL) failed
at net/tls.c line 2449
You can look at xcat.sf.net. xCAT does diskless clients for centos, suse,
and others. It boots things mostly into ramdisk. Has some complicated
options to balance persistence versus stateless, memory usage versus nfs
access, etc.
On Wed, Dec 4, 2013 at 10:42 AM, Richard Hornbaker
For what it is worth, if I remember I plan to pull this into the xNBA
repository when I next merge (I think that'll be tomorrow). I second that
this is an issue in a lot of poorly configured environments. Surprised to
see *VMs* so badly afflicted, but switch timeouts with block-by-default
FWIW, you can look at 'IBM FastSetup', which already employs iPXE in this
manner. They use iPXE on a floppy image as a means to sidestep any DHCP
requirement around netboot. The scheme is easily made workable yet
generic in UEFI mode (i.e. not having to include any specific drivers, just
SNP).
PM, Jarrod Johnson
jarrod.b.john...@gmail.com wrote:
So I found a bug, it's probably easy to fix but I've about burned out
my brain making TLS work in EFI mode.
assert(((cert-extensions.subject_alt_name.names))-prev != NULL)
failed at net/tls.c line 2449
assert(((cert
So ESXi netboot with iPXE download protocol hit's a snag as-is due to some
inadequate code in esxi's boot loader. I have thus far addressed that by
modified their boot loader, but I can also acheive the same effect by
assuring that it's boot device does not have PXE or filesystem protocols on
it.
#define GETKEY_TIMEOUT ( TICKS_PER_SEC / 4 )
What happens if you changed that to 2 instead of 4?
Speaking of issues, FWIW, if you are in something that sends a cursor key
application mode (e.g. esxi serial console), then arrow keys might not work
based on what I see in code review. ESC [ A is
What about iPAddress fields (see my patch earlier in thread)?
On Mon, Mar 31, 2014 at 9:17 AM, Michael Brown mc...@ipxe.org wrote:
On 25/11/13 19:12, Alex Chernyakhovsky wrote:
Are there any other comments or concerns with this patchset? I'd love to
see it merged.
The subjectAltName and
Keep in mind that even with your build issues resolved, you'll likely not
get what you would expect without
https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/73d1ff05b058a2507fda0119825715fa2253d722and
Since I'm rebasing to recent iPXE, thought I'd take the opportunity to ask
if there is general disinterest in snponly.efi? Notably I see that I must
continue to apply my dance to check loaded image for SNP when
last_opened_snpdev finds nothing in efi_image.c and also have to revert
Disable SNP
AM, Jarrod Johnson
jarrod.b.john...@gmail.com wrote:
Since I'm rebasing to recent iPXE, thought I'd take the opportunity to
ask if there is general disinterest in snponly.efi? Notably I see that I
must continue to apply my dance to check loaded image for SNP when
last_opened_snpdev finds
:16, Jarrod Johnson wrote:
Since I'm rebasing to recent iPXE, thought I'd take the opportunity to
ask if there is general disinterest in snponly.efi?
Good timing:
http://git.ipxe.org/ipxe.git/commitdiff/d0cfbd0
It's still a bit rough around the edges, but both snp.efi and snponly.efi
-- http://ipxe.org
Features: HTTP DNS TFTP EFI Menu
iPXE ifstat
iPXE
On Tue, Jul 8, 2014 at 12:40 PM, Michael Brown mc...@ipxe.org wrote:
On 08/07/14 16:55, Jarrod Johnson wrote:
I'm very happy to see snponly.efi and snp.efi concepts available. That
will make my life much better. Thanks
I have attached patch to add iPAddress. IT seemed to work for ipv4, I
confess to not having *tested* the IPv6 path, but it is in there.
From af49713640bf6f077be391b15643d543842804c2 Mon Sep 17 00:00:00 2001
From: Jarrod Johnson jarrod.b.john...@gmail.com
Date: Wed, 9 Jul 2014 15:41:06 -0400
Any thoughts on what's happening? Regretably I doubt I have the requisite
knowledge to dive deeper here..
On Tue, Jul 8, 2014 at 1:45 PM, Jarrod Johnson jarrod.b.john...@gmail.com
wrote:
For now, the results of the latter:
iPXE initialising devices...EFIDRV connecting our drivers
EFIPCI
For what it is worth, when this change got committed ESXi 5.5 guest with
vmxnet3 starts working too. For some reason at first glance the loaded
image does not
see the ipxe download protocol, haven't gotten to look into that yet...
On Tue, Aug 5, 2014 at 12:30 AM, Curtis Larsen lar...@dixie.edu
This is a repeat from a thread, but it was a bit buried, so I thought I'd
send again after the siginifacnt amount of EFI work Michael has been doing:
iPXE initialising devices...EFIDRV connecting our drivers
EFIPCI 0x69588a98 PciRoot(0x0)/Pci(0x5,0x4) cannot read PCI configuration:
No such device
)
Pxebc (68B88110)
On Tue, Aug 5, 2014 at 6:26 PM, Michael Brown mc...@ipxe.org wrote:
On 05/08/14 19:50, Jarrod Johnson wrote:
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)
/IPv4(0.0.0.0)
is the SNP chainloading device
The presence of /IPv4(0.0.0.0) as part of the device
that...
On Wed, Aug 6, 2014 at 11:00 AM, Michael Brown mc...@ipxe.org wrote:
On 06/08/14 15:40, Jarrod Johnson wrote:
EFIDRV 0x691db218
PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0) could not
open device path: Error 0x7f37e08f (http://ipxe.org/7f37e08f)
This error can
So grub can boot a gzipped kernel, I was wondering if there's a syntax I'm
missing to acheive the same end in ipxe?
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
I recently went to refresh our iPXE code and hit a problem, we'd see the
following kernel panic when we chain boot snponly.efi to elilo (long story)
to centos7.5 kernel:
[0.000567] invalid opcode: [#1] SMP
[0.005161] Modules linked in:
[0.008580] CPU: 0 PID: 0 Comm: swapper/0 Not
wrote:
> On Mon, Jun 18, 2018 at 04:01:44PM -0400, Jarrod Johnson wrote:
> > So grub can boot a gzipped kernel, I was wondering if there's a syntax
> I'm
> > missing to acheive the same end in ipxe?
>
> Please elaborate what you want to achieve.
>
>
> Groeten
>
10, 2018 at 03:29:12PM -0400, Jarrod Johnson wrote:
> > On Mon, Jun 18, 2018 at 4:15 PM Geert Stappers
> wrote:
> > > On Mon, Jun 18, 2018 at 04:01:44PM -0400, Jarrod Johnson wrote:
> > > > So grub can boot a gzipped kernel, I was wondering if there's a
> syntax
>
I can confirm same behavior, using bootx64.efi from esxi 7, the following
produces the same behavior he reported:
#!ipxe
chain boot/efi/boot/bootx64.efi -c /path/to/boot.cfg also call
efi_snp_release() of course.
> iPXE then invokes the OS kernel via StartImage(). At this point, the TPL is
>
Alternatively, if efi_snp_old_tpl seems to have been previously assigned,
perhaps don't save a new 'old' value?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I'll second this as a problem. Have been testing 'snponly.efi' and I'm not sure
the circumstances, but occasionally linux will error about trying to exit boot
services, and esxi pretty much always hangs trying to exit boot services (also
some 'keyboard errors' are printed early on) when booted
72 matches
Mail list logo
