Open
Conversation
Powershell can actually run the script fine if we just use '-file /Windows/Temp/whatever.ps1' so we don't need to make things complicated by calculating a Windows path.
In all the online documentation I can find people are just running "powershell.exe" directly without any path, so use that. Maybe the path was required for very old versions of Windows?
Don't load the user's profile (start up commands etc).
Commit dc66e78fa3 ("windows: delay installation of qemu-ga MSI")
attempted to delay installation of the qemu-ga installer. The stated
reasons was a reboot that happens after installing the virtio-win
drivers, which interrupted (and broke) ongoing installation of
qemu-ga.
However while that might have been an issue at the time, I don't think
it's an issue now. We use pnputil to install the drivers, and
pnp_wait to wait for the installation to settle. In my testing, this
firstboot script runs after the reboot.
Using schtasks is a nightmare and this has caused many other problems.
There seems no reliable way to delay installation in the way stated in
the original commit.
Note I also changed /forcerestart -> /norestart since there seems no
good reason to do another reboot here. Also I simplified the code so
there's only one script, even if we found multiple MSIs.
Reverts: commit dc66e78fa37db33e3c7358b7f7c7fa809cf62f9d
Fixes: https://issues.redhat.com/browse/RHEL-49761
Thanks: Morgan Weetman
The qemu-ga installer is a Windows GUI program so it runs asynchronously with the script (in Unix terms, as if the command was run using '&'). This means that it will still be running after the script ends, potentially causing problems with later scripts such as the VMware uninstaller. Plus it's generally undesirable not to wait for it to finish. Fixes: https://issues.redhat.com/browse/RHEL-49761 Thanks: Yan Vugenfirer Updates: commit 5d1f5b8
This returns the name of the firstboot directory in the guest, creating it if necessary. We will use this to ensure we place temporary scripts and files here rather than all over the filesystem as before.
Rather than placing these in %systemroot%\Temp, keep them with the other scripts. This should make capturing debugging information from customers easier.
Instead of dumping these in the root directory, place them into our own Temp directory. This just moves the location where they are copied, but should have no other effect.
It is apparently not possible to get the QEMU Guest Agent installer to just log to the regular output channel, it will only write to a named log file. Print the name of this log file in log.txt so at least users will know where to look for the real logs.
No change, just adds comments.
After help from some Windows friends and looking at the code in this project: https://github.com/HCK-CI/HLK-Setup-Scripts/ we learned that Windows installers lock files in a way that makes subsequent steps in the firstboot process fail. The 'fix' for this is to reboot after each stage of the install. This leads to a large number of reboots (only the first time after conversion), but does appear to work, even fixing VMware Tools uninstallation which we previously thought impossible. Fixes: https://issues.redhat.com/browse/RHEL-49761 Fixes: https://issues.redhat.com/browse/RHEL-51169 Thanks: Konstantin Kostiuk, Yuri Benditovich
These were previously present in guestfs-tools/customize/ but they are dependencies of the common mlcustomize/ code so there was a rather weird circular importing situation. This is a largely straightforward move of these modules into the common code.
Fixes: https://issues.redhat.com/browse/RHEL-56383 Thanks: Vadim Rozenfeld
enable virt-customize options, such as first-boot, hostname, password. Signed-off-by: Wang Guoquan <wangguoquan03@foxmail.com>
Fixes: https://issues.redhat.com/browse/RHEL-65009 Fixes: https://issues.redhat.com/browse/RHEL-65010 Reported-by: Ming Xie
This defines a function and as per usual syntax we put 'in' on a new line at the end of functions.
This is already defined by AC_CANONICAL_HOST in the configure scripts. It will have a value similar to "linux-gnu" on Linux platforms.
If you tried to use --run/--run-command with a Windows guest
you would get the obscure error:
virt-customize: warning: log file /builder.log: Guestfs.Error("download:
/builder.log: No such file or directory") (ignored)
virt-customize: error: ls: command exited with an error
Check that the guest OS is compatible with the host OS. In fact we
can assume that the host OS is always Linux, so we're only interested
in checking that the guest OS is also Linux.
After this change, the error becomes:
virt-customize: error: host (linux-gnu/x86_64) and guest
(windows/i386) are not compatible, so you cannot use command line
options that involve running commands in the guest. Use --firstboot
scripts instead.
This is slightly more restrictive than before, but not in a way that
matters in practice.
Also this cleans up the obscure ~incompatible_fn argument so it does
something sensible, and improves the documentation.
Fixes: https://issues.redhat.com/browse/RHEL-67560
Fixes: https://issues.redhat.com/browse/RHEL-67565
Reported-by: Ming Xie
This used to contain some vestigial code to locate UEFI code and NVRAM files. It was only used by virt-v2v -o qemu. Following changes mean it will no longer be used by virt-v2v.
Add qemuopts_add_raw function which can be used to add raw, unquoted output to a qemu command line. This can only be used when creating a script. Use with caution. We use this with virt-v2v -o qemu to allow flexible command line options to be defined in prior shell script.
Fixes: commit 1389356
This module replaced the Stdlib Option module, and was only needed in OCaml <= 4.07. Since libguestfs now depends on OCaml >= 4.08, we no longer need this. The same source code will use the Option module from Stdlib instead.
Even our previous baseline of OCaml 4.07 had this function, so the test was not required before, and even less now that we have moved to baseline OCaml 4.08.
Fedora 34+ and RHEL 9.0+ unified BIOS and UEFI grub configuration into a single file. This leaves /boot/efi/EFI/<OS>/grub.cfg as a so-called "wrapper" which just loads the real grub2 configuration at /boot/grub2/grub.cfg. Running '/sbin/grub2-mkconfig -o /boot/efi/EFI/<OS>/grub.cfg' overwrites the wrapper instead of the real configuration file. RHEL 9.5 added a hard error if you try to do this, which broke virt-v2v. The error message was: commandrvf: /sbin/grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg Running `grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg' will overwrite the GRUB wrapper. Please run `grub2-mkconfig -o /boot/grub2/grub.cfg' instead to update grub.cfg. Try to detect this situation and substitute the real grub configuration file instead. Reported-by: Robert Knipp, Fabian Deutsch Thanks: Nijin Ashok, Marta Lewandowska Fixes: https://issues.redhat.com/browse/RHEL-77989 Related: https://issues.redhat.com/browse/RHEL-32099 Related: https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
This is no longer used in any libguestfs project, and I don't foresee if ever being needed again in the future. Signed-off-by: Cole Robinson <crobinso@redhat.com>
…fo-drivers Remove use of libosinfo `drivers` metadata
Turns out that the fixes I made (for libguestfs) were not actually being run as this directory is not used by libguestfs. Hence predictably the fixes were not complete. Fixes: commit 14531a8
Valgrind was complaining about a memory leak in this function. From looking at similar code in libosinfo itself, it appears we ought to be unrefing a lot more references here. This error started happening after the new 'test-phony-win2k25.sh' was added, but it seems to be unrelated to the test itself and must have been a pre-existing problem that was exposed by the test. ==2959521== ==2959521== HEAP SUMMARY: ==2959521== in use at exit: 43,662,865 bytes in 1,194,159 blocks ==2959521== total heap usage: 3,898,497 allocs, 2,704,338 frees, 2,609,865,939 bytes allocated ==2959521== ==2959521== 353 (40 direct, 313 indirect) bytes in 1 blocks are definitely lost in loss record 2,661 of 3,422 ==2959521== at 0x52BFAEC: g_type_create_instance (gtype.c:1929) ==2959521== by 0x52A48B3: g_object_new_internal.part.0 (gobject.c:2606) ==2959521== by 0x52A5EFD: g_object_new_with_properties (gobject.c:2603) ==2959521== by 0x52A6F30: g_object_new (gobject.c:2415) ==2959521== by 0x121A52: v2v_osinfo_os_find_os_by_short_id (libosinfo-c.c:166) ==2959521== by 0x2DEE12: caml_c_call (in /home/rjones/d/virt-v2v/v2v/virt-v2v) ==2959521== by 0x6F4D7BF: ??? ==2959521== by 0x6F5543F: ??? ==2959521== ==2959521== LEAK SUMMARY: ==2959521== definitely lost: 40 bytes in 1 blocks ==2959521== indirectly lost: 87 bytes in 5 blocks ==2959521== possibly lost: 0 bytes in 0 blocks ==2959521== still reachable: 1,976,140 bytes in 98 blocks ==2959521== suppressed: 35,544,294 bytes in 1,133,259 blocks ==2959521== Reachable blocks (those to which a pointer was found) are not shown. ==2959521== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==2959521== ==2959521== For lists of detected and suppressed errors, rerun with: -s ==2959521== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 10 from 10) Thanks: Pavel Hrdina, Daniel Berrange
This is wrong as the declaration of the two objects uses g_autoptr, so they are freed already. This doesn't explain why valgrind was complaining before. This reverts commit 5972144.
Pairing the vio10 and q35 supports checks is a bit awkward. Break these apart into simpler functions. This will require a patch on v2v side as well Signed-off-by: Cole Robinson <crobinso@redhat.com>
mltools: decouple and simplify osinfo device support checks
The implementation for this was previously removed in commit 7528d4d Make it explicitly throw an error, and remove the docs Signed-off-by: Cole Robinson <crobinso@redhat.com>
mlcustomize: disable `--inject-virtio-win osinfo`
This failed in valgrind with the memory leak below: ==1227361== 353 (40 direct, 313 indirect) bytes in 1 blocks are definitely lost in loss record 2,664 of 3,425 ==1227361== at 0x52C0AEC: g_type_create_instance (gtype.c:1929) ==1227361== by 0x52A58B3: g_object_new_internal.part.0 (gobject.c:2606) ==1227361== by 0x52A6EFD: g_object_new_with_properties (gobject.c:2603) ==1227361== by 0x52A7F30: g_object_new (gobject.c:2415) ==1227361== by 0x121932: v2v_osinfo_os_find_os_by_short_id (libosinfo-c.c:166) ==1227361== by 0x2DEE92: caml_c_call (in /home/rjones/d/virt-v2v/v2v/virt-v2v) ==1227361== by 0x6F4E80F: ??? ==1227361== by 0x6F5648F: ??? Cole Robinson worked out what is happening here. My copy of libosinfo contains no information about Windows 2025, thus searching for short-id win2k25 returns no matches and throws a Not_found exception. However exceptions in OCaml C code are basically longjmp, but written in assembly and invisible to the compiler: https://github.com/ocaml/ocaml/blob/d03434b711135a88883c558176a04effce4de3a1/runtime/amd64.S#L229-L235 This means they *do not* run any attribute((cleanup)) handlers, eg. for g_autoptr. Hence the g_autoptr locals in this function are leaked. We didn't realise until this point that OCaml exceptions and attribute((cleanup)) are incompatible. This may affect other code in libguestfs. The simple fix for this is to change the function so that it doesn't throw exceptions on the happy path. Instead we return Some os | None. Thanks: Cole Robinson
It's the opposite of String.explode!
$ git ls-files | xargs codespell
OCaml 5.3 added these functions at long last. However the function in 5.3 is slightly incompatible with ours as it will raise an exception if the n parameter is negative (ours returned an empty list). To avoid surprises modify our functions to match OCaml. List.take is used in guestfs-tools drivers/hwdata.ml, but the use does not depend on n being negative. List.drop is not used anywhere.
OCaml 5.3 added these functions at long last, but with slightly different names. Rename our functions to match. List.dropwhile is used in libguestfs and virt-v2v. List.takewhile is not used.
It returns the last element in a list, very inefficiently of course.
We wish to use List functions in the String module, which requires List to be defined first. No change, just code movement.
This pair of functions both return the longest common prefix. String.common_prefix returns the longest common prefix of two strings. String.longest_common_prefix returns the same for a list of strings.
OCaml >= 4.08 provides 'Fun.id' so we do not need to define this ourselves.
OCaml >= 4.08 provides 'Fun.protect' which is mostly compatible, so remove our definition.
In OCaml >= 4.08 this is now provided in the standard List module.
Fixes the following harmless warnings: Warning 58 [no-cmx-file]: no cmx file was found in path for module GettextCompat, and its interface was not compiled with -opaque Warning 58 [no-cmx-file]: no cmx file was found in path for module Gettext, and its interface was not compiled with -opaque
…_with In OCaml >= 4.13 we got standardized functions to test the prefix and suffix of a string, but using different names and parameter ordering. Use the standard functions instead of our own names.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.