Major Hayden | 26 Aug 16:53 2014
Picon

Re: Mikrotik RouterOS

> Hi,
> 
> Is there a way to use iPXE with Mikrotik RouterOS?
> 
> Best regards,
> Andrew Cheah
> Mobile: +65 9071 1798

Andrew -

Were you looking to PXE boot the RouterOS image itself and serve it up to Mikrotik devices or did you want to
use your Mikrotik device to serve up PXE to clients on the network?

I'm currently using iPXE to boot clients on two different networks managed by Mikrotik devices (a RB493G
and CRS125-24G-1S-2HnD-IN).  Let me know if I can help.

--
Major Hayden

Robin Smidsrød | 22 Aug 19:30 2014

[ipxe] [build] Avoid using embedded script in VirtualBox named configuration (#26)

With the new build support for the .isarom prefix it is now possible to avoid the embedded script completely and still get the normal autoboot behavior.

As we now have more space it was possible to re-enable the support for MULTIBOOT images.

You can merge this Pull Request by running

git pull https://github.com/robinsmidsrod/ipxe vbox-namedconf-sans-script

Or view, comment on, or merge it at:

  https://github.com/ipxe/ipxe/pull/26

Commit Summary

  • [build] Avoid using embedded script in VirtualBox named configuration

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<p>With the new build support for the .isarom prefix it is now possible to avoid the embedded script completely and still get the normal autoboot behavior.</p>

<p>As we now have more space it was possible to re-enable the support for MULTIBOOT images.</p>

<h4>You can merge this Pull Request by running</h4>
  git pull https://github.com/robinsmidsrod/ipxe vbox-namedconf-sans-script
<p>Or view, comment on, or merge it at:</p>
<p>&nbsp;&nbsp;<a href="https://github.com/ipxe/ipxe/pull/26">https://github.com/ipxe/ipxe/pull/26</a></p>

<h4>Commit Summary</h4>
<ul>
<li>[build] Avoid using embedded script in VirtualBox named configuration</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/26/files#diff-0">src/config/vbox/README</a>
    (14)
  </li>
  <li>
    D
    <a href="https://github.com/ipxe/ipxe/pull/26/files#diff-1">src/config/vbox/embedded.ipxe</a>
    (5)
  </li>
  <li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/26/files#diff-2">src/config/vbox/general.h</a>
    (1)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/26.patch">https://github.com/ipxe/ipxe/pull/26.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/26.diff">https://github.com/ipxe/ipxe/pull/26.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/26">view it on GitHub</a>.</p>
</div>
Robin Smidsrød | 21 Aug 17:01 2014

[ipxe] [build] Added named configuration for VirtualBox (#25)

You can merge this Pull Request by running

git pull https://github.com/robinsmidsrod/ipxe vbox-namedconf

Or view, comment on, or merge it at:

  https://github.com/ipxe/ipxe/pull/25

Commit Summary

  • [build] Added named configuration for VirtualBox

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<h4>You can merge this Pull Request by running</h4>
  git pull https://github.com/robinsmidsrod/ipxe vbox-namedconf
<p>Or view, comment on, or merge it at:</p>
<p>&nbsp;&nbsp;<a href="https://github.com/ipxe/ipxe/pull/25">https://github.com/ipxe/ipxe/pull/25</a></p>

<h4>Commit Summary</h4>
<ul>
<li>[build] Added named configuration for VirtualBox</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-0">src/config/vbox/README</a>
    (16)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-1">src/config/vbox/colour.h</a>
    (0)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-2">src/config/vbox/console.h</a>
    (0)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-3">src/config/vbox/crypto.h</a>
    (0)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-4">src/config/vbox/embedded.ipxe</a>
    (5)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-5">src/config/vbox/general.h</a>
    (28)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-6">src/config/vbox/serial.h</a>
    (0)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-7">src/config/vbox/settings.h</a>
    (0)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/25/files#diff-8">src/config/vbox/sideband.h</a>
    (0)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/25.patch">https://github.com/ipxe/ipxe/pull/25.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/25.diff">https://github.com/ipxe/ipxe/pull/25.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/25">view it on GitHub</a>.</p>
</div>
ya-mouse | 19 Aug 10:14 2014

Re: [ipxe] ConnectX3 support from Mellanox Flexboot (#20)

Mellanox would update their own FlexBoot's codebase to the newer iPXE with IPv6 support and so. Closing.


Reply to this email directly or view it on GitHub.

<div>
<p>Mellanox would update their own FlexBoot's codebase to the newer iPXE with IPv6 support and so. Closing.</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/20#issuecomment-52602980">view it on GitHub</a>.</p>
</div>
ya-mouse | 19 Aug 10:14 2014

Re: [ipxe] ConnectX3 support from Mellanox Flexboot (#20)

Closed #20.


Reply to this email directly or view it on GitHub.

<div>
<p>Closed <a href="https://github.com/ipxe/ipxe/pull/20" class="issue-link" title="ConnectX3 support from Mellanox Flexboot">#20</a>.</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/20#event-154345480">view it on GitHub</a>.</p>
</div>
Mike Fahey | 7 Aug 23:39 2014

network boot 32bit UEFI device

I am trying to network boot an ASUS T100 Model : t100-ta-c1-GR

 

But it fails. This device has a 32bit UEFI chip which is the problem.

 

Is there any way this can be made to work?

 

I have 750 of these device to image with FOG.

 

Thanks guys.

 

 

 

Mike Fahey

Senior Application/Network Administrator

Nazareth Area School District

One Education Plaza Nazareth, PA 18064

Phone 610.759.1170 ext. 1777

Fax: 610.746.7001

mfahey-dS1w0U4UQNpB/ZHmtE5TRw@public.gmane.org

 

<div>
<div class="WordSection1">
<p class="MsoNormal">I am trying to network boot an ASUS T100 Model : t100-ta-c1-GR<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">But it fails. This device has a 32bit UEFI chip which is the problem.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Is there any way this can be made to work? <p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I have 750 of these device to image with FOG. <p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks guys.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><span>Mike Fahey<p></p></span></p>
<p class="MsoNormal"><span>Senior Application/Network Administrator
<p></p></span></p>
<p class="MsoNormal"><span>Nazareth Area School District
<p></p></span></p>
<p class="MsoNormal"><span>One Education Plaza Nazareth, PA 18064
<p></p></span></p>
<p class="MsoNormal"><span>Phone 610.759.1170 ext. 1777<p></p></span></p>
<p class="MsoNormal"><span>Fax: 610.746.7001<p></p></span></p>
<p class="MsoNormal"><span><a href="mailto:mfahey@...">mfahey@...</a><p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
</div>
Jarrod Johnson | 5 Aug 20:50 2014
Picon

snponly.efi broken

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 (http://ipxe.org/2c044087)
EFIPCI 0x68ffe998 PciRoot(0x0)/Pci(0x1F,0x6) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
EFIPCI 0x68ffb698 PciRoot(0x1)/Pci(0x5,0x4) cannot read PCI configuration: No such device (http://ipxe.org/2c044087)
SNP 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) is the SNP chainloading device
EFIDRV 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) has driver "SNPONLY"
EFIDRV 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) disconnecting existing drivers
EFIDRV 0x68b85c18 UNKNOWN connecting new drivers
EFIDRV 0x68b85c18 UNKNOWN could not connect new drivers: Error 0x7f37e082 (http://ipxe.org/7f37e082)
ok

I tried commenting out the disconnect drivers call, which left net0 in ifstat but it didn't actually work.
<div><div dir="ltr">
<div>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:<br>iPXE initialising devices...EFIDRV connecting our drivers<br>
EFIPCI 0x69588a98 PciRoot(0x0)/Pci(0x5,0x4) cannot read PCI configuration: No such device (<a href="http://ipxe.org/2c044087">http://ipxe.org/2c044087</a>)<br>EFIPCI 0x68ffe998 PciRoot(0x0)/Pci(0x1F,0x6) cannot read PCI configuration: No such device (<a href="http://ipxe.org/2c044087">http://ipxe.org/2c044087</a>)<br>
EFIPCI 0x68ffb698 PciRoot(0x1)/Pci(0x5,0x4) cannot read PCI configuration: No such device (<a href="http://ipxe.org/2c044087">http://ipxe.org/2c044087</a>)<br>SNP 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) is the SNP chainloading device<br>
EFIDRV 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) has driver "SNPONLY"<br>EFIDRV 0x68b85c18 PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)/MAC(5CF3FC6E4738,0x0)/IPv4(0.0.0.0) disconnecting existing drivers<br>
EFIDRV 0x68b85c18 UNKNOWN connecting new drivers<br>EFIDRV 0x68b85c18 UNKNOWN could not connect new drivers: Error 0x7f37e082 (<a href="http://ipxe.org/7f37e082">http://ipxe.org/7f37e082</a>)<br>ok<br><br>
</div>I tried commenting out the disconnect drivers call, which left net0 in ifstat but it didn't actually work.<br>
</div></div>
Ajeet_Raina | 5 Aug 12:46 2014
Picon

(Error code 3c0920) Operation Not supported

Dell - Internal Use - Confidential

 

Hello,

 

I am getting the following error while PXE boot on VMware ESXi 5.1.0. I used the latest version of iPXE from ipxe.org.

 

 

Can you please suggest me?

<div><div class="WordSection1">
<p><span>Dell - Internal Use - Confidential </span><p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Hello,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">I am getting the following error while PXE boot on VMware ESXi 5.1.0. I used the latest version of iPXE from ipxe.org.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Can you please suggest me?<p></p></p>
</div></div>
Curtis Larsen | 5 Aug 06:30 2014

Apple EFI SNP set ReceiveFilters patch

Attached is the git diff for changes necessary to make the Apple EFI
allow SNP->ReceiveFilters to actually set SNP->RecieveFilterSetting.

Also included in the patch are a debugging routine to display the
SNP->Mode structure, a modification to snpnet_poll_rx to check if there
is something to receive, a possible typo correction in snpnet_poll_tx,
Michael Brown's change to open EFI driver protocols by GET_PROTOCOL, and
a debugging check for failed calls to DisconnectController.

The behavior seen in the Apple EFI (1.10) on SNP->RecieveFilters is:
- Failure if any of the PROMISCUOUS or MULTICAST filters are included
- Success if only UNICAST is included, however the result is UNICAST |
BROADCAST
- Success if only UNICAST and BROADCAST are included
- If UNICAST, or UNICAST|BROADCAST are used, but the previous call tried
(and failed) to set UNICAST|BROADCAST|MULTICAST, then the result is
UNICAST|BROADCAST|MULTICAST

Yes, this sounds broken to me, but it's the way it works.

So, the modified code does tries using SNP->RecieveFilterMask, then
falls back to UNICAST|BROADCAST|MULTICAST, then UNICAST|BROADCAST, and
finally UNICAST.

I'd be happy to do any further testing, or to clean up the code anyway
you'd like.

Sorry, I didn't configure my editor for tabbed spacing, so I hope you
have a pretty-printer to filter through.

Thanks,

Curtis Larsen

Attached is the git diff for changes necessary to make the Apple EFI
allow SNP->ReceiveFilters to actually set SNP->RecieveFilterSetting.

Also included in the patch are a debugging routine to display the
SNP->Mode structure, a modification to snpnet_poll_rx to check if there
is something to receive, a possible typo correction in snpnet_poll_tx,
Michael Brown's change to open EFI driver protocols by GET_PROTOCOL, and
a debugging check for failed calls to DisconnectController.

The behavior seen in the Apple EFI (1.10) on SNP->RecieveFilters is:
- Failure if any of the PROMISCUOUS or MULTICAST filters are included
- Success if only UNICAST is included, however the result is UNICAST |
BROADCAST
- Success if only UNICAST and BROADCAST are included
- If UNICAST, or UNICAST|BROADCAST are used, but the previous call tried
(and failed) to set UNICAST|BROADCAST|MULTICAST, then the result is
UNICAST|BROADCAST|MULTICAST

Yes, this sounds broken to me, but it's the way it works.

So, the modified code does tries using SNP->RecieveFilterMask, then
falls back to UNICAST|BROADCAST|MULTICAST, then UNICAST|BROADCAST, and
finally UNICAST.

I'd be happy to do any further testing, or to clean up the code anyway
you'd like.

Sorry, I didn't configure my editor for tabbed spacing, so I hope you
have a pretty-printer to filter through.

Thanks,

Curtis Larsen

Oliver Rath | 31 Jul 20:34 2014
Picon

dhcp 44 (netbios) useable as setting?

Hi list,

is it possible to use dhcp 44 (ip address of netbios daemon) in a
ipxe-setting? i didnt found anything about this in the documentation.
Maybe there is a generic way to use dhcp-entries?

I.e. something like

echo ${dhcp/44}
or
echo ${net0.dhcp/44:ipv4}
?

Regards,
Oliver

Michael Brown | 30 Jul 00:20 2014

Xen netfront support

I'm please to announce that iPXE now natively supports Xen netfront 
virtual NICs.  This may be of interest to anyone wanting to use iPXE 
running in a Xen PV-HVM domain.

I have one issue which I'm not sure how to handle, and would appreciate 
feedback from anyone who frequently uses Xen:

For each configured NIC, Xen exposes both an emulated PCI NIC (for OSes 
with no native Xen drivers) and a netfront virtual NIC (for OSes with 
native Xen drivers).  Xen provides a mechanism for OSes to "unplug" the 
emulated PCI NICs.  Operating systems with native Xen drivers will 
typically unplug the emulated PCI NICs to prevent confusion.

iPXE could easily unplug the emulated PCI NICs.  However, this operation 
is irreversible.  If the loaded OS does not include native Xen drivers, 
then it will not be able to see any network devices.  This is undesirable.

iPXE could easily expose both the emulated PCI NICs and the netfront 
virtual NICs (as e.g. net0 and net1).  This works perfectly (since the 
backends are entirely independent; the "hardware" really _is_ providing 
two NICs which happen to have the same MAC address and be connected to 
the same network), but it's somewhat confusing for a user to see:

   iPXE> ifstat
   net0: 56:3c:dc:73:51:7e using netfront on vif/0 (open)
     [Link:up, TX:0 TXE:0 RX:0 RXE:0]
   net1: 56:3c:dc:73:51:7e using rtl8139 on PCI00:04.0 (open)
     [Link:up, TX:0 TXE:0 RX:0 RXE:0]

iPXE cannot easily mask out just the emulated NICs, since we have no 
easy way to identify which ones they are (other than irreversibly 
unplugging them).  Masking by PCI vendor:device IDs known to be used by 
qemu doesn't work, since there's nothing preventing someone using PCI 
pass-through to expose a real physical NIC with the same vendor:device 
ID.  Also, this approach would be fragile since the list of emulated NIC 
types is known to change occasionally.

Any suggestions?

Michael

Gmane