Re: [Libguestfs] Fwd: virt-v2v creating image that does not install guest agent on first boot

On 21.09.23 18:08, Richard W.M. Jones wrote: >On Thu, Sep 21, 2023 at 04:50:26PM +0200, Lee Garrett wrote: >>After testing it again today, the guest agent is still not >>installed, however this time the C:\Program >>Files\Guestfs\Firstboot\log.txt exists: >> >>starting firstboot service >>running "C:\Program Files\Guestfs\Firstboot\scripts\5000-0001-wait-pnp.bat" >> 1 file(s) moved. >>Wait for PnP to complete >>.... exit code 0 >>running "C:\Program Files\Guestfs\Firstboot\scripts\5000-0002-install-qemu-ga-x86_64-msi-ps1.bat" >> 1 file(s) moved. >>Removing any previously scheduled qemu-ga installation >>ERROR: The system cannot find the file specified. >>Scheduling delayed installation of qemu-ga from qemu-ga-x86_64.msi >>SUCCESS: The scheduled task "Firstboot-qemu-ga" has successfully been created. >>.... exit code 0 >>running "C:\Program >>Files\Guestfs\Firstboot\scripts\5000-0003-uninstall-VMware-Tools.bat" >> 1 file(s) moved. >>uninstalling VMware Tools >>.... exit code 0 >>uninstalling firstboot service >>Service uninstalled successfully >> >> >>The folder scripts is empty, all scripts are in scripts-done. The >>contents of the folder are: >>5000-0001-wait-pnp.bat >>123 5000-0001-wait-pnp.log >>5000-0002-install-qemu-ga-x86_64-msi-ps1.bat >>5000-0003-uninstall-VMware-Tools.bat >>5000-0003-uninstall-VMware-Tools.log >> >>Note that the .log is missing for qemu-ga. > >This is what we'd expect, except maybe the missing log for qemu-ga. >It's a little odd that it is missing, but it's also possible that the >log file doesn't get written if there's no output. > >>At least today I could twice provision the windows 11 VM, and in >>both cases the main log.txt was generated by the time I checked. How >>are the services scheduled? Could it be that they were delayed by > >>1h? > >Yes, we do actually try to delay qemu-ga installation. It should only >be delayed for about 120 seconds (not 1 hour). > >https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L580 > >However there have been timezone bugs with this in the past (and maybe >there still are), see the sordid history in these two links: > >https://github.com/libguestfs/libguestfs-common/blob/e70d89a58dae068be2e19c7c21558707261af96a/mlcustomize/inject_virtio_win.ml#L558 I see. That's not reassuring. :( > >Which TZ are you in? The host machine is UTC+2 (Berlin summer time), however the Windows 11 trial vmware image itself defaults to UTC-8 (Pacific Time US & Canada). After a little bit of digging this indeed seems to be the issue. `schtasks.exe /Query` gives: PS C:\Users\User> schtasks.exe /Query Folder: \ TaskName Next Run Time Status ======================================== ====================== =============== Firstboot-qemu-ga 9/21/2023 4:04:00 PM Ready [...] which is ~7 hours in the future. Btw, running `.\5000-0002-install-qemu-ga-x86_64-msi-ps1.bat` by hand works just fine. So it definitely is just the scheduling issue that's preventing it from running.

> >Rich. > >>On 11.09.23 21:29, Richard W.M. Jones wrote: >>> >>>If we suspect that the whole firstboot mechanism might not be working >>>with the new version of Windows, one way to test it (on this one, or a >>>freshly installed Windows VM) would be: >>> >>> $ virt-customize -a windows.img --firstboot-command 'echo hello' >>> >>>and see if "hello" is written in some form to the log.txt file inside >>>the guest after it boots. >>> >>>If that doesn't work then it's likely some change in Windows which is >>>breaking firstboot support. >>> >>>Rich. >>> >> >>Regards, Lee > Regards, Lee