similar to: [PATCH v2] daemon: inspect: better handling windows drive mapping.

I have several Windows disk images which contains strange registry entry for mapped drives: "\\DosDevices\\Y:"=hex(3):00,00,00,00,00,00,00,00,00,00,00,00 Which is decoded something like diskID = 0x0, partition starts at 0 bytes from the start of the disk. In addition of Windows disk image I have attached dummy disk and made xfs file system on a whole device without partitioning it. I

By creating an empty disk and using it as the first disk of the vm (i.e. /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the iteration order of the disks. This causes inspect_os() to fail since Parted returns a Unix_error if the device does not contain any partitions - fix this by handling this Unix_error. Signed-off-by: Sam Eiderman <sameid@google.com> ---

Yea, I noticed that commit, but since it was used in gpt too regardless of that commit, I decided not to mention this regression. I also noticed that list_filesystems() still works, this is probably due to filtering of devices (daemon/listfs.ml): "let devices = List.filter is_not_partitioned_device devices in" What do you have in mind here? On Tue, Jun 30, 2020 at 12:33 PM Pino

On Tuesday, 30 June 2020 10:33:40 CEST Sam Eiderman wrote: > By creating an empty disk and using it as the first disk of the vm (i.e. > /dev/sda, /dev/sdb{1,2} contains the windows fses) we change the > iteration order of the disks. > This causes inspect_os() to fail since Parted returns a Unix_error if > the device does not contain any partitions - fix this by handling this >

Mostly a line-for-line translation of the C inspection code. --- daemon/Makefile.am | 2 + daemon/inspect_fs.ml | 6 + daemon/inspect_fs_windows.ml | 491 ++++++++++++++++++++++++++++++++++++++++++ daemon/inspect_fs_windows.mli | 24 +++ 4 files changed, 523 insertions(+) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index a4657ed86..80314a524 100644 ---

No need to redeclare them again in few modules, just use them from the Structs module. --- daemon/btrfs.mli | 8 +------- daemon/inspect_fs_windows.ml | 4 ++-- daemon/listfs.ml | 4 ++-- daemon/parted.mli | 9 +-------- daemon/statvfs.mli | 16 +--------------- 5 files changed, 7 insertions(+), 34 deletions(-) diff --git a/daemon/btrfs.mli

No need to redeclare them again in few modules, just use them from the Structs module. --- daemon/btrfs.mli | 8 +------- daemon/inspect_fs_windows.ml | 4 ++-- daemon/listfs.ml | 4 ++-- daemon/parted.mli | 9 +-------- daemon/statvfs.mli | 16 +--------------- 5 files changed, 7 insertions(+), 34 deletions(-) diff --git a/daemon/btrfs.mli

Rely on currying, and avoid extra helper functions. No behaviour changes. --- daemon/inspect_fs_unix.ml | 20 ++++++++++---------- daemon/inspect_fs_windows.ml | 2 +- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/daemon/inspect_fs_unix.ml b/daemon/inspect_fs_unix.ml index 59e26a05e..3ad119306 100644 --- a/daemon/inspect_fs_unix.ml +++ b/daemon/inspect_fs_unix.ml @@ -68,7

From: "Richard W.M. Jones" <rjones at redhat.com> When a Windows guest doesn't have a HKLM\SYSTEM\MountedDevices node, inspection fails. However inspection should not completely fail just because we cannot get the drive letter mapping from a guest. --- src/inspect_fs_windows.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git

On Fri, Feb 05, 2016 at 12:15:32PM -0500, Dawid Zamirski wrote: > This patch updates the guestfs_inspect_get_drive_mappings API call to > also return drive letters for GPT paritions. Previously this worked > only for MBR partitions. This is achieved by matching the GPT partition > GUID with the info stored in the blob from > HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

pragma GCC diagnostic is a gcc 4.6+ feature, compilation fails with older compilers: inspect-fs-windows.c: In function 'map_registry_disk_blob': inspect-fs-windows.c:502: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:503: error: #pragma GCC diagnostic not allowed inside functions inspect-fs-windows.c:505: error: #pragma GCC diagnostic not allowed inside

On Fri, 2016-02-05 at 18:08 +0000, Richard W.M. Jones wrote: > On Fri, Feb 05, 2016 at 12:15:32PM -0500, Dawid Zamirski wrote: > > This patch updates the guestfs_inspect_get_drive_mappings API call > > to > > also return drive letters for GPT paritions. Previously this worked > > only for MBR partitions. This is achieved by matching the GPT > > partition > >

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

This patch series changes a small part of the library to use __attribute__((cleanup(...))) to automatically free memory when pointers go out of the current scope. In general terms this seems to be a small win although you do have to use it carefully. For functions where you can completely get rid of the "exit code paths", it can simplify things. For a good example, see the

This patch updates the guestfs_inspect_get_drive_mappings API call to also return drive letters for GPT paritions. Previously this worked only for MBR partitions. This is achieved by matching the GPT partition GUID with the info stored in the blob from HKLM\SYSTEM\MountedDevices\DosDevices keys. For GPT partions this blob contains a "DMIO:ID:" prefix followed by a 16 byte binary GUID.

Does SYSLINUX have any idea which DOS driveletter would be assigned to the disk it is booting from? At www.veder.com someone is trying to build a USB flash drive. However, FreeDOS does not seem to boot correctly from it (bootsector trouble maybe, or kernel itself is confusing drives), thus we're thinking of using Syslinux + Memdisk + bootimage, but somehow we want to be able to also access the

Hi, as a followup for the signature fix for mount_vfs [1], here it is a patch series to generate automatically most of the OCaml interfaces of daemon actions. Only the Lvm and Mount modules are left with hand-written interfaces. [1] https://www.redhat.com/archives/libguestfs/2018-April/msg00059.html Thanks, Pino Toscano (3): daemon: directly use Optgroups daemon: use the structs from the

This safe wrapper around Unix.openfile ensures that exceptions escaping cannot leave unclosed files. There are only a few places in the code where this wrapper can be used currently. There are other occurences of Unix.openfile but they are not suitable for replacement. --- common/mlstdutils/std_utils.ml | 4 ++++ common/mlstdutils/std_utils.mli | 6 ++++++ daemon/devsparts.ml | 5

This safe wrapper around Unix.openfile ensures that exceptions escaping cannot leave unclosed files. There are only a few places in the code where this wrapper can be used currently. There are other occurences of Unix.openfile but they are not suitable for replacement. --- common/mlstdutils/std_utils.ml | 4 ++++ common/mlstdutils/std_utils.mli | 6 ++++++ daemon/devsparts.ml |