ipxe iscsi boot fails, even in virtualbox

[masterr-10da]

Hi,

I set up an iscsi server running iscs-dhcp-server and tftpd-hpa.
At boot I get the following screen:



allow booting;
allow bootp;
ddns-update-style none;
log-facility local7;
default-lease-time -1;
max-lease-time 7200;
authoritative;
option space ipxe;
option ipxe-encap-opts code 175 = encapsulate ipxe;
option ipxe.keep-san code 8 = unsigned integer 8;
option ipxe.bus-id code 177 = string;

subnet 10.0.0.0 netmask 255.255.0.0 {
use-host-decl-names on;
range 10.0.0.164 10.0.0.192;
#option routers 10.0.0.111;

that's my dhcpd.conf

option domain-name-servers 10.0.0.1;
option broadcast-address 10.0.255.255;
option root-path "10.0.0.111:/var/lib/tftpboot/";
next-server 10.0.0.111;
if not exists ipxe.bus-id {
filename "undionly.kpxe";
option routers 10.0.0.1;
} else {
filename "";
option root-path "iscsi:10.0.0.111:::1:iqn.2013-09.at.lightserver.empower:windows";
option ipxe.keep-san 1;
option routers 0.0.0.0;
}
server-name "empower";
server-identifier 10.0.0.111;
}

but however windows 7 doesn't come up, the boot process quits with a bluescreen.
My router is running is OpenWRT. Do I have to set something special to enable iscsi boot?
I found a guide here > etherboot.org/wiki/sanboot/win2k8_iscsi_install < but the rule

iptables -A forwarding_lan -i br-lan -o br-lan -j ACCEPT

brings an error:

iptables: No chain/target/match by that name.

So I checked with ifconfig:

ifconfig
br-lan Link encap:Ethernet HWaddr A0:F3:C1:78:07:C0
inet addr:10.0.0.1 Bcast:10.0.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8677375 errors:0 dropped:5180 overruns:0 frame:0
TX packets:13955772 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1039227257 (991.0 MiB) TX bytes:17619986844 (16.4 GiB)

Is it very likely OpenWRT is blocking required packet exchange? iptables v1.4.20

best regards

[MultimediaMan]

Where are you actually telling iPXE to boot from the root-path? Because with the information given, I don't think you are. You're close, however.

It looks like you're trying to run iPXE like syslinux. While that is a workable approach, you're going to have to embed some scripts to get it to do what you want. Without a script to run, iPXE is one sad bootloader.

To get iPXE to boot from an iSCSI target, you need:

1) A valid IP address at the initiator side:

e.g.

Code:

dhcp net0

Documentation on this is here.

2) Then you will need to "hook" the IQN which you have given as 'root-path':

e.g.

Code:

sanboot --drive 0x80 ${root-path}

Documentation is here.


What you probably want to do is embed a script into iPXE which does this for you. Better yet, embed a script which calls a script which does this for you:

e.g.

Code:

touch myscript.ipxe

And place into it something like:

Code:

#!ipxe
dhcp net0
chain http://somewebserver.on.your.network/${net0/mac:hexhyp}.ipxe

To embed a script into iPXE, use the following arguments at compile time:

Code:

make bin/undionly.kpxe EMBED=myscript.ipxe

Documentation on this is here.

And then create a file with your MAC in that directory on the server http://somewebserver.on.your.network:

e.g.

Code:

touch 08-00-27-f0-87-56.ipxe

Documentation on chainloading is here.

And place into it something like:

Code:

#!ipxe
sanboot --drive 0x80 ${root-path}

If you're going to try to iSCSI boot Windows, you might want to try reading up on some issues you may run into here.

Specifically, you may want to set in your chainloaded script (08-00-27-f0-87-56.ipxe), the following statement:

Code:

net0/gateway 0.0.0.0

For a script consisting of:

Code:

#!ipxe
net0/gateway 0.0.0.0
sanboot --drive 0x80 ${root-path}

Make sure you read the WDS page to understand what is going on (and why Microsoft is/are off their bloody rocker).

That should get you going.

Best,

M^3

[robinsmidsrod]

MultiMediaMan: The "autoboot" command (default script) does try to boot the root-path if it is present and looks like an iSCSI URL. But obviously that will not allow you to do the net0/gateway 0.0.0.0 hack. But I also notice that the dhcpd config sets that explicitly anyways. So overall it does seem like most of your suggestions have already been followed.

Master: I see ipxe.bus-id being used to detect iPXE instead of using user-class. That could be a problem. The image also shows the network settings _before_ the dhcp was performed, not after. So we don't know if they get applied to the setup or not (I think they are, but would like to be sure).

[masterr-10da]

(2014-01-20 08:53)robinsmidsrod Wrote:  MultiMediaMan: The "autoboot" command (default script) does try to boot the root-path if it is present and looks like an iSCSI URL. But obviously that will not allow you to do the net0/gateway 0.0.0.0 hack. But I also notice that the dhcpd config sets that explicitly anyways. So overall it does seem like most of your suggestions have already been followed.

Master: I see ipxe.bus-id being used to detect iPXE instead of using user-class. That could be a problem. The image also shows the network settings _before_ the dhcp was performed, not after. So we don't know if they get applied to the setup or not (I think they are, but would like to be sure).

I see an error now as I installed portsentry:

Code:

Wed Jan 22 21:05:02 2014 daemon.notice portsentry[1461]: attackalert: UDP scan from host: 10.192.192.1/10.192.192.1 to UDP port: 68
Wed Jan 22 21:05:02 2014 daemon.notice portsentry[1461]: attackalert: Host: 10.192.192.1/10.192.192.1 is already blocked Ignoring

there must be a good reason why the rule

Code:

iptables -A forwarding_lan -i br-lan -o br-lan -j ACCEPT

doesn't apply. What does the error

iptables: No chain/target/match by that name.

mean? To me it looks like the forwarding_lan ruleset doesn't exist anymore.

"ipxe.bus-id being used to detect iPXE instead of using user-class"
Thanks, I'll test if that makes the difference.