Red Hat Bugzilla – Bug 457510
iscsiadm reports error when trying to remove target records during sendtargets discvoery processing
Last modified: 2012-06-27 05:28:43 EDT
+++ This bug was initially created as a clone of Bug #430810 +++
Description of problem:
If I remove a target on the isns sever, then rerun discovery with iscsiadm the
record for the target that was removed is not deleted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Record for deleted target should be removed.
-- Additional comment from firstname.lastname@example.org on 2008-07-30 09:45 EST --
Excerpt from strace of iscsiadm:
= -1 EISDIR (Is a directory)
write(2, "iscsiadm: ", 10) = 10
write(2, "Could not remove link /var/lib/i"..., 147) = 147
Note, this particular iscsi target was one that was scanned at install time by
anaconda, ones scanned via iscsiadm command later appear to be symlinks in the
same directory (as iscsiadm appears to expect).
-- Additional comment from email@example.com on 2008-07-31 12:46 EST --
I am not sure what you are reporting on here. This bugzilla was just for isns
discovery, because the removal feature was not implemented.
Are you having trouble with just targets/portals found with send targets
discovery? What is the exact problem? As far as symlink vs dir goes, it should
be ok, because iscsiadm supports both layouts. Is iscsiadm failing and logging
something about this?
You can also run iscsiadm ..... -d 8 to get lots of debug info.
Let me know what is wrong, and run iscsiadm with -d 8 and I can help more.
-- Additional comment from firstname.lastname@example.org on 2008-07-31 13:40 EST --
The original notes on the bug report talk about rerunning discovery with
iscsiadm, and a target that was removed not being deleted. Looked to be the
exact same issue that was happening for me, thus the additional information was
related, and may help to nail down where the bug actually is.
# iscsiadm -m discovery -t st -p 10.4.10.55:3260
iscsiadm: Could not remove link
iscsiadm: Could not delete node
-- Additional comment from email@example.com on 2008-08-01 05:05 EST --
(In reply to comment #3)
> The original notes on the bug report talk about rerunning discovery with
> iscsiadm, and a target that was removed not being deleted. Looked to be the
> exact same issue that was happening for me, thus the additional information was
> related, and may help to nail down where the bug actually is.
Ah I see, it was my fault. I did not describe the problem right in the original
bugzilla comment. This bugzilla is just for isns discvoery not removing targets
correctly. For isns, we did not implement this feature at all, so if the isns
server told us about targetA and targetB, then only tells us about TargetA, the
initiator's isns discovery code just leaves targetB on purpose.
For what you hit below it looks like a bug in the sendtargets code where we did
try to handle the case where sendtargets returns different targets.
Let me make a new bugzilla for your issue.
> # iscsiadm -m discovery -t st -p 10.4.10.55:3260
> iscsiadm: Could not remove link
> err 21
> iscsiadm: Could not delete node
Could you tell me what version of iscsi-initiator-utils you are using, and what
version of RHEL5?
And is the portal at 10.0.30.7,3260 on the target
iqn.2003-10.com.lefthandnetworks:lhsan:28:www-root, no longer being returned by
sendtargets? Some versions of iscsiadm, will try to upgrade older formats to
Could you also run iscsiadm with -d 8 and send the output.
I tied replicating this here, by first making records with the old tools that
did not use links. Then I used the current tool,
iscsi-initiator-utils-126.96.36.1998-0.7, to do discovery to the same discvoery
address, and it worked ok. I also tried removing targets and doing discvoery
with the new tools but using the old nonlink layout and that worked ok.
Created attachment 313764 [details]
iscsiadm -d8 output
Slightly censored to protect information about who's network this is, and the network layout. Changed IP addresses / hostnames / iscsi target names.
Box was installed as 5.1 and was upgraded to 5.2 (it's is a CentOS install, for which RH is upstream, so in theory, a bug in one should be in both)
iscsi-initiator-utils-188.8.131.528-0.7.el5 is installed.
The target's in question that it is generating an error attempting to delete, where target that it scanned during install time (by anaconda), so what ever version of iscsi-initiator-utils is included in the 5.1 installer.
I do know how to fix the issue manually (by deleting the directory manually), and I did do this on one of the other servers, but, I would like to contribute when possible.
(In reply to comment #4)
> Box was installed as 5.1 and was upgraded to 5.2 (it's is a CentOS install, for
> which RH is upstream, so in theory, a bug in one should be in both)
Yeah, it should be in both.
Let me try this here with anaconda installing it the initial db and using those versions. Thanks for the info.
I am adding this on the todo for the next RHEL version.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
This did not make 5.3, due to a lack of resources. Proposing for 5.4.
Moving to 5.5.