similar to: [PATCH] customize: firstboot: make sure to run Linux scripts only once

If a script does not finish, hangs, etc, it would be executed again at the next boot, since the injected firstboot.sh helper removes it only after it finished. Before executing a script, move it to another internal subdirectory (scripts-done) and execute it from there, so it is not run again by firstboot.sh. The downside is that now scripts are executed only once at all, so if a script fails it

Pass -a to each tee invocation, otherwise just the last one (so only for the last script executed) will appear in the log file. --- customize/firstboot.ml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/customize/firstboot.ml b/customize/firstboot.ml index 89821f3..0b95708 100644 --- a/customize/firstboot.ml +++ b/customize/firstboot.ml @@ -50,8 +50,8 @@ d=%s/scripts

On Mon, Nov 03, 2014 at 08:49:08PM +0100, Pino Toscano wrote: > If a script does not finish, hangs, etc, it would be executed again at > the next boot, since the injected firstboot.sh helper removes it only > after it finished. > > Since firstboot.sh only runs executable files, then remove the > executable attributes before running it, so it will not run again. > Also, remove

This patchset attempts to address a number of shortcomings in the firstboot infrastructure I came across while working with v2v conversion of various Windows VMs. Roman Kagan (4): firstboot: consolidate line ending conversion firstboot: enhance firstboot driver script for Windows firstboot: make script naming descriptive convert_windows: split firstboot into steps

Currently we install a systemd service named firstboot.service and a SysV service named virt-sysprep-firstboot. On systems where systemd is the init system and runs with the SysV compatibility, the different names make systemd handle them as different services, and thus trying to run the firstboot script runner twice. Rename both the systemd service and the SysV one to guestfs-firstboot: the new

When firstboot is used from virt-v2v the scripts, if not fast enough, can get killed by Windows. After windows installs virtio drivers injected by virt-v2v it performs some internall reboot, stopping all the running services and killing any running firstboot script. This is problem mostly for MSI installs (like qemu-ga that was added recently) that can take several seconds to finish. This change

I have only verified the fix on Debian 7. The Debian 6 guest doesn't appear to boot, I'm not sure why. The second patch contains a test suite. Rich.

Currently firstboot would only work on redhat-based images. Handle redhat-based, suse-based and debian guests, error out in case of an unknown distro. Update firstboot.sh: - make sure scripts exists and can be executed - add LSB header to avoid insserv warnings later on - run script only if called with "start" Update functions, pass only required options. Signed-off-by: Olaf Hering

Hi all, v2 includes all comments from Pino and Richard. I also removed the mkdir /run/lvm in the init since it only failed in one case and couldn't reproduce it anymore. Cédric Bosdonnat (11): v2v: also search for windows virtio drivers in symlinks Update packagelist for SLES and openSUSE customize: fix windows firstboot script customize: change windows firstboot path customize:

In the TODO file there's a discussion of perhaps writing a new 'virt-customize' tool. I think it's probably better (or at any rate, easier) to just add this functionality into virt-sysprep. That is what this small series of patches aims to achieve. Note these are not very well tested at the moment. The first patch adds a generic and useful '--firstboot' flag. The

On Tue, Apr 05, 2016 at 01:47:29PM +0200, Cédric Bosdonnat wrote: > The output of the first boot scripts is available in the guest as > -F<C:\Program Files\Red Hat\Firstboot\log.txt>. > +F<C:\Program Files\Guestfs\Firstboot\log.txt>. Changing this path is fine, but let's split it into a separate patch. > + let services = ["rhsrvany.exe";

Rename the C:\Program Files\Red Hat\Firstboot folder into the more vendor independent C:\Program Files\Guestfs\Firstboot. --- builder/virt-builder.pod | 2 +- customize/firstboot.ml | 2 +- v2v/test-v2v-in-place.sh | 2 +- v2v/test-v2v-virtio-win-iso.sh | 2 +- v2v/test-v2v-windows-conversion.sh | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff

Hello, We have a nodejs app which is injecting first boot scripts using virt-customize however the exact same commands are working when triggered manually. Here is the debug output of the commands Regards, Peter [ 0.0] Examining the guest ... libguestfs: trace: set_network true libguestfs: trace: set_network = 0 libguestfs: trace: add_drive

v1: https://www.redhat.com/archives/libguestfs/2017-July/msg00127.html v2: - Remove /etc/systemd/system/default.target.wants/guestfs-firstboot.service link as well. - Use multi-user.target for virt-p2v as well. Rich.

Hi there! I know it's been a while since I posted my first version of some patches. But here I have rebased them on top of Roman's work and added a few other ones. Cédric Bosdonnat (11): v2v: also search for windows virtio drivers in symlinks Update packagelist for SLES customize: fix windows firstboot script customize: change windows firstboot path customize: add support for

There's not going to be an easy way to present this patch. It's huge and interconnected. Anyway, what it does is lay the groundwork for a new tool which I'm calling 'virt-customize'. virt-customize is virt-builder, but without the part where it downloads a template from a respository. Just the part where it customizes the template, that is, installing packages, editing

Rename the C:\Program Files\Red Hat\Firstboot folder into the more vendor independent C:\Program Files\Guestfs\Firstboot. --- builder/virt-builder.pod | 2 +- customize/firstboot.ml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/builder/virt-builder.pod b/builder/virt-builder.pod index 9a49138..dc36c13 100644 --- a/builder/virt-builder.pod +++ b/builder/virt-builder.pod

See: https://bugzilla.redhat.com/show_bug.cgi?id=1469655 https://github.com/systemd/systemd/issues/6334 https://lists.freedesktop.org/archives/systemd-devel/2017-July/039325.html

When the guest uses systemd, install firstboot scripts under ‘multi-user.target’. See this link for details: https://lists.freedesktop.org/archives/systemd-devel/2017-July/039325.html This fixes firstboot on Fedora 26 (and in general with systemd >= 233). Thanks: Lennart Poettering --- customize/firstboot.ml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

I am running libguestfs version 1.34.2 The issue is the following. When I start the vm with virt-log I see this: Mar 13 17:33:30 multi6 firstboot.sh[358]: /usr/lib/virt-sysprep/firstboot.sh start Mar 13 17:33:30 multi6 cron[359]: (CRON) INFO (Running @reboot jobs) Mar 13 17:33:30 multi6 firstboot.sh[358]: Scripts dir: /usr/lib/virt-sysprep/scripts Mar 13 17:33:30 multi6 firstboot.sh[358]: ===