Source: insserv
Version: 1.26.0-1
Severity: wishlist
X-Debbugs-Cc: debian-hurd@lists.debian.org
User: debian-hurd@lists.debian.org
Usertags: hurd-amd64 hurd-i386

Hi,

my goal is to easily create chroots for Debian GNU/Hurd on systems running the
default Debian init system: systemd. Since Hurd binaries cannot be executed on
Linux, dpkg --force-script-chrootless is used and this requires insserv to be
installed outside of the chroot. This is not possible if the system on the
outside has systemd installed because that conflicts with insserv and according
to Michael Biebl this is not going to change. A possible way forward would be
if another binary package could be produced by src:insserv which just ships the
insserv binary in a location that is not in $PATH.

I opened https://salsa.debian.org/debian/insserv/-/merge_requests/2 with a
possible way forward. From the MR description:

The systemd-sysv package conflicts with insserv (see #1072562 for details) and
in #debian-devel Michael Biebl confirmed that this is not likely going to
change. But systemd does not work on non-Linux systems like GNU/Hurd, so when
creating chroots for these systems, sysvinit is usually used instead. Since
Hurd binaries cannot be executed on Linux, the chroot is created using dpkg
--force-script-chrootless which executes maintainer scripts without chroot
isolation and uses the $DPKG_ROOT environment variable to communicate the
location of the chroot directory. To install packages shipping sysvinit scripts
(like openssh-server) the insserv utility has to be run but due to systemd-sysv
conflicting with insserv, the system on the outside must not have systemd-sysv
installed. This means that to create a Hurd chroot, another chroot layer around
it is needed. It would be convenient if that additional layer could be avoided
when creating chroots for GNU/Hurd and other operating systems which use
insserv on systems which boot with systemd.

Michael Biebl suggested that one possible way forward would be to add a
insserv-bin package which ships a copy of /usr/sbin/insserv but places it
outside of $PATH as /usr/libexec/insserv. The systemd-sysv would then not need
to Conflict with that package.

To keep this change minimally invasive, the insserv-bin ships a copy of the
insserv binary which is also shipped in the insserv package. In fact, this
patch does not change the insserv binary package at all (it remains bit-by-bit
identical to how it looked like before this change).

Alternatively, the insserv binary package could be changed to gain a Depends on
insserv-bin and ship a symlink from /usr/sbin/insserv to /usr/libexec/insserv.

What do you think?

Thanks!

cheers, josch

From 7de38d8d9cb8985fc300668fe64a6d0568ee1791 Mon Sep 17 00:00:00 2001
From: Johannes Schauer Marin Rodrigues <josch@debian.org>
Date: Fri, 13 Mar 2026 18:18:40 +0100
Subject: [PATCH] Add insserv-bin binary package with /usr/libexec/insserv

The systemd-sysv package conflicts with insserv (see #1072562 for
details) and in #debian-devel Michael Biebl confirmed that this is not
likely going to change. But systemd does not work on non-Linux systems
like GNU/Hurd, so when creating chroots for these systems, sysvinit is
usually used instead. Since Hurd binaries cannot be executed on Linux,
the chroot is created using dpkg --force-script-chrootless which
executes maintainer scripts without chroot isolation and uses the
$DPKG_ROOT environment variable to communicate the location of the
chroot directory. To install packages shipping sysvinit scripts (like
openssh-server) the insserv utility has to be run but due to
systemd-sysv conflicting with insserv, the system on the outside must
*not* have systemd-sysv installed. This means that to create a Hurd
chroot, another chroot layer around it is needed. It would be convenient
if that additional layer could be avoided when creating chroots for
GNU/Hurd and other operating systems which use insserv on systems which
boot with systemd.

Michael Biebl suggested that one possible way forward would be to add a
insserv-bin package which ships a copy of /usr/sbin/insserv but places
it outside of $PATH as /usr/libexec/insserv. The systemd-sysv would then
not need to Conflict with that package.

To keep this change minimally invasive, the insserv-bin ships a copy of
the insserv binary which is also shipped in the insserv package. In
fact, this patch does not change the insserv binary package at all (it
remains bit-by-bit identical to how it looked like before this change).

Alternatively, the insserv binary package could be changed to gain a
Depends on insserv-bin and ship a symlink from /usr/sbin/insserv to
/usr/libexec/insserv.
---
 debian/control                        | 18 ++++++++++++++++++
 debian/insserv-bin.install            |  1 +
 debian/{dirs => insserv.dirs}         |  0
 debian/{docs => insserv.docs}         |  0
 debian/{install => insserv.install}   |  3 +++
 debian/{postinst => insserv.postinst} |  0
 debian/{postrm => insserv.postrm}     |  0
 7 files changed, 22 insertions(+)
 create mode 100644 debian/insserv-bin.install
 rename debian/{dirs => insserv.dirs} (100%)
 rename debian/{docs => insserv.docs} (100%)
 rename debian/{install => insserv.install} (73%)
 rename debian/{postinst => insserv.postinst} (100%)
 rename debian/{postrm => insserv.postrm} (100%)

diff --git a/debian/control b/debian/control
index 93b011f..38c2ffe 100644
--- a/debian/control
+++ b/debian/control
@@ -30,3 +30,21 @@ Description: boot sequence organizer using LSB init.d script dependency informat
  detecting and rejecting dependency loops.
  .
  Using insserv incorrectly can result in an unbootable system.
+
+Package: insserv-bin
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
+Description: boot sequence organizer using LSB init.d script dependency information (binary only)
+ The insserv program is used by the standard SysV-based init system. It
+ updates the order of symlinks in /etc/rc?.d/ based on dependencies
+ specified by LSB headers in the init.d scripts themselves.
+ .
+ These declared relations between scripts make it possible to optimize
+ the boot sequence for the currently installed set of packages, while
+ detecting and rejecting dependency loops.
+ .
+ This package ships the insserv binary from the insserv package but it places
+ the executable into /usr/libexec/insserv so that it does not appear in the
+ system's $PATH and can safely be installed alongside systemd-sysv.
diff --git a/debian/insserv-bin.install b/debian/insserv-bin.install
new file mode 100644
index 0000000..5edb2f8
--- /dev/null
+++ b/debian/insserv-bin.install
@@ -0,0 +1 @@
+usr/sbin/insserv /usr/libexec
diff --git a/debian/dirs b/debian/insserv.dirs
similarity index 100%
rename from debian/dirs
rename to debian/insserv.dirs
diff --git a/debian/docs b/debian/insserv.docs
similarity index 100%
rename from debian/docs
rename to debian/insserv.docs
diff --git a/debian/install b/debian/insserv.install
similarity index 73%
rename from debian/install
rename to debian/insserv.install
index c46ba93..9ebab33 100644
--- a/debian/install
+++ b/debian/insserv.install
@@ -2,3 +2,6 @@ debian/check-archive-initd-scripts usr/share/insserv
 debian/check-initd-order usr/share/insserv
 debian/make-testsuite usr/share/insserv
 debian/seq-changes usr/share/insserv
+usr/sbin/insserv
+etc/insserv.conf
+usr/share/man/man8/insserv.8
diff --git a/debian/postinst b/debian/insserv.postinst
similarity index 100%
rename from debian/postinst
rename to debian/insserv.postinst
diff --git a/debian/postrm b/debian/insserv.postrm
similarity index 100%
rename from debian/postrm
rename to debian/insserv.postrm

Johannes,

Thanks for this.

Great!

My preference is that the systemd conflicts with insserv should be removed. You
have a reasonable usage case for coinstalling insserv with systemd.  The
conflicts also causes autopkgest failures on ci.d.o for startpar, openrc and
insserv itself as systemd cannot be uninstalled from the autopkgtest testbed.

The conflicts was added to avoid interactions between systemd, initscripts and
insserv, however support for LSB initscripts in systemd has now been removed and
I find it unlikely that #1072562 or similar would still be issue even if
initscripts and insserv were installed on a systemd system. If I am wrong in my
analysis here, I would be happy to be pointed to a reproducer for such an issue.

With best wishes

Mark

Hi Mark,

Quoting Mark Hindley (2026-03-27 20:49:05)

do you want to bring this up with systemd maintainers? I'm not sure whether I
have enough energy right now to challenge the strong position on that topic
which I felt Michael Biebl seems to have when we talked in #debian-devel about
that topic.

Thanks!

cheers, josch

Hi Mark,

Quoting Mark Hindley (2026-03-27 20:49:05)

I asked Michael Biebl in #debian-devel again about this and the remaining
problem seems to be that most packages still ship sysv init scripts alongside
the systemd service files and that means that maintainer script code is
generated which calls update-rc.d/innserv if present.

I suggested to change the debhelper snippet which generates the relevant bit in
maintainer scripts but Michael Biebl wasn't happy with that approach either.

Jochen Sprickerhof brought up that update-rc.d/insserv could behave differently
if DPKG_ROOT is set, but Michael Biebl replied that he has "no interest in
touching this code and investigating all the corner cases".

Remember, that this is just a convenience feature. I can use the $DPKG_ROOT
method just fine from a clean chroot without systemd installed. I want to
explore whether maybe this requirement can be dropped but I don't think too
much energy and/or friction should be spent on that. I thought that just adding
another small binary package would be the path of least resistance.

Thanks!

cheers, josch

Hi Mark,

without the systemd maintainers willing to change things I fear that nothing
will move. I'd argue that it would be a great boon for ports which cannot have
systemd if it were easier to create chroots or bootable images for them from
the more common installations which are using systemd. And right now I see no
other way forward than adding another binary package which ships insserv
at a location that is not in $PATH. Maybe you have another idea?

Thanks!

cheers, josch

Apr 13, 2026 08:57:26 Johannes Schauer Marin Rodrigues <josch@debian.org>:
Hi,

I have a somewhat tangential idea which I believe might help here. I am in contact with openRC upstream and for 0.64 they are planning to support native openRC init scripts started from /etc/rc. While /etc/init.d is already supported this uses "legacy" sysvinit ones and is dependent on insserv to get the service ordering correct. Currently, this is a hard dependency. However, it is smart enought to do its own ordering with native openRC scripts. Time permitting I'd like to explore this anyway to make openRC support in Debian more mainstreamed.

best,

werdahias

PS: Sorry about brevity / formatting, sent from mobile

Josch,

Thanks for the nudge. I fully support your aims.

I had a quick look at this. I can't find any maintscript snippets that change
behaviour by testing for the presence/absence of /sbin/insserv. The only place
that I can find something similar is update-rc.d from src:init-system-helpers.

Whilst I respect Michael's extensive experience and everybody is entitled to
have an opinion, the systemd maintainers cannot be the gatekeepers of what is
acceptable.

For the autopkgtest breakage that I have already identified, I would still
prefer a solution that enabled the systemd Conflicts insserv to be removed. Are
you able to look at update-rc.d and see how its behaviour could be improved?

Thanks

Mark

Hi,

Quoting Mark Hindley (2026-04-14 08:31:39)

yes, I made the same observation.

In #debian-devel Michael Biebl only brought up update-rc.d as the problematic
point (maybe there is more). In that case, I had assumed that the fix would
simply be to tell update-rc.d to ignore the presence of /sbin/insserv and
/etc/insserv.conf in case the current system is using systemd. In that case, I
had imagined that the fix is as simple as doing:

--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -192,6 +192,10 @@ sub create_sequence {
     $insserv = "/sbin/insserv" if ( -x "$dpkg_root/sbin/insserv");
     # If insserv is not configured it is not fully installed
     my $insserv_installed = -x "$dpkg_root$insserv" && -e "$dpkg_root/etc/insserv.conf";
+    # Ignore the presence of insserv if this system is using systemd
+    if ($insserv_installed && -d "$dpkg_root/run/systemd/system") {
+        $insserv_installed = 0;
+    }
     my @opts;
     push(@opts, '-f') if $force;
     # Add force flag if initscripts is not installed

But I'm not an expert in this matter and I also do not have any motivation to
argue with the systemd maintainers about this. If you have the energy for that
then I can support you with doing the work when things need to be
patched/fixed. In that case, how else can I help you? If you agree that above
is likely correct, then I can build init-system-helpers with this patch and see
if it indeed has the intended effect or not. I suppose to try this out I would
have to install some packages which ship sysv scripts? Do you have a suggestion
for a small/simple package which would be a good candidate?

Thanks!

cheers, josch

Johannes Schauer Marin Rodrigues writes ("Bug#1132024: Add insserv-bin binary package with /usr/libexec/insserv for easily creating Hurd chroots"):

Hi.  (I've just been lurking in this thread.)

I think my package "userv" may be a good candidate.  It has both an
init script and a systemd unit.  It has some autopkgtests if those are
helpful.

Ian.

Hi,

Quoting Ian Jackson (2026-04-14 12:30:11)

thank you for chiming in. :)

I changed my patch to this:

--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -192,6 +192,10 @@ sub create_sequence {
     $insserv = "/sbin/insserv" if ( -x "$dpkg_root/sbin/insserv");
     # If insserv is not configured it is not fully installed
     my $insserv_installed = -x "$dpkg_root$insserv" && -e "$dpkg_root/etc/insserv.conf";
+    # Ignore the presence of insserv if this system is using systemd as init
+    if ($insserv_installed && readlink "$dpkg_root/usr/sbin/init" eq "../lib/systemd/systemd") {
+        $insserv_installed = 0;
+    }
     my @opts;
     push(@opts, '-f') if $force;
     # Add force flag if initscripts is not installed

I don't think it would be correct to check /run/systemd/system as I proposed
earlier because that would allow us to find out whether systemd is the init
system currently running but we want to find out which init system the system
is going to use. The distinction is important because we want equal behaviour
when working inside a chroot (no systemd running) and also with $DPKG_ROOT
(without a chroot). Maybe there is a better check. I'm open for ideas.

I've changed src:insserv to create the binary package insserv-cheat which is
identical to insserv except the name. This is so that I can install insserv and
systemd-sysv at the same time despite the Conflict. I put my patched
src:insserv and src:init-system-helps in a local repo and then ran:

SOURCE_DATE_EPOCH=1776164211 mmdebstrap --include=systemd-sysv,insserv-cheat \
    --chrooted-customize-hook='apt install --yes console-setup-linux userv' \
    unstable chroot.tar http://deb.debian.org/debian \
    "deb [trusted=yes] http://127.0.0.1:8080 ./"

Without above patch, installing console-setup-linux produces the message:

insserv: FATAL: service mountkernfs has to be enabled to use service keyboard-setup.sh

Though for some reason the exit code is not propagated out of the maintainer
script so the "apt install" will still succeed despite this message. The
resulting chroot will have /etc/init.d/.depend.boot, /etc/init.d/.depend.start
and /etc/init.d/.depend.stop populated with the various targets including
userv, keyboard-setup.sh and console-setup.sh.

With above patch, the error message from console-setup-linux is gone and
/etc/init.d/.depend.boot, /etc/init.d/.depend.start and
/etc/init.d/.depend.stop will remain empty.

What else do I have to check? It is a bit unfortunate that console-setup-linux
from bug #1072562 does not result in a non-zero exit. That makes automatically
testing this a bit more tricky.

Thanks!

cheers, josch

Josch,

Thanks for this.

This looks sane to me. Obviously the readlink test could be combined with the my
declaration:

     my $insserv_installed = -x "$dpkg_root$insserv" &&
     -e "$dpkg_root/etc/insserv.conf" &&
     readlink "$dpkg_root/usr/sbin/init" ne "../lib/systemd/systemd";

But that is just sugar.

I agree.

LGTM.

Thanks for taking this on.

Mark

Hi Mark,

Quoting Mark Hindley (2026-04-15 20:29:03)

yes, either would work fine.

What do you imagine would be the next steps? Where does this hang now?

Thanks!

cheers, josch

I suppose

 1) get this patch accepted into src:init-system-helpers

 2) get the Conflicts: insserv removed from systemd-sysv.

Are you able to start with 1)?

Best wishes

Mark

Hi,

Quoting Mark Hindley (2026-04-23 21:19:36)

I already expressed earlier that I have no desire to argue this out with the
systemd maintainers who do not seem to be in favour of this change. Or, in case
of Michael Biebl, even explicitly expressed that they do not want to change
init-system-helpers in that way. I filed
https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/33 but I
have no energy to push this change on a social level. I would need help from
others if accepting this change needs any convincing of people.

Thanks!

cheers, josch

Hi,
I would also support this change since this means openrc could run real
autopkgtests with itself as init etc.

best,

werdahias

Hi Mark,

Quoting Matthias Geiger (2026-06-01 22:35:27)

I filed the MR against init-system-helpers more than 48 days ago and there is
zero maintainer reaction so far.

Michael Biebl is against this change and I do not see a way to change this.

As I see it, we are stuck and nothing is moving.

Unless you have another idea, the only practical way forward I see is creating
an extra binary package shipping the insserv program in some location that is
not in $PATH.

Or do you see any other way forward?

Thanks!

cheers, josch

Josch,

Thanks for this. I feel your pain and am sorry for it.

Unless there is a valid technical reason why the approach you are proposing is
wrong, then an individual's preference is not a good enough reason for
inaction. If there is a technical problem with the proposal, then it should be
identified so it can be addressed. Maybe Michael would clarify why he hasn't yet
merged the change suggested?

Whilst I accept that would 'solve' the immediate issue, I am still very
reluctant to go down that route. The problem here, as I see it, is that it bakes
in the idea that systemd and insserv are incompatible. It would be virtually
impossible to move back from that in the future. The MR proposed ensures that
systemd and insserv *are* compatible. That seems a step forward worthy of
wholehearted.

In my view, systemd, insserv, runit, (soon) native openrc and maybe others in
the future should co-exist peacefully in Debian. Unnecessary conflicts that
obstruct that should not be tolerated.

But maybe my ideals are misplaced. Feel free to tell me so, if you want!

Best wishes

Mark

Mark Hindley writes ("Bug#1132024: Add insserv-bin binary package with /usr/libexec/insserv for easily creating Hurd chroots"):

I agree with this.

I don't think this is actionable by us in the init diversity team.

Johannes, can you please remind where the existing discussions were?
In particular, you say Michael Biebl is against this change.  Can you
provide references?

I think an actionable next step might be to try to summarise the
situation, and send the init-system-helpers maintainer a rather formal
message setting out the options and inviting them to reconsider and/or
expand on their reasoning.

Depending on the response, and our analysis of it, we could change our
mind about our package split; ask for mediation; ask the TC; or decide
we don't want to pick a fight and do a suboptimal thing.

I tend to agree with this.

Ian.

I agree too, just stating "this is not possible" without any technical
reason to back it up is not how we do things.
I agree that the package split should be the last resort; unless there
is proof that this change would break things (which I doubt it will),
there should be no reason by init-system-helper maintainers to block
that. If they insist on their stance *and* do not state why this does
not work then thinking about the TC might be an option IMO.

best,

werdahias

Hi Mark & Ian,

thank you for your replies.

Quoting Ian Jackson (2026-06-10 14:30:14)

It happened in IRC. If you have logs, then look at #debian-devel on March 11
2026.

I proposed changing update-rc.d to do the right thing (skip running insserv) on
systems using systemd as init even if insserv is installed. Michael Biebl said
that they'd rather not touch that.

Michael suggested to install insserv into a location like /usr/libexec.

I also asked whether they agree that the problem is that update-rc.d uses the
presence of /sbin/insserv without checking whether systemd is installed.
Michael disagreed with that without giving more of an explanation.

I asked whether update-rc.d could do something different to solve this
situation and Michael didn't respond anything anymore after that.

I sent a ping to
https://salsa.debian.org/debian/init-system-helpers/-/merge_requests/33

Lets wait maybe a week for a reply to my ping.

Thank you for both your suppport!

cheers, josch