Dear Maintainer,

When /sbin/init is sysvinit-core, apt-get install open-iscsi does not finish as
follows. The postinst script is terminated from another tty.

Script started on 2021-03-01 08:42:11+09:00 [TERM="linux" TTY="/dev/tty1" COLUMNS="128" LINES="48"]
root@host:~# apt-get install open-iscsi
The following additional packages will be installed:
  libisns0 libopeniscsiusr netbase
The following NEW packages will be installed:
  libisns0 libopeniscsiusr netbase open-iscsi
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 504 kB of archives.
After this operation, 2,211 kB of additional disk space will be used.
Preparing to unpack .../libisns0_0.100-3_amd64.deb ...
Unpacking libisns0:amd64 (0.100-3) ...
Selecting previously unselected package libopeniscsiusr.
Preparing to unpack .../libopeniscsiusr_2.1.3-2_amd64.deb ...
Unpacking libopeniscsiusr (2.1.3-2) ...
Selecting previously unselected package open-iscsi.
Preparing to unpack .../open-iscsi_2.1.3-2_amd64.deb ...
Unpacking open-iscsi (2.1.3-2) ...
Selecting previously unselected package netbase.
Preparing to unpack .../archives/netbase_6.2_all.deb ...
Unpacking netbase (6.2) ...
Setting up libopeniscsiusr (2.1.3-2) ...
Setting up libisns0:amd64 (0.100-3) ...
Setting up netbase (6.2) ...
Setting up open-iscsi (2.1.3-2) ...
Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets:
iscsiadm: No records found
.
Starting iSCSI initiator daemon: iscsidSetting up iSCSI targets:
iscsiadm: No records found
.

dpkg: error processing package open-iscsi (--configure):
 installed open-iscsi package post-installation script subprocess was killed by signal (Terminated)
Processing triggers for libc-bin (2.31-9) ...
Processing triggers for initramfs-tools (0.139) ...
update-initramfs: Generating /boot/initrd.img-5.10.0-3-amd64
Errors were encountered while processing:
 open-iscsi
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish
root@host:~# exit

Script done on 2021-03-01 08:43:48+09:00 [COMMAND_EXIT_CODE="100"]

Best regards, Ryutaroh Matsumoto

Dear Ryutaroh,

I see nothing wrong here. What is the output you expect ?

iscsiadm is reporting correct that the iscisi database has no record of
any iscsi target. So the daemon has run successful but there's no
target to connect to.

Hi Ritesh,

Thanks again for paying attention to my report.

On the qemu default configuration by virt-manager in Bullseye,
"apt-get install open-iscsi" finishes with no problem when /sbin/init==systemd-sysv,
while "apt-get install open-iscsi" never finishes when /sbin/init==systemd-sysv.

Is it expected? If this is an expected behavior, I am happy to attach "wontfix" tag
and/or close this issue.

The reason behind reporting this different behavior of "apt-get install open-iscsi"
is that it let autopkgtest of src:tgt always fail on the qemu testbed
when /sbin/init==systemd-sysv.

Best regards, Ryutaroh

I guess you meant sysvinit in the latter case.

The installation of the open-iscsi package shouldn't have any
difference in regard to the init system.

While I don't test with sysvinit any more, I don't recollect dropping
support for it. So if there's any specific issue, we could try to
resolve it.

I really don't know the behavior yet. The autopkgtest thing is not
something I'm versed with but nevertheless if there's a problem with
the actual package, it'd be nice to fix it.

So can you please point me to what the actual problem with the package
is, when run on a system with sysvinit-core being active ?

I was wrong... The latter should have been sysvinit-core...

apt-get install open-iscsi never finishes and,
I have to kill -TERM the post installation script from another tty.
Since I only run open-iscsi on a VM,
I am unsure if the open-iscsi with terminated installation works without any problem,
but at least apt/dpkg does not recognized open-iscsi as "fully installed".

If you don't reproduce the reported symptom on your Debian host,
I will upload the VM image file (300 MB qcow2) somewhere.

Best regards, Ryutaroh

No. No need to upload the VM image. Instead please just help me with
the debci/autopkgtest setup. It'll help me in the longer run.

What should be the steps to reproduce this bug on my machine using
debci/autopkgtest ?

(Assuming you are using Debian Bullseye amd64.)

# debci setup -f -b qemu -a amd64 -s sid
The above will create /var/lib/debci/qemu/sid-amd64.img
"debci setup" sometimes fails, in such a case please retry...

The above image has /sbin/init==systemd-sysv, of course.
As open-iscsi has no problem with /sbin/init==systemd-sysv,
We need to replace it with sysvinit-core in the VM image.

# apt-get --install-recommends install virt-manager
# cp /var/lib/debci/qemu/sid-amd64.img /var/lib/libvirt/images
# virt-manager (this can be run by an ordinary user belonging to libvirt group)

Start VM on /var/lib/libvirt/images/sid-amd64.img
Login as root (no password) into the Linux running on VM.
on-VM# apt-get install sysvinit-core
on-VM# echo "S0:2345:respawn:/sbin/getty -L ttyS0 115200 vt100" >>/etc/inittab
on-VM# shutdown -h -P now

/var/lib/libvirt/images/sid-amd64.img should have /sbin/init==sysvinit-core now.

autopkgtest -B -u debci -o some-dir-for-logging open-iscsi -- qemu --debug --show-boot /var/lib/libvirt/images/sid-amd64.img
The test should get stuck at apt-get install open-iscsi...

Best regards, Ryutaroh

Control: tag -1 +confirmed
Control: tag -1 +help


I figured it out what the problem is. I'm fairly confident that the
problem lies in the deb-systemd-helper tools that generates the
following script (full generated script attached)

```
# Automatically added by dh_systemd_enable/13.3.3

if [ "$1" = "configure" ] || [ "$1" = "abort-
upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-
remove" ] ; then

        # This will only remove masks created by d-s-
h on package removal.

        deb-systemd-helper unmask 'open-
iscsi.service' >/dev/null || true



        # was-
enabled defaults to true, so new installations run enable.

        if deb-systemd-helper --quiet was-enabled 'open-
iscsi.service'; then

                # Enables the unit on first installation, creates new

                # symlinks on upgrades if the unit file has changed.

                deb-systemd-helper enable 'open-
iscsi.service' >/dev/null || true

        else

                # Update the statefile to add new symlinks (if any), wh
ich need to be

                # cleaned up on purge. Also remove old symlinks.

                deb-systemd-helper update-state 'open-
iscsi.service' >/dev/null || true

        fi

fi

# End automatically added section

```


Please check my screenshot where the invocation of this tool is overridden and the overall installation completes immediately.

Now, dh-systemd-helper tool written in perl, is not something I want to debug further. Because neither am I well versed with perl nor systemd. SO any help there is welcome. Bug has been tagged appropriately.

@Ryutaroh: Thank you for finding and reporting the bug and having the patience with me. Working on this bug, with you, made me learn a couple of new things. :-)

Thank you very much for spending your time on investigating this issue.
I wonder if this issue should also be assigned to init-system-helpers package
including deb-systemd-helper, for example, by the following commands

 clone 983737 -1
 reassign -1 init-system-helpers  1.60

Your analysis of this issue seems indicating this is also an issue in init-system-helpers,
though I am unsure. As init-system-helpers is one of very few "essential" packages,
its bug must be identified and fixed before the release of Bullseye, if any.

You are most welcome!

Best regards, Ryutaroh

I guess so. Rather than clone you could just reassign this bug to init-
system-helpers and see what the maintainers have to say about my
findings.

Thanks,
Ritesh

Am 05.03.21 um 07:54 schrieb Ritesh Raj Sarraf:

I don't see a proper explanation which would justify a reassign to
init-system-helpers.

Please dig a bit deeper before reassigingin.

Thanks.

That looks like the same issue as #589487 and others.

Either make sure the sysvinit script cleans up the environment to make
it is safe to be run, have the daemon do so to be safe to be started
via sysvinit scripts, or add a workaround to the postinst script (fixes
this particular problem, but not if the sysvinit script gets called in
some other environment).

Ansgar

* Ritesh Raj Sarraf <rrs@debian.org>:

TBF, if there's not going to be regular testing with sysvinit, maybe
the support code for it should go away...?

Chris

Yes. If it becomes release critical.

OTOH, The shell script having issues shouldn't really be of major
concern. Because most majority of users have switched to systemd based
setups. Also our GR resolution encourages to provide best possible
support for both scenarios.

My wishful thought has always been that there will be other users in
Debian (and derivatives), who'd still have an interest in it
(sysvinit), and will report back issues and fixes too.

I see Ryutaroh bug report with that in mind only.


As for this bug report, the issue isn't really directly with open-
iscsi. Or at least, not to my knowledge. Only the invocation of a
systemd helper utility causes problems.