similar to: [PATCH] firstboot: rename systemd service file

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

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 systemd handle them as different services, and thus trying to > run the firstboot script runner

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.

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

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

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

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.

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

Turn the rc.d symlinks for the guestfs-firstboot service as relative, instead of absolute paths: the result is the same (the service works the same), and this way is more coherent with symlinks created by update-rc.d. --- customize/firstboot.ml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/customize/firstboot.ml b/customize/firstboot.ml index 52dfbbe..706d63c 100644

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

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

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

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

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

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

What's the best way around "firstboot" ? "firstboot" hung my machine and had to blown it up to get past it. If you bypass firstboot, what other config settings is one missing? I found the following info.... ==================================================================== # Booting without Internet Connection / Stuck on RedHat Registration during First Bootup This

On Fri, Oct 07, 2016 at 04:42:21PM -0400, Charlie Drage wrote: > I apologize if this is not the appropriate place to contact you.. Adding the mailing list. > Got a weird issue! > > So when I use --firstboot via virt-sysprep on a host, it's totally fine. > > However.. > > In this scenario: > 1. virt-sysprep an offline image > 2. transfer said image from one

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

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

Dear Experts, Sorry about taking shortcut and asking everybody... My question is: how do you avoid "firstboot" screen in latest CentOS 7.3 kickstart. I have installed about a dozen of CentOS 7 (none of which was 7.3) with that kickstart file. None of them ever went to firstboot screen on first boot. Now after kickstart installation of CentOS 7.3 it goes into firstboot screen showing