Bug 1019388 - firstboot scripts (virt-builder, virt-sysprep) don't work for Debian 6 & 7 guests
Summary: firstboot scripts (virt-builder, virt-sysprep) don't work for Debian 6 & 7 gu...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-15 15:28 UTC by Richard W.M. Jones
Modified: 2016-09-01 10:19 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-09-01 10:19:46 UTC
Embargoed:


Attachments (Terms of Use)

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 FredL 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 FredL 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 FredL 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.


Note You need to log in before you can comment on or make changes to this bug.