Threaded Mode | Linear Mode

classen · 2015-02-09, 23:36

Hello,

I'm having some troubles getting a newly purchased machine to boot from an iSCSI LUN served from a NetApp filer.

I can do a network install of CentOS6 or CentOS7 to a fresh LUN. The CentOS installer is able to find the iSCSI target and install the OS. Now my problems begin, as I cannot get the new machine to boot off the remote LUN.

Here is the relevant portion of my dhcpd.conf file:

Code:

host blah-iscsi {

     hardware ethernet 00:25:90:fc:3a:af;

     fixed-address 192.168.20.23;

     option root-path "iscsi:192.168.20.11:::1:iqn.1992-08.com.netapp:sn.1234:vs.4";

     option iscsi-initiator-iqn "iqn.2015-02.blah:1234";

}

During boot I see the following in my dhcp log files:

Code:

Feb  9 14:01:39 dhcpd: DHCPDISCOVER from 00:25:90:fc:3a:af via 192.168.20.1

Feb  9 14:01:39 dhcpd: DHCPOFFER on 192.168.20.23 to 00:25:90:fc:3a:af via 192.168.20.1

Feb  9 14:01:39 dhcrelay: packet to bogus giaddr 192.168.20.1.

Feb  9 14:01:41 dhcpd: DHCPREQUEST for 192.168.20.23 (192.168.1.5) from 00:25:90:fc:3a:af via 192.168.20.1

Feb  9 14:01:41 dhcpd: DHCPACK on 192.168.20.23 to 00:25:90:fc:3a:af via 192.168.20.1

Feb  9 14:01:41 dhcrelay: packet to bogus giaddr 192.168.20.1.

Feb  9 14:01:41 in.tftpd[27549]: tftp: client does not accept options

and if I interrupt the boot process and enter the iPXE command line ping does not work until I type "dhcp" on the command line.

[Image: pre-dhcp_ipxe_ping.jpg]

if I inspect the config settings prior to manually issing a dhcp command it appears that most values are set except for the iqn-iniiator value.

[Image: pre-dhcp_ipxe_config1.jpg]

page2.

it looks like the iqn-initiator value is not properly set. So clearly dhcp is partially working

if I manually issue the dhcp command from iPXE, then inspect the config settings the iqn-initiator value IS getting properly set:

[Image: post-dhcp_ipxe_config1.jpg]

page2.

But back on the iPXE command line, issuing an autoboot still fails.

I'm at a bit of a loss. What to try next?

classen · 2015-02-13, 19:42

more information from my latest attempts.

Tried the following this morning:
1. boot into iPXE command line
2. issue dhcp command
3. go into config and set iqn-initiator value manually
4. exit config
5. sanhook --drive 0x81 ${root-path}
6. sanboot --drive 0x81

[Image: sanboot_manual_error.jpg]

So the SAN device gets registered, but there is a timeout during boot.

I guess the next thing to do is examine the packet trace and see who is not playing nice.

classen · (This post was last modified: 2015-02-19 23:38 by classen.)

a screenshot from wireshark:

[Image: wireshark_ss.jpg]

It looks like things are going fine until about packet 128 when 192.168.20.23 decides to logout and close the connection.

I turned on SCSI and iSCSI debug messages, and rebuilt undionly.kpxe

Code:

make bin/undionly.kpxe DEBUG=scsi:3,iscsi

Now I'm getting into the weeds.

Anyone have a clue what this SCSI error means?

[Image: boot_SCSI_error.jpg]

MultimediaMan · 2015-02-20, 00:03

What image on the iSCSI LUN are you attempting to boot?

classen · 2015-02-20, 01:35

(2015-02-20 00:03)MultimediaMan Wrote: What image on the iSCSI LUN are you attempting to boot?

The /boot partition that was presumable made during installation of CentOS and which hopefully contains the initramfs and grub and all that other goodness.

MultimediaMan · 2015-02-20, 01:37

So, you were able to install CentOS over iSCSI? Or, did you DD an existing CentOS installation to the iSCSI LUN?

classen · 2015-02-20, 02:13

(2015-02-20 01:37)MultimediaMan Wrote: So, you were able to install CentOS over iSCSI? Or, did you DD an existing CentOS installation to the iSCSI LUN?

Yes, I just completed a fresh install of CentOS via iSCSI. I use PXE to boot the initrd

Code:

LABEL CentOS 6 x86_64 Install

        MENU LABEL CentOS 6.5 x86_64 Install

        KERNEL images/centos/x86_64/6/vmlinuz

        APPEND initrd=images/centos/x86_64/6/initrd.img ramdisk_size=100000 ip=dhcp url=http://my.webserver.com/centos/6/os/x86_64

Once the Anaconda installer is running I can configure the iSCSI LUN as an "advanced storage option" and the install goes smoothly.

I've done this for other linux machines that I have, but this new machine is just not behaving, and I'm trying to figure out if it's iPXE or the Supermicro motherboard or the NetApp that is causing the problem.

MultimediaMan · 2015-02-20, 02:25

This seems counter-intuitive, but have you tried NOT configuring iSCSI in the advanced setup during the anaconda installation?

classen · 2015-02-20, 17:41

(2015-02-20 02:25)MultimediaMan Wrote: This seems counter-intuitive, but have you tried NOT configuring iSCSI in the advanced setup during the anaconda installation?

I'm not sure what exactly you're suggesting. I am not installing to a local hard drive so my options are to install to a network device such as FCoE or iSCSI.

The Anaconda installer is able to discover and use the iSCSI LUN as an installation target, and when the installation is complete and I am required to reboot, the chain of boot utilities is somehow just not working.

It looks like iPXE is finding the NetApp and it sees the LUN and checks that it is available and the correct size, but during the next handoff step things fail.

Maybe this has nothing to do with iPXE, but I'm running out of ideas. I may just return this unit and ask fro a different motherboard.

MultimediaMan · 2015-02-20, 20:27

You are getting the gist of what I'm saying... don't select a an iSCSI target in Anaconda: the iBFT is handed off to the Anaconda and NetworkManager. Just treat it as a local install (but without the local disk).