Bug 988860 - virt-sysprep --firstboot option writes incorrect "99" (instead of "S99") sysv-init-style start up script
Summary: virt-sysprep --firstboot option writes incorrect "99" (instead of "S99") sysv...
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: 988862 988863
TreeView+ depends on / blocked
 
Reported: 2013-07-26 15:09 UTC by Richard W.M. Jones
Modified: 2013-07-26 15:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 988862 988863 (view as bug list)
Environment:
Last Closed: 2013-07-26 15:13:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Richard W.M. Jones 2013-07-26 15:09:30 UTC
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 Richard W.M. Jones 2013-07-26 15:13:23 UTC
Closing as this bug has already been fixed upstream as
noted in the description.


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