Re: [Libguestfs] guestmount failing to mount a qcow image
On 12/08/2011 05:43 PM, Richard W.M. Jones wrote:
On Thu, Dec 08, 2011 at 04:49:08PM +0000, Pádraig Brady wrote:
> # guestmount --rw -a /tmp/disk -i /tmp/tmplFlBCc
> libguestfs: error: mount_options: mount_options_stub: /dev/root: No
> such file or directory
This image works OK with libguestfs 1.14/1.15. I suspect the commit
you need to make it work is:
commit 917f947590c92318fee2545ba88245d0de012e31
Author: Richard W.M. Jones <rjones(a)redhat.com>
Date: Fri Sep 16 15:26:20 2011 +0100
inspection: Handle /dev/root in /etc/fstab.
This means "the device that holds /etc/fstab", so map it correctly.
This fixes support for ttylinux and also some other guests that use
/dev/root instead of a real device name.
The bigger issue here for OpenStack is how to recover gracefully when
inspection fails. Even though guestmount -i doesn't work on the older
libguestfs, you could still have used explicit -m option(s).
Yep that works: `guestmount -a annoying.qcow2 -m /dev/sda mount_dir/`
The awkward thing about the failure mode is that it warns,
but returns EXIT_SUCCESS, leaving the dir "half mounted"
(and then fusermount -u gives an EBUSY error (hmm I might use -z))
I'm tempted to assume an error if there is any output to stderr.
You would have to know somehow which filesystem(s) are available and
which
you want to modify. That is information you can get from the API
(g.list_filesystems) or using virt-filesystems. It's reasonable, if
there is only one filesystem in the image, to just mount that one.
What's less clear is what should happen if there are multiple
filesystems: that information would have to be passed down from the
user through OpenStack.
There is a 'partition' variable passed through the api,
I guess it could be 0 = /dev/sda, 1..N = /dev/sdaN, -1 => -i
I'll sort something out.
cheers,
Pádraig.