Bugzilla – Bug 1226388
Yast2 iSCSI LIO server reports internal error after targetcli exits with status 255
Last modified: 2024-07-01 15:54:35 UTC
Created attachment 875503 [details] yast2 log Tumbleweed fresh install from 20240613 image Try to get to commandline yast / Network Services / iscsi LIO target and immediately get internal error: Caller: /usr/lib64/ruby/gems/3.3.0/gems/cheetah-1.0.0/lib/cheetah.rb:675:in `report_errors' Details: Execution of "/usr/bin/targetcli iscsi/\ get\discovery_auth\ enable\ userid\ password\ mutual_userid\mutual_password" failed with status 255 (no error output). Log attached # systemctl enable --now targetcli Created symlink /etc/systemd/system/remote-fs.target.wants/targetcli.service → /usr/lib/systemd/system/targetcli.service. # systemctl status targetcli ● targetcli.service - "Generic Target-Mode Service (fb)" Loaded: loaded (/usr/lib/systemd/system/targetcli.service; enabled; preset: disabled) Active: active (exited) since Sat 2024-06-15 07:32:11 MDT; 2s ago Process: 27819 ExecStart=/usr/bin/targetcli restoreconfig $CONFIG_FILE (code=exited, status=255/EXCEPTION) Main PID: 27819 (code=exited, status=255/EXCEPTION) CPU: 125ms Jun 15 07:32:11 dellap-e6540-suse systemd[1]: Starting "Generic Target-Mode Service (fb)"... Jun 15 07:32:11 dellap-e6540-suse targetcli[27819]: name 'glob' is not defined Jun 15 07:32:11 dellap-e6540-suse systemd[1]: Finished "Generic Target-Mode Service (fb)". Have even tried working around this with webmin and iscsi is unusable, log attached As iscsi server is the primary purpose of this instance, we are effectively dead in the water
Since obviously one of those many external commands that this YaST module calls failed, the problem lies probably with that command, not necessarily with YaST. >> 07:32:22 <3> [Ruby] yast/wfm.rb(handle_exception):271 >> Client /usr/share/YaST2/clients/iscsi-lio-server.rb >> failed with 'Execution of >> >> /usr/bin/targetcli iscsi get discovery_auth enable userid password mutual_userid mutual_password >> >> failed with status 255 (no error output).' >> (Cheetah::ExecutionFailed). This might be the result of some misconfiguration earlier since (AFAICS) the YaST code in that area hasn't changed at all for a very long time. Or it might also be yet another case of those underlying tools changing their behavior and nobody bothering to tell us about it.
I can 100% reproduce this problem on the latest TW with all updates. But it's not just that YaST module, it's the 'targetcli' command in general: >> balrog-tw-dev:~ # rpm -qa "*targetcli*" >> >> python311-targetcli-fb-2.1.57-2.3.noarch >> targetcli-fb-common-2.1.57-2.3.noarch >> >> balrog-tw-dev:~ # targetcli >> >> name 'glob' is not defined >> >> balrog-tw-dev:~ # echo $? >> >> 255 >> >> balrog-tw-dev:~ # whoami >> >> root >> balrog-tw-dev:~ # cat /etc/os-release >> >> NAME="openSUSE Tumbleweed" >> # VERSION="20240613" >> ID="opensuse-tumbleweed" >> ID_LIKE="opensuse suse" >> VERSION_ID="20240613" >> PRETTY_NAME="openSUSE Tumbleweed" >> ANSI_COLOR="0;32" >> # CPE 2.3 format, boo#1217921 >> CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20240613:*:*:*:*:*:*:*" >> #CPE 2.2 format >> #CPE_NAME="cpe:/o:opensuse:tumbleweed:20240613" >> BUG_REPORT_URL="https://bugzilla.opensuse.org" >> SUPPORT_URL="https://bugs.opensuse.org" >> HOME_URL="https://www.opensuse.org" >> DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed" >> LOGO="distributor-logo-Tumbleweed" And despite my default python is still 2.7, it should work because /usr/bin/targetcli is a symlink to /etc/alternatives/targetcli which in turn is a symlink to /usr/bin/targetcli-3.11, which has a correct shell she-bang #!/usr/bin/python3.11 which is installed and works fine.
Reassigning to the targetcli maintainers: % osc maintainer -e python311-targetcli-fb Defined in package: Base:System/targetcli-fb bugowner of python311-targetcli-fb : lduncan@suse.com maintainer of python311-targetcli-fb : hare@suse.com, lduncan@suse.com, kernel-storage-team@suse.de
The last change to this package was 8 months ago: https://build.opensuse.org/package/show/openSUSE:Factory/targetcli-fb Change log: https://build.opensuse.org/projects/openSUSE:Factory/packages/targetcli-fb/files/targetcli-fb.changes?expand=1 Can this really be broken since 8 months? Or did something else change on the system in the meantime, e.g. Python 3.11 which now complains about "glob"?
I just updated my tumbleweed from 20240610-0 to 20240613-0. Targetcli was working fine for 20240610-0. I believe the problem is the rtslib package, i.e. python311-rtslib-fb. After the upgrade, I get the same error you are showing. I will try removing the last patch added to rtslib (which was done without consulting me), and see if that fixes it. Adding the author of said patch to the cc list.
Yes, reverting that patch seems to fix the problem. I'll submit the reversion.
Revert has been submitted. See OBS request 1181351. You can get a copy of the fixed rtslib package at devel:languages:python/python-rtslib-fb
Hi all, the patch to python-rtslib-fb was meant just to drop the remnants of Python 2, which is EOL for quite some time. This package, as almost the whole Factory, is built only with various versions of Python 3. The compatibility package between Python 2 and Python 3, python-six, might not support the next Python 3 release (though I can't find any announcement stating that right now, I need to recheck) and should therefore be dropped from as many pkgs as possible before the release. But it is not pressing yet. Those were my reasons for submitting that patch and I am really sorry for all the inconvenience it caused. The revert looks fine to me, except you might need to Require and BuildRequire python-six again in the future, now it is probably pulled in by some other dependencies.
(In reply to Markéta Machová from comment #8) > Hi all, the patch to python-rtslib-fb was meant just to drop the remnants of > Python 2, which is EOL for quite some time. This package, as almost the > whole Factory, is built only with various versions of Python 3. The > compatibility package between Python 2 and Python 3, python-six, might not > support the next Python 3 release (though I can't find any announcement > stating that right now, I need to recheck) and should therefore be dropped > from as many pkgs as possible before the release. But it is not pressing yet. > > Those were my reasons for submitting that patch and I am really sorry for > all the inconvenience it caused. The revert looks fine to me, except you > might need to Require and BuildRequire python-six again in the future, now > it is probably pulled in by some other dependencies. No worries. I would like to address the python3-ness by updating all 3 packages needed for targetcli, i.e. targetcli itself, configshell, and rtslib. They really need to be tested/verified together. I usually update all 3 of them regularly (about once a year?). Please file a bug on all 3 of them needed to be updated, and assign it to me?
I believe this is fixed now. Any objections to closing it?
Is this supposed to be fixed in Leap 15.5? I just installed the latest updated in an LXC container and still getting the same error
Can confirm this bug appears to be fixed in latest Tumbleweed updates, thanks :)
*** Bug 1226333 has been marked as a duplicate of this bug. ***
Marking this as resolved in Tumbleweed.