open-iscsi installation failed on TX1/TX2 Jetpack3.0/3.1 -- ubuntu 16.04

open-iscsi installation succeed on ubuntu 16.04 x64, but failed on ubuntu 16.04 jetson arm64 platform.

Is this a opensource bug?

Log:

ubuntu@tegra-ubuntu:~/extsata/opencv_dev/v3.1.0$ sudo apt-get install open-iscsi


Unpacking open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.4) …
Processing triggers for initramfs-tools (0.122ubuntu8) …
Processing triggers for systemd (229-4ubuntu10) …
Processing triggers for man-db (2.7.5-1) …
Setting up open-iscsi (2.0.873+git0.3b4b4500-14ubuntu3.4) …

Job for iscsid.service failed because a configured resource limit was exceeded. See “systemctl status iscsid.service” and “journalctl -xe” for details.
invoke-rc.d: initscript iscsid, action “start” failed.
dpkg: error processing package open-iscsi (–configure):
subprocess installed post-installation script returned error exit status 1
Processing triggers for initramfs-tools (0.122ubuntu8) …
Errors were encountered while processing:
open-iscsi
E: Sub-process /usr/bin/dpkg returned an error code (1)

ubuntu@tegra-ubuntu:~/extsata/opencv_dev/v3.1.0$

From this message, what is the output of the “see” note?

See "systemctl status iscsid.service" and "journalctl -xe"


NETLINK_ISCSI socket create failed. What this depends on?

ubuntu@tegra-ubuntu:~$ systemctl status iscsid.service
● iscsid.service - iSCSI initiator daemon (iscsid)
Loaded: loaded (/lib/systemd/system/iscsid.service; enabled; vendor preset: enabled)
Active: failed (Result: resources) since Wed 2017-08-02 10:28:55 UTC; 14h ago
Docs: man:iscsid(8)
Process: 909 ExecStart=/sbin/iscsid (code=exited, status=0/SUCCESS)
Process: 902 ExecStartPre=/lib/open-iscsi/startup-checks.sh (code=exited, status=0/SUCCESS)

Aug 02 10:28:55 tegra-ubuntu systemd[1]: Starting iSCSI initiator daemon (iscsid)…
Aug 02 10:28:55 tegra-ubuntu iscsid[909]: iSCSI logger with pid=910 started!
Aug 02 10:28:55 tegra-ubuntu systemd[1]: iscsid.service: Failed to read PID from file /run/iscsid.pid: Invalid argumen
Aug 02 10:28:55 tegra-ubuntu systemd[1]: iscsid.service: Daemon never wrote its PID file. Failing.
Aug 02 10:28:55 tegra-ubuntu systemd[1]: Failed to start iSCSI initiator daemon (iscsid).
Aug 02 10:28:55 tegra-ubuntu systemd[1]: iscsid.service: Unit entered failed state.
Aug 02 10:28:55 tegra-ubuntu systemd[1]: iscsid.service: Failed with result ‘resources’.

ubuntu@tegra-ubuntu:~$ journalctl -xe
Aug 03 00:47:00 tegra-ubuntu systemd[1]: Started CUPS Scheduler.
– Subject: Unit cups.service has finished start-up
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit cups.service has finished starting up.

– The start-up result is done.
Aug 03 00:47:00 tegra-ubuntu systemd[1]: Starting iSCSI initiator daemon (iscsid)…
– Subject: Unit iscsid.service has begun start-up
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit iscsid.service has begun starting up.
Aug 03 00:47:00 tegra-ubuntu iscsid[2292]: iSCSI logger with pid=2293 started!
Aug 03 00:47:00 tegra-ubuntu systemd[1]: iscsid.service: Failed to read PID from file /run/iscsid.pid: Invalid argumen
Aug 03 00:47:00 tegra-ubuntu iscsid[2293]: iSCSI daemon with pid=2294 started!
Aug 03 00:47:00 tegra-ubuntu iscsid[2293]: can not create NETLINK_ISCSI socket
Aug 03 00:47:00 tegra-ubuntu systemd[1]: iscsid.service: Daemon never wrote its PID file. Failing.
Aug 03 00:47:00 tegra-ubuntu systemd[1]: Failed to start iSCSI initiator daemon (iscsid).
– Subject: Unit iscsid.service has failed
– Defined-By: systemd
– Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

– Unit iscsid.service has failed.

– The result is failed.
Aug 03 00:47:00 tegra-ubuntu systemd[1]: iscsid.service: Unit entered failed state.
Aug 03 00:47:00 tegra-ubuntu systemd[1]: iscsid.service: Failed with result ‘resources’.
Aug 03 00:47:04 tegra-ubuntu sudo[2165]: pam_unix(sudo:session): session closed for user root

Shall I rebild the kernel with some options…
?

It has been a long time since I set up iSCSI, and as I recall, even slight config errors caused failures. However, after installing the software, the service won’t be running. Typically it would be something like (I think it is named “iscsi.service”, but there may be related services, e.g., for serving iSCSI iscsid.service…the distinction being client versus daemon/server):

sudo systemctl start iscsi.service

So to start with, is the Jetson target (daemon serving the iSCSI) or initiator (mounting an iSCSI from another machine’s storage)? Also, I never went beyond a very basic password…it wasn’t too hard getting that working on Linux, Windows was a pain to set up correctly (and I don’t remember a lot about it, this was a one time thing a couple of years back). FYI, I found the performance was quite good, there are a number of fascinating possibilities for this on a Jetson (especially if a remote host target has lots of RAM for caching).

jetson is for initiator; target works well on my X86 PC, and wait jetson to connect.
Intiator need install open-iscsi first, that’s the problem I encountered.

I try “sudo systemctl start iscsi.service” or “sudo systemctl start iscsid.service”
No one work…
the same report as:
Job for iscsid.service failed because a configured resource limit was exceeded. See “systemctl status iscsid.service” and “journalctl -xe” for details.

The same open-iscsi version 2.0.873 initiator work normally on my annother Linux x64 machine.
Same linux release(ubuntu 16.04), only platform is different, ARM64 Vs X64.

I am not sure whether open-iscsi passed test under ARM64 and X64 with ubuntu 16.4 x64.

Note that installing open-iscsi causes an attempt to start iscsid.service, but if not configured, then the service cannot succeed. The Ubuntu server guide for iSCSI is here:
https://help.ubuntu.com/lts/serverguide/iscsi-initiator.html

Status of serving an iSCSI target is iscsid.service:

sudo systemctl status iscsi<b>d</b>.service

Status of service for requesting/mounting an iSCSI target (initiating from a client):

sudo systemctl status iscsi.service

Although open-iscsi installs both client and server software on Ubuntu, neither will be configured at the time of install, and on the Jetson end you won’t want iscsid.service, you will only want iscsi.service. The vendor preset is to enable (which is a bad default since a new install won’t have a configuration), but you probably want to avoid the iscsid.service error at each startup, so:

sudo systemctl disable iscsid.service
# Verify:
sudo systemctl status iscsid.service | egrep disabled

I do not currently have an iSCSI target set up, so I can’t test further configuration, but that should get you started. Realize that having iscsid.service fail is not an error…the real error is that the vendor preset default is to enable a service before it has been configured.

To manually start the initiator/user of iSCSI:

sudo systemctl start iscsi.service

To set automatic start of initiator/user of iSCSI:

sudo systemctl enable iscsi.service

To disable automatic start of initiator/user of iSCSI:

sudo systemctl disable iscsi.service

You may also find that because an iSCSI disk is treated just like a directly connected disk that automount is a bad idea unless you can guarantee the target is online and visible to the initiator at all times…network or other failure implies the same reaction as a failed disk being yanked from a non-hotplug drive slot. So even if you expect the drive to be used at all times, you do not want to add an fstab entry for automounting the drive until you have it manually working.

On a note of “cool things”, iSCSI makes an incredibly fast swap partition if desired.

The issue happened with command “sudo apt install open-iscsi”.
After installation failure, iSCSI Initiator Configuration:
node.startup = manually (to automatic) will not make this work.
so any following command “iscsiadm”, “iscsi_discovery”… all failed.

even disable iscsi daemon service, iscsi initiator still cannot work.

Btw, iscsi target — initiator work well on my home IPSAN network(ubuntu 16.04 intel x86 ).
Not found installation failure with installing open-iscsi, of course I use “iscsiadm” do configuration as initiator.

The point is that the failure is not a package install failure. It is just a configuration failure, the package is there. Setting to manual is just until you get it to work…after setting up configuration, then “sudo systemctl start iscsi.service”. You will have to research configuring the iSCSI before starting the service will work. iSCSI has many security options…it will not be easy to get configuration right, though if you have a way to monitor logs on the target to see what it thinks of incoming connections it will be easier.

issuse resolved with kernel missed iscsi initiator configuration.