Check the DHCP server logs against known failed machines; e.g. ' cat
/var/log/messages | grep -i "dhcpd dhcp" ' for messages relating to dhcp.
On Wed, Sep 2, 2020 at 12:06 AM wrote:
> Hi, Michael
>
> Thank you for your reply.
>
> Because some machines succeed and some machines fail, they all use
Oliver,
I do it all of the time. However depending on the system Architecture, BIOS
and Driver support, it can and does introduce some problems with certain
hardware. I use the iPXE variables for ${product} to blacklist problematic
hardware.
Best,
Matt
On Mon, Oct 15, 2018 at 7:38 AM Oliver Ra
Victor, yes it is. Whether or not is able to be burned into a ROM is kind
of a vendor-specific question. The 82599 card is a 10GbE chip; many of the
newer systems are UEFI, and I haven't really heard if UEFI-enabled ROMs are
possible or practical.
On Wed, Jun 8, 2016 at 2:08 PM, Victor Salvacruz
Can we see the boot.php generated? iPXE is/ appears to be working, it just
can't find anything in the php script.
On Tue, Mar 8, 2016 at 2:24 AM, wrote:
> Hi,
>
>
>
> We are trying to boot a Hyper-V VM using PXE so we can upload a image and
> get the error below could you assist please?
>
>
>
>
Starting about 23/11/2015 the snponly.efi build in my iPXE build
environment started to fail...
[LD] bin-x86_64-efi/snponly.efi.tmp
bin-x86_64-efi/blib.a(memmap_settings.o): In function
`memmap_settings_fetch':
ipxe/src/core/memmap_settings.c:158: undefined reference to `get_memmap'
bin-x86_64-efi
More information: The lockup is with VMware v11 VMs in VMware Workstation
11. A Couple of physical hosts will simply spontaneously reboot at the
referenced point in process.
On Fri, Aug 21, 2015 at 2:23 PM, Matthew Helton wrote:
> I have observed the following on commit 4e03a: W
I have observed the following on commit 4e03a: When chainloading from
undionly.ipxe to ipxe.pxe there is a hard lockup:
Client system PXEs into undionly.kpxe normally...reaches out for the
${uuid}.ipxe file as normal:
[Error code]
http://mywebserver.mydomain.net/NetBoot/iPXE/bin/ipxe.pxe... ok
PX
bin-x86_64-efi/blib.a(config.o): In function `__requiring_symbol__':
config.c:(.tbl.requiring_symbols+0x0): undefined reference to `obj_vesafb'
make: *** [bin-x86_64-efi/ipxe.efi.tmp] Error 1
I do have CentOS7/SL7 binutils installed... not sure what this is.
Best,
Matt
--
There is never time
All,
Compile went without issue: The compiled code worked on the test cases I
currently have (which have been functionally unchanged for over a year).
Thank You!
Matt
On Mon, Jul 27, 2015 at 5:52 PM, James A. Peltier wrote:
> - Original Message -
> | On 27/07/15 18:05, James A. Peltie
All,
Confirming James results on a RHEL/CentOS 6.6 platform... I'm getting the
same thing.
Best,
Matt
On Mon, Jul 27, 2015 at 12:05 PM, James A. Peltier wrote:
> Now I wind up with
>
>
>
> [BUILD] bin/vsprintf_test.o
> [BUILD] bin/x509_test.o
> [BUILD] bin/aes.o
> cc1: warnings being t
James,
Agreed. Yes, and we need the requirements for GCC and other packages
updated as well. It's fine that a newer platform is needed, but it needs to
be documented.
Michael, Robin?
Matt
On Sun, Jul 26, 2015 at 12:12 PM, James A. Peltier wrote:
> The question is, is this intentional code br
James,
Thank you; it's fixed by migrating to a CentOS 7 build and gcc 4.8.3; as
mentioned before in this list you need xz-devel installed or the make will
croak at "util/zbin lzma.h: No such file or directory"
Best,
Matt
On Sat, Jul 25, 2015 at 7:38 PM, James A. Peltier wrote:
> Ya, I have t
When making:
$ make
[DEPS] core/xferbuf.c
[BUILD] bin/xferbuf.o
cc1: warnings being treated as errors
core/xferbuf.c: In function ‘xfer_buffer’:
core/xferbuf.c:312: error: value computed is not used
make: *** [bin/xferbuf.o] Error 1
$
System GCC: gcc.x86_64 4.4.7-11.e
Commit: 2b15ae55073dfbaf66dbbb41ebe804a16cf47f1e
cc1: warning being treated as errors
core/xferbuf.c: In function 'xfer_buffer':
core/xferbuf.c:312: error: value computed is not used
make: *** [bin/xferbuf.o] Error 1
--
There is never time enough to do it right, but there always seems to be
eno
Which NIC are you using and are you UNDI or using the Native driver? UNDI
VLAN support is very spotty vendor to vendor within the UNDI stack.
On Tue, Jul 7, 2015 at 8:33 PM, James A. Peltier wrote:
> I have a Dell R730XD which seems to be misbehaving. When booting off a
> VLAN it seems that the
Hello list. I was testing the latest enhancement for iPXE. It worked
perfectly on InfoBlox and ISC DHCPD but couldn't get it work on a Windows
DHCP server.. After a little searching, I came up with this:
Explanation of the technical problem:
http://www.mattzuba.com/2011/03/windows-2008-rc2-dhcp-s
Hello All. I received the error: http://ipxe.org/1d704239 last night and
saw a previous thread on the list going back to 2010. The cause in this
case was an active iSCSI Target which had no disk or disk image file
associated with it. Playing with a few other settings (such as deliberately
specifyi
Oliver,
Even the largest DHCP servers don't require bonded interfaces except in
very specific configurations.
This is probably an issue with your DHCP Server: If you are running your
DHCP server on a Bonded interface (generally not required), there may be
some switch-side configuration settings y
I work in a SLES Shop: SLES10 SP2 is a very old distro and is nearly 2
years out of support. Using OpenSLES or updating to SLES10 SP4 will
probably resolve the issue. IIRC there were issues compiling newer versions
of iPXE on the old GCC/Perl used in SLES which were fixed in SLES10 SP3 and
SP4.
To me, you are doing it backwards...
Boot from iPXE from USB: configure network and mount (Blank) iSCSI Target
disk (sanhook) with "keep san 1' and then exit iPXE to boot from the RHEL
CD-ROM.
On Thu, May 9, 2013 at 8:12 PM, Gruher, Joseph R
wrote:
> Hello-
>
> ** **
>
> I am trying to b
Joshua,
What Michael has said is likely your problem: you are out of option
ROM space: To clarify; what Michael is talking about is the RAM the
BIOS requires at POST when enumerating BIOS devices (addon/integrated
option ROMs). The Patch will allow this to be shifted somewhat in memory;
it may hel
I've seen this too with some RealTeks (just last week as a matter of fact);
The Foxconn DS42S/DS52S board exhibits this behavior. I haven't tried yet
with an ISO or a USB Stick, but it looks like a possible bug in UNDI
somewhere. I've got the serial port debugging setup completed
hardware-wise. Nee
If you simply exit out of the script instead of trying a local sanboot,
does it work? What model HP ProLiant?
On Mon, Jan 7, 2013 at 4:22 AM, Christoph Schug
wrote:
> Hello,
>
> I am currently trying to use iPXE for some staged booting environment
> where the boot process of each server can be
ng machine
with that error message.
This is why I would like to see an alternative undionly kernel placed in
memory as escape mechanism if the ipxe.pxe kernel cannot find a Natively
driven NIC.
On Sun, Dec 23, 2012 at 1:28 AM, Joshua Oreman wrote:
> On Sat, Dec 22, 2012 at 11:19 PM, Matth
The stray thought occured to me that instead of scripting
whitelists/blacklists by system model, or relying on external detection
methods (Syslinux or HDT) for NICs, could be ipxe.pxe be altered to carry
an alternate kernel within itself?
The concept would be that as part of the ipxe.pxe binary; i
Once undionly.kpxe is loaded with no embedded script, you will probably
need to do something like the following at minimum:
dhcp
chain http://%pathtoserver%/hw.ipxe
Best,
Matt
On Mon, Dec 3, 2012 at 11:58 PM, shawn belknap wrote:
> i got a laptop to get the undionly.kpxe ipxe defaults, wh
Ruben,
Buenos Dias,
Yes it can, as it turns out, one of the things I am using iPXE
for is to boot ThinClients via HTTP using ThinStation5.1; the only thing I
am doing differently than you is booting via UUID rather than MAC address.
My ThinStation config files are also u
[quote] 2)I didn't build iPXE with the script, I'm just trying to use
undionly.kpxe with the script: [/quote]
Right there is your problem, I think. The script is in a remote location,
it is not embedded in iPXE. So, when you "run" it via chainload, you are
running it from the server (read once), n
Replied to Forum Thread... I can't see any internal reason why that doesn't
work. Maybe some whitespaces somewhere?
On Sat, Nov 24, 2012 at 12:57 PM, Shao Miller wrote:
> Good day, Ty.
>
> 1. What script are you using?
>
> 2. How did you build iPXE with that script?
>
> 3. What version does th
I've noticed some misordering of the UUID rendering in iPXE, Observed in
Asus Gen4 or later Motherboards, and HP's ProLiant Enterprise Servers (G6,
G7, G8)
"The true" UUID in BIOS/PXE is:
Code: 1F00B3E0-00C6-0800-2C4A-BCAEC5280EAD
as rendered in the BIOS, PXE UNDI, OS and the iLO information hea
30 matches
Mail list logo
