With the current implementation, the root inode of the given partition
is ignored.
The root inode is now reported. Its name will be a single dot '.'
reproducing the TSK API.
Signed-off-by: Matteo Cafasso <noxdafox@gmail.com>
On Debian family of OSes Grub2 tools are prefixed with 'grub-', not with
'grub2-'. We have to detect the correct name of the tool to use it.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
When creating the XML for the new guest, always put the name of the pool
containing the disks, even when -os specified a pool UUID: libvirt does
not handle pool UUIDs for storage, but only names.
When running in verbose mode for debugging, run `glance --version` to
print the version of the glance client. This helps when dealing with
failures, or making its output actionable.
The glance client v1.0.0 defaults to the Image v2 API: this means that
an image can be referenced only by its UUID, and not anymore by the name
as well (which does not need to be unique). This caused our glance
invocation to set the properties for the newly created image to fail,
since we are using the name as identifier.
Instead of first creating the image and then setting all the properties
for it, set all the properties when creating the image: other than being
simpler, it also avoid parsing the output of the 'glance image-create'
command for the UUID ('id') of the image.
Create a new module [Linux_kernels] which does all kernel detection,
and also provides a place to define the kernel_info data structure.
This is essentially just code motion.
If the guest has no <Name> element in the OVF, previously we chose
"default" as the name. This changes that so it uses a name derived
from the basename of the OVA file instead.
For example:
virt-v2v -i ova /path/to/myguest.ova [...]
would use "myguest" as the name (assuming no <Name> was present).
Modifies the behaviour of
commit 1ae4252c93.
Upstream Perl is going to remove '.' from @INC (the include path for
modules) by default for the next major release (= 5.26) [1], as measure
to fix security issues. Debian already started backporting the fixes
for this [2], thus behaving this way in current Sid installations.
Since the affected Perl sources are only the local daemon testing
scripts, a simple fix is to force the 'requires' for the local
captive-daemon.pm module to start from the current directory: this way
there is no need to manually augment @INC, and only our local module is
loaded automatically.
[1] https://rt.perl.org/Public/Bug/Display.html?id=127810
[2] https://lists.debian.org/debian-devel-announce/2016/08/msg00013.html
Make use of the recently added 'getprogname' module in gnulib: replace
our guestfs_int_program_name with the getprogname() provided by the
module, since it does the same thing, and in a portable way.
As consequence of the above, use gnulib in a couple of tests that use
getprogname().
Since guestfs_int_program_name is gone, drop the configure checks
associated with it.
When running 'make maintainer-check-extra-dist', check also that all
generated files are included in the tarball. This is done so that end
users will not need OCaml to compile from tarball releases.
Previously we used an awkward hack to split up the large src/actions.c
into smaller files (which can benefit from being compiled in
parallel). This commit generalizes that code, so that we pass a
subsetted actions list to certain generator functions.
The output of the generator is identical after this commit and the
previous commit, except for the UUID encoded into tests/c-api/tests.c
since that is derived from the MD5 hash of generator/actions.ml.
This mostly mechanical change moves all of the libguestfs API
lists of functions into a struct in the Actions module.
It also adds filter functions to be used elsewhere to get
subsets of these functions.
Original code Replacement
all_functions actions
daemon_functions actions |> daemon_functions
non_daemon_functions actions |> non_daemon_functions
external_functions actions |> external_functions
internal_functions actions |> internal_functions
documented_functions actions |> documented_functions
fish_functions actions |> fish_functions
*_functions_sorted ... replacement as above ... |> sort
Commit ab2df2e659 attempted to rewrite
/etc/hosts if it contained the old hostname.
However this wasn't done reliably for a couple of reasons:
(1) Certain Debian/Ubuntu /etc/hostname contains
"localhost.localdomain" but still has "unassigned-hostname" or
"unassigned-hostname.unassigned-domain" in /etc/hosts.
(2) Even if (1) doesn't apply, you still need to split out the
hostname and domainname parts and deal with them separately.
Use /etc/os-release as first option, translating the distro name to the
current identifier used. The other options (the release files) are left
as following checks, avoiding them if any matches.
Don't remove the Processor and Intelppm nodes since that just breaks
the device driver.
The only remaining node being removed by the original code was
"rhelscsi" (the xenpv-win driver). I changed this so that instead of
deleting the whole node, it simply disables that driver. If you look
at RHBZ#737600, it's not even clear that deleting nodes was the right
fix for anything. I also renamed the function.
Reviewed-by: Roman Kagan <rkagan@virtuozzo.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
When put on new virtual hardware Windows will start driver installation
for newly discovered devices.
The problem is that it happens asynchronously and concurrently with
other activities, in particular, the firstboot scripts. This may result
in conflicts (because a firstboot script may want to install or
uninstall a driver, etc.) and eventually in the system left in
inconsistent state.
In order to prevent it, add another firstboot script which calls a
special utility, pnp_wait, whose sole purpose is to wait until all
PnP-related activities are finished. (It does so via a WinAPI call
which isn't available from a script so it has to be a compiled .exe.
The source code for it can be found in the corresponding directory in
https://github.com/rwmjones/rhsrvany). This firstboot script is put
first, so that other firstboot scripts do not have to worry about
interactions with PnP manager any more.
One caveat is that on Windows XP and Windows 2003 the PnP manager always
fires the "Found New Hardware" wizard, which doesn't allow PnP to make
any progress until the user closes it. As a result, this firstboot
script would never finish.
To work it around, follow the Microsoft KB
(https://support.microsoft.com/en-us/kb/938596) and set up a registry
key to make the the PnP manager not fire the wizard; the key is restored
to its initial state upon PnP completion. Unfortunately this only works
on systems having the mentioned update installed; otherwise the user
will have to interact with the UI.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
