Hello:

That is not (and should not be) a problem for anyone taking the time to reply to as request for support here at Dev1.

ie: You do what you can, when you can and if you can.

My apologies if my text sounded like anything else.

Time is, indisputably, the most valuable thing anyone has.
And to dedicate a part of it, however small, to help someone is the right thing to do.

It is part of what I refer to as the 'pay it forward system'.
It goes around and (eventually) will come back to you.

Best,

A.

Hello:

You're welcome.

Quite so ...

No.
You just need some practise on how to get around the file system.
We have *all* been there at some point.

Don't worry, you'll ge there.  8^)

See here:
https://www.youtube.com/watch?v=qCMZcUKzzKw

You should also check out the other parts of the series.

Best,

A.

Hello:

Not the case.
Thanks anyhow.

Right ...
It's built in.
Should have remembered that. 8^°

In my case it would be:

$ grep ipv6.ko /lib/modules/6.1.0-33-amd64/modules.builtin
kernel/net/ipv6/ipv6.ko
$ 

Thanks for your input.

Best,

A.

Hello:

You're welcome.

That's the first thing to do before posting.
You don't know what you don't know till you look for it. 8^°

Actually it is tragic.

For years now, Bill Hewlett and David Packard (founders of the original HP) have been turning in their graves three times a minute.
To think what HP was and see the piece of crap that it has become ...
Uncanny.

Best,

A.

Hello:

You're welcome.

Yes, your post is.
What I meant to say was that it is not connected to the OP by @Fjalar.

That said, let's see if we can make some sense out of what seems to be going on.

etch is a Debian release from April 2007 and Devuan did not exist at that time.
Devuan Jesse was released May 2017, roughly ten years later.

$ uname -a tells us your system runs Devuan Daedalus.
apt list | grep -i installed | grep -i open-iscsi tells us the open-iscsi package installed is open-iscsi_2.1.8-1_amd64.

Yet for some reason, attempting to run the application gets you a classic systemd error in a system that by definition does not use the systemd package for init.

In an attempt to get to the bottom of the problem, I decided to see if I could reproduce the problem:

Installation

# apt install open-iscsi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libisns0 libopeniscsiusr
Recommended packages:
  finalrd
The following NEW packages will be installed:
  libisns0 libopeniscsiusr open-iscsi
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 464 kB of archives.
After this operation, 2152 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://deb.devuan.org/merged daedalus/main amd64 libisns0 amd64 0.101-0.2+b1 [92.0 kB]
Get:2 http://deb.devuan.org/merged daedalus/main amd64 libopeniscsiusr amd64 2.1.8-1 [59.7 kB]
Get:3 http://deb.devuan.org/merged daedalus/main amd64 open-iscsi amd64 2.1.8-1 [312 kB]
Fetched 464 kB in 2s (187 kB/s)    
Preconfiguring packages ...
Selecting previously unselected package libisns0:amd64.
(Reading database ... 188375 files and directories currently installed.)
Preparing to unpack .../libisns0_0.101-0.2+b1_amd64.deb ...
Unpacking libisns0:amd64 (0.101-0.2+b1) ...
Selecting previously unselected package libopeniscsiusr.
Preparing to unpack .../libopeniscsiusr_2.1.8-1_amd64.deb ...
Unpacking libopeniscsiusr (2.1.8-1) ...
Selecting previously unselected package open-iscsi.
Preparing to unpack .../open-iscsi_2.1.8-1_amd64.deb ...
Unpacking open-iscsi (2.1.8-1) ...
Setting up libopeniscsiusr (2.1.8-1) ...
Setting up libisns0:amd64 (0.101-0.2+b1) ...
Setting up open-iscsi (2.1.8-1) ...
Processing triggers for libc-bin (2.36-9+deb12u10) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for initramfs-tools (0.142+deb12u1) ...
update-initramfs: Generating /boot/initrd.img-6.1.0-33-amd64
live-boot: core filesystems dm-verity devices utils udev blockdev iscsi dns.
#

The package installed properly.

Attempt to run the application using your same parameters:

$ iscsiadm --mode discovery --type sendtargets --portal 192.168.178.100
sh: 1: /bin/systemctl: not found                                            # <---- same error
iscsiadm: can not connect to iSCSI daemon (111)!
iscsiadm: Could not make /etc/iscsi/send_targets: Permission denied         # <---- this neeeds root
iscsiadm: Could not add new discovery record.

Same error.

Try as root, again using your same parameters:

# iscsiadm --mode discovery --type sendtargets --portal 192.168.178.100
sh: 1: /bin/systemctl: not found                                            # <---- same error
iscsiadm: can not connect to iSCSI daemon (111)!
iscsiadm: Could not scan /sys/class/iscsi_transport.
sh: 1: /bin/systemctl: not found                                            # <---- same error
iscsiadm: can not connect to iSCSI daemon (111)!
iscsiadm: Cannot perform discovery. Initiatorname required.
iscsiadm: Could not perform SendTargets discovery: could not connect to iscsid
# 

Same error.

---

From what I see, it seems that this is a problem with the open-iscsi_2.1.8-1_amd64 package.
It requies a Devuan bug report to the maintainers.

See here on how to do that.

Note: Being a topic not related to the original post, please continue anything related to this issue on another, new thread. 

Best,

A.

Hello:

The printout points to a typical error in Linux systems using systemd.
Devuan is not one of them.

From the web:

systemd has been intentionally removed from Devuan, no failed update or accident to speak of there.  8^°

The installed open-iscsi application is looking for systemctl (part of the systemd package) but cannot find it, hence the error printout.

At the risk of stating the obvious, this should not happen* if the installed open-iscsi package is the one present in the Devuan repositories.

* unless there has been some error in the processing / sanitising for use in Devuan for which a bug report should be filed with the Devuan maintainers.

HTH.

Best,

A.

Hello:

Does not seem possible.

I have not found a way to disable any of those modules.
ie: ima, evm, selinux, etc. 

Whatever methods I found searching on-line did not work.

The main thing to disable would be LSM which seems to orchestrate all of them, including this latest Microsoft contribution to the Linux kernel.
But I have not been able to find a working method.

Right ...  8^°

Debian obviously does, no options to disable or heads-up given.
No surprise there ...

As a result, Devuan is stuck with all this crap.

Best,

A.

Hello:

Some fresh news with respect to LSM (Linux Security Modules).
Yes, those modules.
The ones you cannot disable or have any control over.

About eBPF

TL;DR

Absolutely wonderful !!!

Just what we were needing.
Linux kernel with Microsoft security module integration doing all of that.

Check the Phoronix note here.

Best,

A.

Hello:

Maybe I'm just as dumb as a (rusty) doornail, but after all these years (~12) with Linux I still fail to grasp the need for anything but one properly working init package for my systems* which have always worked wthout a hitch.
* desktop, netbook, RPi

Of course, as many others have, I came across more than one issue.
But none in any way related to the default init software, which was always* sysvinit. 
* save experiments with Debian/Debian based dists which I abandoned as systemd was adopted.

+1

Best,

A.

Hello:

I disabled apparmor from the first time I saw it has been installed and enabled without my intervention.
So no, I do not have the problem you have.

My way of dealing with it is adding security=none apparmor=0 nmi_watchdog=0 to my kernel command line.

That said, I am not too sure the stanza is quite as effective as I believe it is because early on, my dmesg printout also reveals this:

--- snip ---
[    3.066032] evm: Initialising EVM extended attributes:
[    3.066218] evm: security.selinux    # <-
[    3.066338] evm: security.SMACK64 (disabled)
[    3.066493] evm: security.SMACK64EXEC (disabled)
[    3.066660] evm: security.SMACK64TRANSMUTE (disabled)
[    3.066842] evm: security.SMACK64MMAP (disabled)
[    3.067009] evm: security.apparmor   # <- 
[    3.067132] evm: security.ima        # <-
[    3.067239] evm: security.capability # <-
[    3.067369] evm: HMAC attrs: 0x1
--- snip --- 

As you can see, evm* does not indicate apparmor (and other security features) as being disabled.
ie: adding security=none to the kernel command line should have disabled all that.

* https://linux-ima.sourceforge.net/linux … l-20110907

Edit:

At some point, someone posted a request to disable EVM and IMA.

I have tried (adding lsm=    to the kernel command line but it does not work, at least in the latest Daedalus 6.1.0-33-amd64:

$ grep -o "lsm=.*" /proc/cmdline
lsm=
$ 
$ ls /sys/kernel/security/
evm  ima  integrity  lockdown  lsm       # <- this should read "integrity  lsm"
$ 

Apparently it requires a patch. (?)

Best,

A.