Bug 1019388

Summary: firstboot scripts (virt-builder, virt-sysprep) don't work for Debian 6 & 7 guests
Product: [Community] Virtualization Tools Reporter: Richard W.M. Jones <rjones>
Component: libguestfsAssignee: Richard W.M. Jones <rjones>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: frederic.lespez, mbooth, ptoscano, rbalakri
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-01 10:19:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard W.M. Jones 2013-10-15 15:28:40 UTC
Description of problem:

virt-sysprep and virt-builder have various --firstboot options
which let you inject scripts that run once the first time the
guest is booted.  However they do not work for Debian 6 & 7
guests (they do work for other guests).

Version-Release number of selected component (if applicable):

libguestfs 1.23.32.

How reproducible:

100%

Steps to Reproduce:

  virt-builder debian-6 --firstboot-command "echo HELLO WORLD"

(or use debian-7 instead of debian-6).  After the guest has been
created, boot it up and check to see if the /root/virt-sysprep-firstboot.log
file exists and contains the magic string.

Actual results:

No log file created and it doesn't contain the magic string.

Expected results:

Log file created and it contains the magic string.

Additional info:

Is it because we're not running update-rc.d?

Comment 1 Pino Toscano 2013-12-12 13:34:07 UTC
(In reply to Richard W.M. Jones from comment #0)
> Is it because we're not running update-rc.d?

Yes, correct.

Since Debian 6 (or for sure Debian 7) the SysV boot has become dependency-based, so just adding the init script and manually creating the symlinks is not enough.

But running update-rc.d or insserv is not an option, so in case firsrboot.ml should basically do something similar to what insserv does, i.e. fiddle with the services dependencies adding our own firstboot script service.

Comment 2 Frédéric Lespez 2014-06-29 14:17:42 UTC
I am using Debian testing with libguestfs version 1.26.2.

This bug is still present with debian 7 images at least (I didn't test with anything else).

Here is a workaround :
You need to run update-rc.d (previously reported) with a "--run-command" option.
For example :
virt-sysprep -a /path/to/image.img --firstboot /path/to/firstboot_script --run-command 'update-rc.d virt-sysprep-firstboot defaults'

Comment 3 Richard W.M. Jones 2014-06-30 07:47:59 UTC
So probably using the update-rc.d command (comment 2) in
install_sysvinit_debian would work
https://github.com/libguestfs/libguestfs/blob/16e817456cf7e5162ba053c92f1a4df24a4160d5/customize/firstboot.ml#L144
I really don't like running guest commands for sysprep
operations.  It would be better to `virt-diff' the guest
before and after update-rc.d to see what it does.

Comment 4 Frédéric Lespez 2014-07-02 20:44:40 UTC
I have done `virt-diff' the guest before and after update-rc.d.
Here is the differences :
 - the file /etc/init.d/.depend.start has changed
--- etc1/init.d/.depend.start	2014-06-25 15:39:24.000000000 +0200
+++ etc2/init.d/.depend.start	2014-07-02 22:17:37.000000000 +0200
@@ -1,4 +1,4 @@
-TARGETS = killprocs motd rpcbind nfs-common rsyslog exim4 atd cron acpid ssh bootlogs single rmnologin rc.local
+TARGETS = killprocs motd rpcbind nfs-common rsyslog exim4 atd cron acpid ssh bootlogs single virt-sysprep-firstboot rmnologin rc.local
 INTERACTIVE =
 exim4: rsyslog
 atd: rsyslog
@@ -6,5 +6,6 @@
 acpid: rsyslog
 ssh: rsyslog
 single: killprocs bootlogs motd
+virt-sysprep-firstboot: rpcbind nfs-common rsyslog exim4 atd bootlogs motd cron acpid ssh
 rmnologin: rpcbind nfs-common rsyslog exim4 atd bootlogs motd cron acpid ssh
 rc.local: rpcbind nfs-common rsyslog exim4 atd bootlogs motd cron acpid ssh
 - the symlink /etc/rc2.d/S99virt-sysprep-firstboot has changed
Before: /etc/rc2.d/S99virt-sysprep-firstboot -> /etc/init.d/virt-sysprep-firstboot
After: /etc/rc2.d/S20virt-sysprep-firstboot -> ../init.d/virt-sysprep-firstboot
 - the symlink /etc/rc3.d/S99virt-sysprep-firstboot has changed
Before: /etc/rc3.d/S99virt-sysprep-firstboot -> /etc/init.d/virt-sysprep-firstboot
After: /etc/rc3.d/S20virt-sysprep-firstboot -> ../init.d/virt-sysprep-firstboot
 - the symlink /etc/rc5.d/S99virt-sysprep-firstboot has changed
Before: /etc/rc5.d/S99virt-sysprep-firstboot -> /etc/init.d/virt-sysprep-firstboot
After: /etc/rc5.d/S20virt-sysprep-firstboot -> ../init.d/virt-sysprep-firstboot

I think that only the /etc/init.d/.depend.start is relevant.

Comment 5 Frédéric Lespez 2014-07-02 20:51:07 UTC
Instead of doing:
--run-command 'update-rc.d virt-sysprep-firstboot defaults'
you can just do:
--run-command 'insserv'

insserv doesn't exactly the same thing (ie it gives the same 'virt-diff').

Comment 6 Richard W.M. Jones 2014-07-03 07:42:44 UTC
Thanks, this is all interesting and useful information for when
we (or someone) comes to fix this.

Comment 7 Richard W.M. Jones 2016-08-26 20:56:05 UTC
Proposed patch:
https://www.redhat.com/archives/libguestfs/2016-August/thread.html#00208

Comment 8 Richard W.M. Jones 2016-09-01 10:19:46 UTC
Fixed upstream in libguestfs >= 1.35.3 and >= 1.34.2.