[Libguestfs] [PATCH] make-fs: print error message on mkfs failure
This makes a bit easier to diagnose failures on mkfs, without the need
to restart the filesystem creation with verbose output (which will
produce a lot more output).
---
make-fs/make-fs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/make-fs/make-fs.c b/make-fs/make-fs.c
index ff291a1..561c6ae 100644
--- a/make-fs/make-fs.c
+++ b/make-fs/make-fs.c
@@ -773,8 +773,8 @@ do_make_fs (const char *input, const char *output_str)
if (r == -1) {
/* Provide more guidance in the error message (RHBZ#823883). */
- fprintf (stderr, "%s: 'mkfs' (create filesystem) operation failed.\n",
- guestfs_int_program_name);
+ fprintf (stderr, "%s: 'mkfs' (create filesystem) operation failed: %s\n",
+ guestfs_int_program_name, guestfs_last_error (g));
if (STREQ (type, "fat"))
fprintf (stderr, "Instead of 'fat', try 'vfat' (long filenames) or
'msdos' (short filenames).\n");
else
--
2.5.0
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
[Libguestfs] [PATCH] daemon: ntfs: fix format strings
Use PRIi64 as format string for int64_t, so it builds and works fine
also on 32bit. Also switch from asprintf_nowarn to asprintf, since no
custom formats (eg %Q, %R) are used.
---
daemon/ntfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/daemon/ntfs.c b/daemon/ntfs.c
index 92088f7..e555c63 100644
--- a/daemon/ntfs.c
+++ b/daemon/ntfs.c
@@ -282,8 +282,8 @@ do_ntfscat_i (const mountable_t *mountable, int64_t inode)
}
/* Construct the command. */
- if (asprintf_nowarn (&cmd, "ntfscat -i %ld %s",
- inode, mountable->device) == -1) {
+ if (asprintf (&cmd, "ntfscat -i %" PRIi64 " %s",
+inode, mountable->device) == -1) {
reply_with_perror ("asprintf");
return -1;
}
@@ -311,14 +311,14 @@ do_ntfscat_i (const mountable_t *mountable, int64_t inode)
}
if (ferror (fp)) {
-fprintf (stderr, "fread: %ld: %m\n", inode);
+fprintf (stderr, "fread: %" PRIi64 ": %m\n", inode);
send_file_end (1); /* Cancel. */
pclose (fp);
return -1;
}
if (pclose (fp) != 0) {
-fprintf (stderr, "pclose: %ld: %m\n", inode);
+fprintf (stderr, "pclose: %" PRIi64 ": %m\n", inode);
send_file_end (1); /* Cancel. */
return -1;
}
--
2.5.0
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH] make-fs: print error message on mkfs failure
On Wed, Mar 02, 2016 at 11:05:19AM +0100, Pino Toscano wrote:
> This makes a bit easier to diagnose failures on mkfs, without the need
> to restart the filesystem creation with verbose output (which will
> produce a lot more output).
> ---
> make-fs/make-fs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/make-fs/make-fs.c b/make-fs/make-fs.c
> index ff291a1..561c6ae 100644
> --- a/make-fs/make-fs.c
> +++ b/make-fs/make-fs.c
> @@ -773,8 +773,8 @@ do_make_fs (const char *input, const char *output_str)
>
> if (r == -1) {
>/* Provide more guidance in the error message (RHBZ#823883). */
> - fprintf (stderr, "%s: 'mkfs' (create filesystem) operation failed.\n",
> - guestfs_int_program_name);
> + fprintf (stderr, "%s: 'mkfs' (create filesystem) operation failed:
> %s\n",
> + guestfs_int_program_name, guestfs_last_error (g));
>if (STREQ (type, "fat"))
> fprintf (stderr, "Instead of 'fat', try 'vfat' (long filenames) or
> 'msdos' (short filenames).\n");
>else
ACK this patch and the previous patch.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
[Libguestfs] signature file is missing for libguestfs-1.32.3.tar.gz
There is no sig file for v1.32.3 in http://libguestfs.org/download/1.32-stable/ Nikos ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
[Libguestfs] [PATCH] daemon: do not fail list-disk-labels w/o labels set
If there are no labels set for the disks, the directory with the
symlinks will not even exists, causing list-disk-labels to fail with
ENOENT. In this situation, act as if the directory was there, but
empty.
---
daemon/devsparts.c | 7 +++
generator/actions.ml | 12
2 files changed, 19 insertions(+)
diff --git a/daemon/devsparts.c b/daemon/devsparts.c
index 7b92bf6..7c690f8 100644
--- a/daemon/devsparts.c
+++ b/daemon/devsparts.c
@@ -316,6 +316,13 @@ do_list_disk_labels (void)
dir = opendir (GUESTFSDIR);
if (!dir) {
+if (errno == ENOENT) {
+ /* The directory does not exist, and usually this happens when
+ * there are no labels set. In this case, act as if the directory
+ * was empty.
+ */
+ return empty_list ();
+}
reply_with_perror ("opendir: %s", GUESTFSDIR);
return NULL;
}
diff --git a/generator/actions.ml b/generator/actions.ml
index 9c34463..287d7f5 100644
--- a/generator/actions.ml
+++ b/generator/actions.ml
@@ -11336,6 +11336,18 @@ silently create an ext2 filesystem instead." };
name = "list_disk_labels"; added = (1, 19, 49);
style = RHashtable "labels", [], [];
proc_nr = Some 369;
+tests = [
+ (* The test disks have no labels, so we can be sure there are
+ * no labels. See in tests/disk-labels/ for tests checking
+ * for actual disk labels.
+ *
+ * Also, we make use of the assumption that RHashtable is a
+ * char*[] in C, so an empty hash has just a NULL element.
+ *)
+ InitScratchFS, Always, TestResult (
+[["list_disk_labels"]],
+"is_string_list (ret, 0)"), [];
+];
shortdesc = "mapping of disk labels to devices";
longdesc = "\
If you add drives using the optional C parameter
--
2.5.0
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
[Libguestfs] [libguestfs] Libguestfs as filesystem forensic tool
Greetings, I am playing around with the idea of using libguestfs as a forensic tool to investigate VM disk images. Some use cases as example: * Sandbox for malware analysis. * Incident response in cloud environments. Libguestfs is a precious resource in this case as it allows to abstract the disk image internals and expose them as mountable devices. Combined with some state of the art tool such as The Sleuth Kit it would turn it into a pretty powerful forensic tool. http://www.sleuthkit.org/ I played around with some proof-of-concept and the idea seems to work. The question I'd like to ask is if this feature would interest the libguestfs community or if I shall fork the project (libguestforensic?) and, if so, what is the preferable way to do it. Thank you. ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] signature file is missing for libguestfs-1.32.3.tar.gz
On Wed, Mar 02, 2016 at 02:30:42PM +0200, Nikos Skalkotos wrote: > There is no sig file for v1.32.3 in > http://libguestfs.org/download/1.32-stable/ I've signed it now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [PATCH] daemon: do not fail list-disk-labels w/o labels set
On Wed, Mar 02, 2016 at 02:45:04PM +0100, Pino Toscano wrote:
> If there are no labels set for the disks, the directory with the
> symlinks will not even exists, causing list-disk-labels to fail with
> ENOENT. In this situation, act as if the directory was there, but
> empty.
> ---
> daemon/devsparts.c | 7 +++
> generator/actions.ml | 12
> 2 files changed, 19 insertions(+)
>
> diff --git a/daemon/devsparts.c b/daemon/devsparts.c
> index 7b92bf6..7c690f8 100644
> --- a/daemon/devsparts.c
> +++ b/daemon/devsparts.c
> @@ -316,6 +316,13 @@ do_list_disk_labels (void)
>
>dir = opendir (GUESTFSDIR);
>if (!dir) {
> +if (errno == ENOENT) {
> + /* The directory does not exist, and usually this happens when
> + * there are no labels set. In this case, act as if the directory
> + * was empty.
> + */
> + return empty_list ();
> +}
> reply_with_perror ("opendir: %s", GUESTFSDIR);
> return NULL;
>}
> diff --git a/generator/actions.ml b/generator/actions.ml
> index 9c34463..287d7f5 100644
> --- a/generator/actions.ml
> +++ b/generator/actions.ml
> @@ -11336,6 +11336,18 @@ silently create an ext2 filesystem instead." };
> name = "list_disk_labels"; added = (1, 19, 49);
> style = RHashtable "labels", [], [];
> proc_nr = Some 369;
> +tests = [
> + (* The test disks have no labels, so we can be sure there are
> + * no labels. See in tests/disk-labels/ for tests checking
> + * for actual disk labels.
> + *
> + * Also, we make use of the assumption that RHashtable is a
> + * char*[] in C, so an empty hash has just a NULL element.
> + *)
> + InitScratchFS, Always, TestResult (
> +[["list_disk_labels"]],
> +"is_string_list (ret, 0)"), [];
> +];
> shortdesc = "mapping of disk labels to devices";
> longdesc = "\
> If you add drives using the optional C parameter
> --
ACK.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] [libguestfs] Libguestfs as filesystem forensic tool
On Wed, Mar 02, 2016 at 05:47:40PM +0200, noxdafox wrote: > Greetings, > > I am playing around with the idea of using libguestfs as a forensic > tool to investigate VM disk images. > > Some use cases as example: > * Sandbox for malware analysis. > * Incident response in cloud environments. > > Libguestfs is a precious resource in this case as it allows to > abstract the disk image internals and expose them as mountable > devices. > > Combined with some state of the art tool such as The Sleuth Kit it > would turn it into a pretty powerful forensic tool. > http://www.sleuthkit.org/ > > I played around with some proof-of-concept and the idea seems to work. > > The question I'd like to ask is if this feature would interest the > libguestfs community or if I shall fork the project > (libguestforensic?) and, if so, what is the preferable way to do it. Actually I believe parts of libguestfs (and especially hivex) are already used in this way. Anyhow you're free to fork libguestfs provided you obey the license. It may be easier/less work if you submit patches upstream where they make sense for the upstream project, such as generally useful APIs (like the ntfscat-i API). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Libguestfs as filesystem forensic tool
On 02/03/16 17:53, Richard W.M. Jones wrote: On Wed, Mar 02, 2016 at 05:47:40PM +0200, noxdafox wrote: Greetings, I am playing around with the idea of using libguestfs as a forensic tool to investigate VM disk images. Some use cases as example: * Sandbox for malware analysis. * Incident response in cloud environments. Libguestfs is a precious resource in this case as it allows to abstract the disk image internals and expose them as mountable devices. Combined with some state of the art tool such as The Sleuth Kit it would turn it into a pretty powerful forensic tool. http://www.sleuthkit.org/ I played around with some proof-of-concept and the idea seems to work. The question I'd like to ask is if this feature would interest the libguestfs community or if I shall fork the project (libguestforensic?) and, if so, what is the preferable way to do it. Actually I believe parts of libguestfs (and especially hivex) are already used in this way. Anyhow you're free to fork libguestfs provided you obey the license. It may be easier/less work if you submit patches upstream where they make sense for the upstream project, such as generally useful APIs (like the ntfscat-i API). One of the patches I'm talking about would add TSK (The Sleuth Kit) as a dependency within the appliance. This would bring new APIs such as: 'fls' more powerful 'ls' command allowing to get list of deleted files or timelines at a given path. 'icat' similar to ntfscat-i but it supports multiple FS. Yet I'm not sure whether it's desirable as it is for a narrow use case and on my Debian box TSK is a 12Mb binary. Rich. ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Libguestfs as filesystem forensic tool
On Wed, Mar 02, 2016 at 05:59:32PM +0200, noxdafox wrote: > One of the patches I'm talking about would add TSK (The Sleuth Kit) > as a dependency within the appliance. > > This would bring new APIs such as: > 'fls' more powerful 'ls' command allowing to get list of deleted > files or timelines at a given path. > 'icat' similar to ntfscat-i but it supports multiple FS. > > Yet I'm not sure whether it's desirable as it is for a narrow use > case and on my Debian box TSK is a 12Mb binary. Yes that's a rather large dependency. However it's possible to use optgroups ["optional" field in generator/actions.ml] and subpackaging to mean that end users don't need to install this dependency unless they want it. Would need to see the patches before really deciding. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Libguestfs as filesystem forensic tool
On 02/03/16 18:24, Richard W.M. Jones wrote: On Wed, Mar 02, 2016 at 05:59:32PM +0200, noxdafox wrote: One of the patches I'm talking about would add TSK (The Sleuth Kit) as a dependency within the appliance. This would bring new APIs such as: 'fls' more powerful 'ls' command allowing to get list of deleted files or timelines at a given path. 'icat' similar to ntfscat-i but it supports multiple FS. Yet I'm not sure whether it's desirable as it is for a narrow use case and on my Debian box TSK is a 12Mb binary. Yes that's a rather large dependency. However it's possible to use optgroups ["optional" field in generator/actions.ml] and subpackaging to mean that end users don't need to install this dependency unless they want it. If I understood correctly, I just need to set the optional field in the API and then issue the command: "./configure --with-extra-packages=... " right? Would need to see the patches before really deciding. Rich. ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] Libguestfs as filesystem forensic tool
On Wed, Mar 02, 2016 at 11:26:08PM +0200, noxdafox wrote: > > > On 02/03/16 18:24, Richard W.M. Jones wrote: > >On Wed, Mar 02, 2016 at 05:59:32PM +0200, noxdafox wrote: > >>One of the patches I'm talking about would add TSK (The Sleuth Kit) > >>as a dependency within the appliance. > >> > >>This would bring new APIs such as: > >> 'fls' more powerful 'ls' command allowing to get list of deleted > >>files or timelines at a given path. > >> 'icat' similar to ntfscat-i but it supports multiple FS. > >> > >>Yet I'm not sure whether it's desirable as it is for a narrow use > >>case and on my Debian box TSK is a 12Mb binary. > >Yes that's a rather large dependency. > > > >However it's possible to use optgroups ["optional" field in > >generator/actions.ml] and subpackaging to mean that end users don't > >need to install this dependency unless they want it. > If I understood correctly, I just need to set the optional field in > the API and then issue the command: "./configure > --with-extra-packages=... " right? Actually even easier than that. Just add the TSK package name to `appliance/packagelist.in'. However you should also use the optional field in `generator/actions.ml' for your new API(s) because it allows callers to query whether the feature is available (using the guestfs_feature_available API). When you use the optional field, you will also need to write a function in the daemon called optgroup__available. See `daemon/ntfs.c' for an example. Note the package name and optional field name don't need to be the same. Also there is not necessarily a 1-1 mapping: it may make sense to have several optgroups, or may not. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Re: [Libguestfs] "guestmount --rw" fails but "guestmount --ro" succeeds on Ubuntu 14.04
Thanks for your response Rich. Please see the output of --trace --verbose below. Regarding your suggestion to convert the vmdk to some other format, I do not want to do it. A security consultant said by modifying certain files in our VM and restarting the VM, one can gain access to encrypted data in our VM. I want to reproduce it. I am able to mount the VM but not able to modify files since it can be mounted with --ro option only. :~$ guestmount --trace --verbose --rw -a agent-disk1.vmdk -i /mnt/vmdk libguestfs: trace: set_verbose true libguestfs: trace: set_verbose = 0 libguestfs: trace: set_recovery_proc true libguestfs: trace: set_recovery_proc = 0 libguestfs: trace: add_drive "agent-disk1.vmdk" libguestfs: trace: add_drive = 0 libguestfs: trace: launch libguestfs: trace: get_tmpdir libguestfs: trace: get_tmpdir = "/tmp" libguestfs: trace: version libguestfs: trace: version = libguestfs: trace: get_backend libguestfs: trace: get_backend = "direct" libguestfs: launch: program=guestmount libguestfs: launch: version=1.24.5 libguestfs: launch: backend registered: unix libguestfs: launch: backend registered: uml libguestfs: launch: backend registered: libvirt libguestfs: launch: backend registered: direct libguestfs: launch: backend=direct libguestfs: launch: tmpdir=/tmp/libguestfsanpm0b libguestfs: launch: umask=0002 libguestfs: launch: euid=1000 libguestfs: command: run: /usr/bin/supermin-helper libguestfs: command: run: \ --verbose libguestfs: command: run: \ -f checksum libguestfs: command: run: \ --host-cpu x86_64 libguestfs: command: run: \ /usr/lib/guestfs/supermin.d supermin helper [0ms] whitelist = (not specified) supermin helper [0ms] host_cpu = x86_64 supermin helper [0ms] dtb_wildcard = (not specified) supermin helper [0ms] inputs: supermin helper [0ms] inputs[0] = /usr/lib/guestfs/supermin.d supermin helper [0ms] outputs: supermin helper [0ms] kernel = (none) supermin helper [0ms] dtb = (none) supermin helper [0ms] initrd = (none) supermin helper [0ms] appliance = (none) checking modpath /lib/modules/3.13.0-74-generic is a directory picked kernel vmlinuz-3.13.0-74-generic supermin helper [0ms] finished creating kernel supermin helper [0ms] visiting /usr/lib/guestfs/supermin.d supermin helper [1ms] visiting /usr/lib/guestfs/supermin.d/base.img supermin helper [3ms] visiting /usr/lib/guestfs/supermin.d/daemon.img.gz supermin helper [3ms] visiting /usr/lib/guestfs/supermin.d/hostfiles supermin helper [00199ms] visiting /usr/lib/guestfs/supermin.d/init.img supermin helper [00200ms] visiting /usr/lib/guestfs/supermin.d/udev-rules.img supermin helper [00201ms] adding kernel modules supermin helper [00667ms] finished creating appliance libguestfs: checksum of existing appliance: c15e020bda105b5ca562616e2edac3c65917bbbd9fb9954efe3d92e697a583a1 libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" libguestfs: trace: get_cachedir libguestfs: trace: get_cachedir = "/var/tmp" libguestfs: [00675ms] begin building supermin appliance libguestfs: [00675ms] run supermin-helper libguestfs: command: run: /usr/bin/supermin-helper libguestfs: command: run: \ --verbose libguestfs: command: run: \ --copy-kernel libguestfs: command: run: \ -f ext2 libguestfs: command: run: \ --host-cpu x86_64 libguestfs: command: run: \ /usr/lib/guestfs/supermin.d libguestfs: command: run: \ --output-kernel /var/tmp/guestfs.l3Pqvn/kernel libguestfs: command: run: \ --output-initrd /var/tmp/guestfs.l3Pqvn/initrd libguestfs: command: run: \ --output-appliance /var/tmp/guestfs.l3Pqvn/root supermin helper [0ms] whitelist = (not specified) supermin helper [0ms] host_cpu = x86_64 supermin helper [0ms] dtb_wildcard = (not specified) supermin helper [0ms] inputs: supermin helper [0ms] inputs[0] = /usr/lib/guestfs/supermin.d supermin helper [0ms] outputs: supermin helper [0ms] kernel = /var/tmp/guestfs.l3Pqvn/kernel supermin helper [0ms] dtb = (none) supermin helper [0ms] initrd = /var/tmp/guestfs.l3Pqvn/initrd supermin helper [0ms] appliance = /var/tmp/guestfs.l3Pqvn/root checking modpath /lib/modules/3.13.0-74-generic is a directory picked kernel vmlinuz-3.13.0-74-generic supermin helper [00048ms] finished creating kernel supermin helper [00842ms] finished mke2fs supermin helper [00842ms] visiting /usr/lib/guestfs/supermin.d supermin helper [00842ms] visiting /usr/lib/guestfs/supermin.d/base.img supermin helper [00878ms] visiting /usr/lib/guestfs/supermin.d/daemon.img.gz supermin helper [00915ms] visiting /usr/lib/guestfs/supermin.d/hostfiles supermin helper [03725ms] visiting /usr/lib/guestfs/supermin.d/init.img supermin helper [03725ms] visiting /usr/lib/guestfs/supermin.d/udev-rules.img supermin helper [03725ms] adding kernel modules supermin helper [07480ms] closing ext2 filesystem supermin helper [07481ms] finished creating appliance libguestfs: [08157ms] finished building supermin appliance libguestfs: command: ru
