Bug 1160203
| Summary: | log of virt-sysprep contains only the output of the last script | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Pino Toscano <ptoscano> |
| Component: | libguestfs | Assignee: | Pino Toscano <ptoscano> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.6 | CC: | huzhan, jherrman, leiwang, mbooth, ptoscano, rjones, virt-bugs, wshi |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | libguestfs-1.20.11-12.el6 | Doc Type: | Bug Fix |
| Doc Text: |
Due to an incorrect implementation of the libguestfs firstboot scripts runner, the firstboot scripts logged only the last executed script instead of all executed scripts. In addition, firstboot scripts that cause booting to stop, such as a script that reboots the guest, were unintentionally executed on every boot. These problems have now been fixed.
|
Story Points: | --- |
| Clone Of: | 1160199 | Environment: | |
| Last Closed: | 2015-07-22 05:56:16 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: | |||
| Bug Depends On: | 1160199 | ||
| Bug Blocks: | |||
|
Description
Pino Toscano
2014-11-04 10:27:08 UTC
The bug cannot be reproduced with libguestfs-1.20.11-11.el6. It seems to be that libguestfs-1.20.11-11.el6 do not support the command "--firstboot-command". Steps: 1. $ virt-sysprep --firstboot-command 'echo first' --firstboot-command 'echo second' -d kvm1 Actual results: virt-sysprep: unknown option `--firstboot-command'. virt-sysprep: reset or unconfigure a virtual machine so clones can be made ....(no "--firstboot-command" info) 2. $ man virt-sysprep ....(no "--firstboot-command" info) We rebased virt-sysprep. It turned out that the rebased virt-sysprep contained a bug in a new feature (--firstboot-command) to do with how it writes log files, and this bug was filed to fix that. Therefore there isn't a way to reproduce the bug, all we can do is check that the bug doesn't exist in the latest virt-sysprep. Gosh, closed it accidentally. I'd prefer if it could be verified by QA. (In reply to Chao Zhang from comment #2) > The bug cannot be reproduced with libguestfs-1.20.11-11.el6. > It seems to be that libguestfs-1.20.11-11.el6 do not support the command > "--firstboot-command". > > > Steps: > > 1. $ virt-sysprep --firstboot-command 'echo first' --firstboot-command 'echo > second' -d kvm1 > > Actual results: > > virt-sysprep: unknown option `--firstboot-command'. > virt-sysprep: reset or unconfigure a virtual machine so clones can be made > ....(no "--firstboot-command" info) > > 2. $ man virt-sysprep > ....(no "--firstboot-command" info) The bug was initially reproduced on master, where --firstboot-command exists, so I just cloned that given the firstboot capabilities exist in 6.6+. Indeed there's no --firstboot-command, but there's --firstboot, which is used to run existing scripts, and it is indeed affected by the issue. Putting back to ON_QA. Verified with the package version: libguestfs-1.20.11-14.el6.x86_64 Verify steps: 1. Edit two simple shell scripts as following. # cat /path/to/echo1.sh echo first # cat /path/to/echo1.sh echo second 2. Run the following command # virt-sysprep -a $image --firstboot /path/to/echo1.sh --firstboot /path/to/echo2.sh 3. Run the guest, login and check the log file ~root/virt-sysprep-firstboot.log in the guest. # cat /root/virt-sysprep-firstboot.log /usr/lib/virt-sysprep/firstboot.sh start Scripts dir: /usr/lib/virt-sysprep/scripts === Running /usr/lib/virt-sysprep/scripts/0001-1426038326-gpsyazqb === first === Running /usr/lib/virt-sysprep/scripts/0002-1426038326-nv6iu426 === second It returns the expected result. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1444.html |