Dear Maintainer,

Initialisation of cloud-init on non-systemd installations is broken. A fresh
installation produces

  Setting up cloud-init (25.3-2)…
  insserv: FATAL: service cloud-init has to be enabled to use service cloud-config

The simple patch below fixes the superficial issue, but I am unsure it addresses
the complete situation.

Version 24.3.1-1 replaces /etc/init.d/cloud-init with
/etc/init.d/cloud-init-main. However, files in /etc/init.d are conffiles and the
original /etc/init.d/cloud-init could persist on installations that are being
upgraded. I think dpkg-maintscript-helper(1) needs to be used to remove or
rename the original, depending on the intention.

Also, I notice the new /etc/init.d/cloud-init-main is actually no-op. Wouldn't
it be simpler to just remove /etc/init.d/cloud-init, /etc/init.d/cloud-init-main
and LSB header references to them? If I have understood that correctly, I am
happy to work up a suitable patch.

Thanks for your thoughts and insight.

Mark

diff -u /etc/init.d/cloud-config /etc/init.d/cloud-config.orig
--- /etc/init.d/cloud-config.orig	2026-02-03 07:22:48.640835483 +0000
+++ /etc/init.d/cloud-config	2026-02-03 07:23:20.448107273 +0000
@@ -1,7 +1,7 @@
 #! /bin/sh
 ### BEGIN INIT INFO
 # Provides:          cloud-config
-# Required-Start:    $local_fs $remote_fs cloud-init cloud-init-local
+# Required-Start:    $local_fs $remote_fs cloud-init-main cloud-init-local
 # Required-Stop:     $remote_fs
 # Default-Start:     2 3 4 5
 # Default-Stop:      0 1 6

Diff finished.  Tue Feb  3 07:27:35 2026

Hi Mark, maintainers,

Matt Gregoire here, Devuan user running cloud-init on sysvinit for my own
cloud templates. I hit this on Devuan Freia and worked up the fix you
offered to
write, on the functionality side: a patch that makes cloud-init-main run
the init
stage instead of the no-op stub, plus the Provides: cloud-init dependency
restore that your report identified.

What it does:

- cloud-init-main runs "cloud-init init" directly. Up to 24.3 the
sysvinit/debian/cloud-init script did this; 24.3.1-1 replaced it with
the stub whose whole body is ":". Result: the init/network stage never
ran on sysvinit at all - user creation, ssh host keys and
authorized_keys silently failed on first boot. The insserv FATAL was
only the visible symptom.
- Re-adds "Provides: cloud-init" so cloud-config's Required-Start is
satisfied (fixes the FATAL in your report).
- Adds $local_fs and cloud-init-local to Required-Start so the local
stage completes before the network stage.

It stacks on top of update-sysvinit.patch (last in series), applies
cleanly against 26.2-1, and I've verified it end-to-end on fresh clones
of my Devuan Freia templates - users, host keys and authorized_keys all
land on first boot now.

On the conffile point in your report: agreed, it's real.
/etc/init.d/cloud-init
can persist on upgrades since there's no maintscript handling in the package
today. My patch doesn't address that - deliberately; it keeps the diff
minimal and the maintscript question is bigger than my fix. If a maintainer
wants a complete solution I'm happy to work up the dpkg-maintscript-helper
piece as a follow-up, or it can ride along with whatever direction you
take on the init scripts generally.

On your other question - whether it'd be simpler to drop
/etc/init.d/cloud-init,
cloud-init-main and their LSB references entirely: possibly, but I'd argue
for keeping sysvinit functional here rather than declaring it dead in
Debian. I keep a fleet on sysvinit for auditability and simplicity, and
I'm not the only one. Upstream cloud-init still ships the sysvinit/
directory, so the capability is there to keep.

Patch inline below. Also happy to send as a salsa MR if that's preferred.

One disclosure, offered freely: this patch was prepared with AI assistance
on my own hardware, at my direction. The analysis, packaging decisions and
test infrastructure behind it are mine, and I have reviewed every line and
verified the behavior end-to-end on fresh sysvinit clones myself. I offer
this since Debian's resolution encourages disclosure as a courtesy. It
should go without saying, but I'll say it: I stand behind the patch, AI
or no AI.

---
Index: cloud-init/sysvinit/debian/cloud-init-main
===================================================================
--- cloud-init.orig/sysvinit/debian/cloud-init-main
+++ cloud-init/sysvinit/debian/cloud-init-main
@@ -1,12 +1,12 @@
#! /bin/sh
### BEGIN INIT INFO
-# Provides: cloud-init-main
-# Required-Start: $remote_fs $syslog
+# Provides: cloud-init-main cloud-init
+# Required-Start: $local_fs $remote_fs $syslog cloud-init-local
# Required-Stop: $remote_fs
# X-Start-Before: sshd
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
-# Short-Description: Cloud init
+# Short-Description: Cloud init (init/network stage)
# Description: Cloud configuration initialization
### END INIT INFO
@@ -14,9 +14,10 @@
# Thomas Goirand <zigo@debian.org>
PATH=/sbin:/usr/sbin:/bin:/usr/bin
-DESC="Cloud service: Single Process"
+DESC="Cloud service: init (network) stage"
NAME=cloud-init
DAEMON=/usr/bin/$NAME
+DAEMON_ARGS="init"
SCRIPTNAME=/etc/init.d/cloud-init-main
# Exit if the package is not installed
@@ -52,8 +53,7 @@
exit 0
fi
- # This is currently a no-op under sysvinit
- :
+ $DAEMON ${DAEMON_ARGS}
case "$?" in
0|1) log_end_msg 0 ;;

Hi Mark, maintainers,

Matt Gregoire here (resend with the patch attached - my first copy's inline
diff lost its tab characters in transit, GUI mail client whitespace
mangling; the attached patch is byte-exact and applies cleanly against
26.2-1 with the current series).

I'm a Devuan user running cloud-init on sysvinit for my own cloud
templates. I hit this on Devuan Freia and worked up the fix you offered to
write, on the functionality side: a patch that makes cloud-init-main run
the init stage instead of the no-op stub, plus the Provides: cloud-init
dependency restore that your report identified.

What it does:

- cloud-init-main runs "cloud-init init" directly. Up to 24.3 the
sysvinit/debian/cloud-init script did this; 24.3.1-1 replaced it with
the stub whose whole body is ":". Result: the init/network stage never
ran on sysvinit at all - user creation, ssh host keys and
authorized_keys silently failed on first boot. The insserv FATAL was
only the visible symptom.
- Re-adds "Provides: cloud-init" so cloud-config's Required-Start is
satisfied (fixes the FATAL in your report).
- Adds $local_fs and cloud-init-local to Required-Start so the local
stage completes before the network stage.

It stacks on top of update-sysvinit.patch (last in series), applies
cleanly against 26.2-1, and I've verified it end-to-end on fresh clones
of my Devuan Freia templates - users, host keys and authorized_keys all
land on first boot now.

On the conffile point in your report: agreed, it's real.
/etc/init.d/cloud-init
can persist on upgrades since there's no maintscript handling in the package
today. My patch doesn't address that - deliberately; it keeps the diff
minimal and the maintscript question is bigger than my fix. If a maintainer
wants a complete solution I'm happy to work up the dpkg-maintscript-helper
piece as a follow-up, or it can ride along with whatever direction you
take on the init scripts generally.

On your other question - whether it'd be simpler to drop
/etc/init.d/cloud-init,
cloud-init-main and their LSB references entirely: possibly, but I'd argue
for keeping sysvinit functional here rather than declaring it dead in
Debian. I keep a fleet on sysvinit for auditability and simplicity, and
I'm not the only one. Upstream cloud-init still ships the sysvinit/
directory, so the capability is there to keep.

Patch attached (fix-sysvinit-init-stage.patch, unified diff, DEP3
headers included). Also happy to send as a salsa MR if that's preferred.

One disclosure, offered freely: this patch was prepared with AI assistance
on my own hardware, at my direction. The analysis, packaging decisions and
test infrastructure behind it are mine, and I have reviewed every line and
verified the behavior end-to-end on fresh sysvinit clones myself. I offer
this since Debian's resolution encourages disclosure as a courtesy. It
should go without saying, but I'll say it: I stand behind the patch, AI
or no AI.

Matt Gregoire
matt@0010.ca