similar to: [PATCH] customize: firstboot: fix Linux log output

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

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 any file found in the scripts subdirectory, be it just run or run in a previous boot. This

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]: ===

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

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

On 03/12/2015 04:35 AM, Richard W.M. Jones wrote: >> leer@eng-leer:~/libguestfs-1.29.29$ virt-builder fedora-21 >> --run-command "ping -c 4 172.16.12.200" >> [ 1.0] Downloading: http://libguestfs.org/download/builder/fedora-21.xz >> [ 1.0] Planning how to build this image >> [ 1.0] Uncompressing >> [ 28.0] Opening the new disk >> [ 31.0]

On Mon, Mar 13, 2017 at 11:48:05PM +0200, Keresztes Péter-Zoltán wrote: > 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 Which version of virt-customize? A number of bugs were fixed in this part of the code in the last

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 the systemd service to virt-sysprep-firstboot as well: other than being

We are enforcing #!/bin/bash at the beginning of the scripts and bash is installed in every guest. Regards, Peter 2017. márc. 14. dátummal, 16:14 időpontban Richard W.M. Jones <rjones@redhat.com> írta: >> On Tue, Mar 14, 2017 at 03:45:34PM +0200, Keresztes Péter-Zoltán wrote: >> I am running libguestfs version 1.34.2 > > As far as I know, this version should contain

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

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

I'm trying to customize the firstboot process in CentOS 5 and have come across a few issues that are driving me nuts. I'm sure they are all upstream issues, but I don't have a RHEL 5 system to verify them. I had these customizations working in CentOS 4, but things that used to work then don't work now. The main problem is that you can't validate user input. This

On Thu, Nov 21, 2019 at 12:04:18PM +0100, Tomáš Golembiovský wrote: > Instead of running firstboot scripts during early boot schedule a task > delayed for 1-2 minute. > > During the first boot, after virt-v2v conversion, Windows installs the > drivers injected by virit-v2v. When this installation is finished > Windows enforces some kind of internal reboot. This unfortunately

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

On Wednesday, 3 August 2016 16:39:46 CEST Richard W.M. Jones wrote: > On Wed, Aug 03, 2016 at 05:35:14PM +0200, Pino Toscano wrote: > > 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

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

I am running the stock libguestfs on latest Ubuntu 16.04 (1:1.32.2-4ubuntu2). My guests are also Ubuntu 16.04. I am running virt-sysprep with --firstboot-command 'dpkg-reconfigure openssh-server'. This works 90% of the time, but occasionally when a new guest first starts it can't find the script: ~# cat virt-sysprep-firstboot.log /etc/init.d/virt-sysprep-firstboot start Scripts

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

On Thu, 2016-05-12 at 17:24 +0300, Roman Kagan wrote: > On Thu, May 12, 2016 at 03:29:11PM +0200, Cédric Bosdonnat wrote: > > Sync the windows firstboot script with its linux brother. Also > > change > > the main redirection to append to the log rather than overwriting > > it. > > With this change, the firstboot script will resist reboots in the > > executed

Sync the windows firstboot script with its linux brother. Also change the main redirection to append to the log rather than overwriting it. With this change, the firstboot script will resist reboots in the executed scripts. --- customize/firstboot.ml | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/customize/firstboot.ml b/customize/firstboot.ml index