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 <[email protected]>
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 ;;
