On 21.09.23 19:43, Richard W.M. Jones wrote:
On Thu, Sep 21, 2023 at 06:24:40PM +0200, Lee Garrett wrote:
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/e70d89a58dae068be2e19c7...
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/e70d89a58dae068be2e19c7...
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.
So this is probably another instance or variation of the timezone formatting problem (of schtasks). Which version of virt-v2v is this? I want to check that you have a version with all the latest patches in this area.
It's 2.2.0-1 from Debian (12) bookworm. I've verified that it doesn't have any distro-specific patches. (https://salsa.debian.org/libvirt-team/virt-v2v/-/tree/debian/master/debian would have a patches/series file in this case)
Rich.
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