Bug 988862 - virt-sysprep --firstboot option writes incorrect "99" (instead of "S99") sysv-init-style start up script
virt-sysprep --firstboot option writes incorrect "99" (instead of "S99") sysv...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Richard W.M. Jones
Virtualization Bugs
:
Depends On: 988860
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-26 11:12 EDT by Richard W.M. Jones
Modified: 2014-06-17 22:00 EDT (History)
6 users (show)

See Also:
Fixed In Version: libguestfs-1.22.5-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 988860
Environment:
Last Closed: 2014-06-13 05:22:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard W.M. Jones 2013-07-26 11:12:25 EDT
+++ This bug was initially created as a clone of Bug #988860 +++

Description of problem:

When you use virt-sysprep on a pre-systemd guest (eg. RHEL 6 guest),
with the --firstboot option, it writes a start-up script called

/etc/rc.d/rc3.d/99virt-sysprep-firstboot

This is of course wrong.  The file should be called

/etc/rc.d/rc3.d/S99virt-sysprep-firstboot
                ^NB

As a result of the incorrect name, the firstboot script does not run.

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

libguestfs 1.20.9, 1.22.4, 1.23.10

Note I have fixed this upstream already:
https://github.com/libguestfs/libguestfs/commit/44c5026d9e06cf5f01098608ddd0aa4acb7bb6eb
This bug exists so that I can check the fix goes into RHEL 6 & RHEL 7.

How reproducible:

100%

Steps to Reproduce:

Create a small shell script that "does something useful".  eg.
It could touch a file at a known location.

export LIBGUESTFS_TRACE=1
virt-sysprep --firstboot ./some-script.sh -a RHEL6.guest
Try to boot the guest.

Observe whether or not the firstboot script ran when the
guest booted (eg. was the file touched?)

Additional info:

The bug was found by Nick Strugnell.
Comment 1 bfan 2013-07-29 05:01:17 EDT
Can reproduce with libguestfs-1.22.4-2.el7.x86_64

[root]# cat some-script.sh 

#!/bin/bash

touch /home/usefulfile

[root]# virt-sysprep --firstboot ./some-script.sh -a RHEL-Server-6.4-64-hvm.raw
/home/usefulfile

then, boot up the rhel6.4 guest, and there is no /home/usefulfile
Comment 3 Lingfei Kong 2013-11-16 21:57:16 EST
Verified with libguestfs-1.22.6-15.el7

Steps:
1. Create test script:
[root@rhel7libguestfs ~]# cat test.sh 
#!/bin/bash

touch /root/test.txt
echo "Hello World!"

2. [root@rhel7libguestfs ~]#  virt-sysprep --firstboot ./test.sh  -a RHEL-Server-6.5-64-20131024.1-hvm.qcow 

3. Check in the guest:
#ls /root/
#test.txt virt-sysprep-firstboot.log


Additional info:
In the guest
#cat virt-sysprep-firstboot.log
=== Running /usr/lib/virt-sysprep/scripts/1384656116-azw3p6uu-test-sh ===
Hello World!
Comment 4 Ludek Smid 2014-06-13 05:22:38 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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