SOLVED iscsi PXE boot of bare metal windows machine does not work anymore

[krakoliezene]

After upgrading from 9.2.1.9 to 9.3-release, which went flawless, kudos to the FreeNAS team!!! my windows 7 machine could not pxe-boot anymore from the iscsi target. Both the booting machine as the FreeNAS console say that the target is not available.
The iscsi service is running:ctld.pid does exist and the configuration is exactly what it was under 9.2.1.9. In the Windows machine nothing changed at all.
Does anybody have a clue?

 

[dlavigne]

Anything in /var/log/messages?

 

[mav@]

What do you mean with "the FreeNAS console say that the target is not available"?

Could you try to get packet dump of failed boot attempt with `tcpdump -pi <interface> -s0 -w file port 3260`?

 

[krakoliezene]

/var/log/messages says:
Dec 10 16:27:53 freenas ctld[54860]: 10.0.0.161 (iqn.2000-09.org.etherboot:UNKNOWN): requested target "iqn.2011-03.krakoliezene.istgt:sanboot03" not found
Dec 10 16:27:53 freenas ctld[46196]: child process 54860 terminated with exit status 1

On which host (freenas I guess) and under which circumstances (during boot?)should I execute the commands for the packetdump? I never did that before.

 

[mav@]

Dec 10 16:27:53 freenas ctld[54860]: 10.0.0.161 (iqn.2000-09.org.etherboot:UNKNOWN): requested target "iqn.2011-03.krakoliezene.istgt:sanboot03" not found

And what do you have in your /etc/ctl.conf? Don't you have such target there?

On which host (freenas I guess) and under which circumstances (during boot?)should I execute the commands for the packetdump? I never did that before.

On FreeNAS during Windows boot attempt when above error message is printed.

 

[jpaetzel]

Can you attach /etc/ctl.conf and the output of ctladm devlist -v please?

 

[krakoliezene]

The output of ctladm devlist -v:

LUN Backend Size (Blocks) BS Serial Number Device ID

0 block 41943040 512 7071bcdd3758000 iSCSI Disk 7071bcdd3758000

lun_type=0

num_threads=14

unmap=on

vendor=FreeBSD

product=iSCSI Disk

revision=0123

naa=0x3cc73bdc39a3984f

file=/dev/zvol/pool1/sanboot01

cfiscsi_target=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot01

cfiscsi_lun=0

scsiname=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot01,lun,0

1 block 83886080 512 7071bcdd3758010 iSCSI Disk 7071bcdd3758010

lun_type=0

num_threads=14

unmap=on

vendor=FreeBSD

product=iSCSI Disk

revision=0123

naa=0x37a81825124bbd86

file=/dev/zvol/pool1/sanboot03

cfiscsi_target=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot03

cfiscsi_lun=0

scsiname=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot03,lun,0

2 block 83886080 512 7071bcdd3758020 iSCSI Disk 7071bcdd3758020

lun_type=0

num_threads=14

unmap=on

vendor=FreeBSD

product=iSCSI Disk

revision=0123

naa=0x34336317210eb502

file=/dev/zvol/pool1/sanboot04

cfiscsi_target=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot04

cfiscsi_lun=0

scsiname=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot04,lun,0

3 block 52428800 512 7071bcdd3758030 iSCSI Disk 7071bcdd3758030

lun_type=0

num_threads=14

unmap=on

vendor=FreeBSD

product=iSCSI Disk

revision=0123

naa=0x3232e24f5f4b9855

file=/dev/zvol/pool1/sanboot05

cfiscsi_target=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot05

cfiscsi_lun=0

scsiname=iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot05,lun,0

And /etc/ctl.conf:
[root@freenas] ~# cat /etc/ctl.conf

portal-group pg1 {

discovery-auth-group no-authentication

listen 10.0.0.103:3260

}


auth-group ag4tg_1 {

initiator-portal "10.0.0.0/24"

auth-type "none"

}


target iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot01 {

alias iqn.2011-03.krakoliezene.istgt:sanboot01

auth-group ag4tg_1

portal-group pg1


lun 0 {

option unmap on

path /dev/zvol/pool1/sanboot01

blocksize 512

serial 7071bcdd3758000

device-id "iSCSI Disk 7071bcdd3758000 "

option vendor "FreeBSD"

option product "iSCSI Disk"

option revision "0123"

option naa 0x3cc73bdc39a3984f

}

}


auth-group ag4tg_2 {

initiator-portal "10.0.0.0/24"

auth-type "none"

}


target iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot03 {

alias iqn.2011-03.krakoliezene.istgt:sanboot03

auth-group ag4tg_2

portal-group pg1


lun 0 {

option unmap on

path /dev/zvol/pool1/sanboot03

blocksize 512

serial 7071bcdd3758010

device-id "iSCSI Disk 7071bcdd3758010 "

option vendor "FreeBSD"

option product "iSCSI Disk"

option revision "0123"

option naa 0x37a81825124bbd86

}

}


auth-group ag4tg_3 {

initiator-portal "10.0.0.0/24"

auth-type "none"

}


target iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot04 {

alias iqn.2011-03.krakoliezene.istgt:sanboot04

auth-group ag4tg_3

portal-group pg1


lun 0 {

option unmap on

path /dev/zvol/pool1/sanboot04

blocksize 512

serial 7071bcdd3758020

device-id "iSCSI Disk 7071bcdd3758020 "

option vendor "FreeBSD"

option product "iSCSI Disk"

option revision "0123"

option naa 0x34336317210eb502

}

}


auth-group ag4tg_4 {

initiator-portal "10.0.0.0/24"

auth-type "none"

}


target iqn.2011-03.krakoliezene.istgt:iqn.2011-03.krakoliezene.istgt:sanboot05 {

alias iqn.2011-03.krakoliezene.istgt:sanboot05

auth-group ag4tg_4

portal-group pg1


lun 0 {

option unmap on

path /dev/zvol/pool1/sanboot05

blocksize 512

serial 7071bcdd3758030

device-id "iSCSI Disk 7071bcdd3758030 "

option vendor "FreeBSD"

option product "iSCSI Disk"

option revision "0123"

option naa 0x3232e24f5f4b9855

}

}

 

[krakoliezene]

Could it be the full targetname has twice the base name in it? The alias is the right one, but the targetname repeats one string. The output of devlist only shows the full name.

 

[jkh]

Hmmm. That looks like this: https://github.com/freenas/freenas/commit/26a6e28ec77484a2c7f47e23b2a1cead3ecb3f6d

If I'm not just smoking crack and that is indeed the fix to this problem, then it will be in the next 9.3-STABLE update. If you want to try hand-applying that diff (it's short - see the commit in question) then you can always edit your /usr/local/libexec/nas/generate_ctl_conf.py on your FreeNAS box directly and try starting/stopping iSCSI to test it (or, even easier, just jump to the 9.3-Nightlies train to test it and then jump back when the fix goes into 9.3-STABLE. With the boot environment support now, you can do that kind of thing safely and easily since it's also trivial to jump back or, in an extreme case, simply roll-back to the previous boot environment.

 

[krakoliezene]

Smoking crack is not advisable, jkh.

 

[krakoliezene]

Smoking crack is not advisable, jkh. I mean thanks a lot, sir!

 

[krakoliezene]

I applied the patch and restarted iSCSI, but there is no difference in the targetnames in ctl.conf or devlist. Even if I change the targetname in the GUI to the short one, it does not have any consequence for the targetname in ctl.conf. I could edit ctl.conf directly, but that is not the way we want it with this nice GUI is it?

 

[jkh]

Ok, well, it was worth a shot. Let's see what jpaetzel says when he wakes up!

 

[mav@]

I applied the patch and restarted iSCSI, but there is no difference in the targetnames in ctl.conf or devlist. Even if I change the targetname in the GUI to the short one, it does not have any consequence for the targetname in ctl.conf.

Both statements are odd, especially the second one. It sounds like config was not regenerated. How exactly you restarted iSCSI? Turned it OFF and back ON in service control menu?

It should not be necessary, but have you tried to reboot?

 

[jpaetzel]

After applying the patch do a service ix-ctld start then attach /etc/ctl.conf If ctl.conf isn't changing then there's some other problem and it will probably be easiest for me just to fix it live than to back and forth over the forums.

The root problem is the target names.

 

[krakoliezene]

I shifted to the nightlies train and the problem is solved. The target names show like they should, both with a short and a long targetname. I already saw that in the stable train the changelog mentions a typo in the ctl configurator.
My PXE-booting host is running again. Thank all of you for your help.
9.3 rocks!!