similar to: virt-builder: --ssh-inject fails because it is executed before --firstboot-command?

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

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 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 all the fixes for Debian firstboot issues, in particular the ones related to https://bugzilla.redhat.com/1019388 > The issue is the following. When I start the vm with virt-log I see this: > > Mar 13 17:33:30 multi6

On Tue, Mar 14, 2017 at 04:46:41PM +0200, Keresztes Péter-Zoltán wrote: > We are enforcing #!/bin/bash at the beginning of the scripts and bash is installed in every guest. No idea in that case. Suggest using guestfish on the guest after virt-customize has run to check that the files are really being installed in the right places and have the right permissions etc. Rich. > Regards,

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

Figured it out. The generated script had CRLF line termination. When we have removed the \r from the end if line everything started to work. Thanks for the help. Regards, Peter > On 14 Mar 2017, at 17:00, Richard W.M. Jones <rjones@redhat.com> wrote: > > On Tue, Mar 14, 2017 at 04:46:41PM +0200, Keresztes Péter-Zoltán wrote: >> We are enforcing #!/bin/bash at the beginning

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

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

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

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

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

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

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 Wed, Jun 22, 2016 at 05:56:09PM -0500, libvirt_users@skagitattic.com wrote: > > Delete what you've done and start from the beginning. Describe > > exactly how you created the guest. Use 'qemu-img info' to show the > > format of the input file. Show precisely the virt-sparsify command > > you are running. And use 'qemu-img info' on the output file

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

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

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 Wed, Mar 08, 2023 at 08:05:35PM +0200, Andrey Drobyshev wrote: > During conversion we copy the necessary drivers to the directory > "%systemroot%\Drivers\Virtio", adding it to the DevicePath registry > value. As documented in [1], this should be enough for Windows to find > device drivers and successfully install them. > > However, it doesn't always happen.