openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #12215
Re: [Nova] Getting error when injecting data into an image
you can try to check permissions on this file .
and ... do you have selinux enabled on this machine ?
On Thu, May 24, 2012 at 4:26 PM, Patrick Petit <
patrick.michel.petit@xxxxxxxxx> wrote:
> Hi Pádraig,
>
> Thank you for your reply.
>
> I am not running
> http://repos.fedorapeople.org/repos/apevec/openstack-preview/fedora-16/
>
> but
>
>
> http://repos.fedorapeople.org/repos/apevec/openstack-preview/fedora-openstack-preview.repo
>
> Which is supposed to work for both Fedora 16 & 17
>
> Anyhow, I applied the suggested libvirt_inject_partition = -1 patch.
>
> It does change things because it's not complaining about mount error any
> more but generates further errors down the path in libvirt.py", line 540
> followed by AMQP errors as traced below.
>
> Thanks
> Patrick
>
>
> 2012-05-24 14:11:02 INFO nova.virt.libvirt.connection
> [req-8b7dbdb7-5771-446a-8cf6-0bcb8833d79f 5677a018b8924cc58f993101c3024794
> 873855379940442797e53f2fa437893f] [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] Injecting key into image
> 661bbe35-ebe5-4614-bdb2-3259ea507934
> 2012-05-24 14:11:54 ERROR nova.compute.manager
> [req-8b7dbdb7-5771-446a-8cf6-0bcb8833d79f 5677a018b8924cc58f993101c3024794
> 873855379940442797e53f2fa437893f] [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] Instance failed to spawn
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] Traceback (most recent call last):
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 598, in
> _spawn
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31]
> self._legacy_nw_info(network_info), block_device_info)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/nova/exception.py", line 114, in wrapped
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] return f(*args, **kw)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/connection.py", line
> 930, in spawn
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] self._create_new_domain(xml)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/connection.py", line
> 1597, in _create_new_domain
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31]
> domain.createWithFlags(launch_flags)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 187, in doit
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] result =
> proxy_call(self._autowrap, f, *args, **kwargs)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 147, in
> proxy_call
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] rv = execute(f,*args,**kwargs)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib/python2.7/site-packages/eventlet/tpool.py", line 76, in tworker
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] rv = meth(*args,**kwargs)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] File
> "/usr/lib64/python2.7/site-packages/libvirt.py", line 540, in
> createWithFlags
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] if ret == -1: raise libvirtError
> ('virDomainCreateWithFlags() failed', dom=self)
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] libvirtError: internal error Process
> exited while reading console log output: char device redirected to
> /dev/pts/2
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31] Could not allocate dynamic translator
> buffer
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31]
> 2012-05-24 14:11:54 TRACE nova.compute.manager [instance:
> a5d5b5c7-093a-4eb4-9d70-d6cfa2b30a31]
> 2012-05-24 14:11:54 ERROR nova.rpc.amqp
> [req-8b7dbdb7-5771-446a-8cf6-0bcb8833d79f 5677a018b8924cc58f993101c3024794
> 873855379940442797e53f2fa437893f] Exception during message handling
> 2012-05-24 14:11:54 TRACE nova.rpc.amqp Traceback (most recent call last):
> 2012-05-24 14:11:54 TRACE nova.rpc.amqp File
> "/usr/lib/python2.7/site-packages/nova/rpc/amqp.py", line 253, in
> _process_data
> 2012-05-24 14:11:54 TRACE nova.rpc.amqp rval = node_func(context=ctxt,
> **node_args)
> 2012-05-24 14:11:54 TRACE nova.rpc.amqp File
> "/usr/lib/python2.7/site-packages/nova/exception.py", line 114, in wrapped
> 2012-05-24 14:11:54 TRACE nova.rpc.amqp return f(*args, **kw)
>
>
>
>
> Best regards,
> Patrick
>
>
> 2012/5/24 Pádraig Brady <P@xxxxxxxxxxxxxx>
>
>> On 05/24/2012 11:38 AM, Patrick Petit wrote:
>> > Hi,
>> > I am getting the following error when running
>> >
>> > $ nova boot myserver --flavor 2 --key_name mykey --image
>> 661bbe35-ebe5-4614-bdb2-3259ea507934
>> >
>> >
>> +-------------------------------------+--------------------------------------+
>> > | Property | Value
>> |
>> >
>> +-------------------------------------+--------------------------------------+
>> > | OS-DCF:diskConfig | MANUAL
>> |
>> > | OS-EXT-SRV-ATTR:host | None
>> |
>> > | OS-EXT-SRV-ATTR:hypervisor_hostname | None
>> |
>> > | OS-EXT-SRV-ATTR:instance_name | instance-00000005
>> |
>> > | OS-EXT-STS:power_state | 0
>> |
>> > | OS-EXT-STS:task_state | scheduling
>> |
>> > | OS-EXT-STS:vm_state | building
>> |
>> > | accessIPv4 |
>> |
>> > | accessIPv6 |
>> |
>> > | adminPass | mAnfCStaqWT2
>> |
>> > | config_drive |
>> |
>> > | created | 2012-05-23T13:49:12Z
>> |
>> > | flavor | m1.small
>> |
>> > | hostId |
>> |
>> > | id |
>> 18cde301-e8c9-4721-928b-cd0daf63a4f0 |
>> > | image | f16-jeos
>> |
>> > | key_name | mykey
>> |
>> > | metadata | {}
>> |
>> > | name | myserver
>> |
>> > | progress | 0
>> |
>> > | status | BUILD
>> |
>> > | tenant_id |
>> 873855379940442797e53f2fa437893f |
>> > | updated | 2012-05-23T13:49:13Z
>> |
>> > | user_id |
>> 5677a018b8924cc58f993101c3024794 |
>> >
>> +-------------------------------------+--------------------------------------+
>> >
>> >
>> > The image was obtained from following the Getting Started with
>> OpenStack on Fedora 17 tutorial (
>> http://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17).
>> So, I guess I am not the only one using it.
>> >
>> > $ glance index
>> >
>> > ID Name
>> Disk Format Container Format Size
>> >
>> > ------------------------------------ ------------------------------
>> -------------------- -------------------- --------------
>> >
>> > 661bbe35-ebe5-4614-bdb2-3259ea507934 f16-jeos
>> qcow2 ovf 213581824
>> >
>> > c15e90f2-e73e-4987-ad7a-11d87403012e cirros-0.3.0-x86_64-ari ari
>> ari 2254249
>> >
>> > 68ad4ece-6a56-4ac8-b112-1dd69283ea83 cirros-0.3.0-x86_64-ami ami
>> ami 25165824
>> >
>> > 6f5d8022-2dfe-406d-b391-fa0e48c175f3 cirros-0.3.0-x86_64-aki aki
>> aki 4731440
>> >
>> >
>> > This is running on Nova Essex on Fedora 16.
>> > After a while I get:
>> >
>> > $ nova list
>> >
>> >
>> +--------------------------------------+----------+--------+------------------+
>> > | ID | Name | Status |
>> Networks |
>> >
>> +--------------------------------------+----------+--------+------------------+
>> > | 18cde301-e8c9-4721-928b-cd0daf63a4f0 | myserver | ERROR |
>> demonet=10.0.0.2 |
>> >
>> +--------------------------------------+----------+--------+------------------+
>> >
>> >
>> > And so the log:
>> >
>> > 2012-05-23 15:50:12 INFO nova.virt.libvirt.connection [-]
>> Compute_service record updated for fedora.localdomain
>> >
>> > 2012-05-23 15:50:35 WARNING nova.virt.libvirt.connection
>> [req-dd9a661c-94d3-42e4-b7ba-699c7b41def4 5677a018b8924cc58f993101c3024794
>> 873855379940442797e53f2fa437893f] [instance:
>> 18cde301-e8c9-4721-928b-cd0daf63a4f0] Ignoring error injecting data into
>> image 661bbe35-ebe5-4614-bdb2-3259ea507934 (
>> >
>> > --
>> >
>> > Failed to mount filesystem: Unexpected error while running command.
>> >
>> > Command: sudo nova-rootwrap mount /dev/mapper/nbd15p1 /tmp/tmpM9dOLC
>> >
>> > Exit code: 32
>> >
>> > Stdout: ''
>> >
>> > Stderr: 'mount: you must specify the filesystem type\n'
>> >
>> > --
>> >
>> > Failed to mount filesystem: Unexpected error while running command.
>> >
>> > Command: sudo nova-rootwrap guestmount --rw -a
>> /var/lib/nova/instances/instance-00000005/disk -m /dev/sda1 /tmp/tmpM9dOLC
>> >
>> > Exit code: 1
>> >
>> > Stdout: ''
>> >
>> > Stderr: "libguestfs: error: mount_options: /dev/vda1 on /: mount: you
>> must specify the filesystem type\n/usr/bin/guestmount: '/dev/sda1' could
>> not be mounted. Did you mean one of these?\n\t/dev/sda1
>> (unknown)\n\t/dev/sda2 (ext4)\n")
>> >
>> >
>> > Note that I get the same error with other images, so it's not specific
>> to f16-jeos. I am confused by this error. If the nova-rootwrap had to
>> specify a filesystem type for the mount to succeed that would be a longtime
>> known bug and so fixed bug right? The default filesystem types seem to be
>> configured properly on the system...
>> >
>> > $ cat /etc/filesystems
>> > ext4
>> > ext3
>> > ext2
>> > nodev proc
>> > nodev devpts
>> > iso9660
>> > vfat
>> > hfs
>> > hfsplus
>> >
>> >
>> > Any help to sort that problem out would be greatly appreciated.
>>
>> So you're running Nova Essex on Fedora 16.
>> I presume that is from:
>> http://repos.fedorapeople.org/repos/apevec/openstack-preview/fedora-16/
>>
>> Those packages include a backport of this folsom feature:
>> https://github.com/openstack/nova/commit/2b3a1e7
>>
>> So that should allow you to set this in /etc/nova/nova.conf:
>>
>> libvirt_inject_partition = -1
>>
>> Then libguestfs should be able to inspect the
>> more complicated f16 jeos image.
>>
>> Note that feature isn't enabled by default due to
>> some incompatibilities with older libguestfs.
>> Though the default may be changed in future.
>>
>> Note also that the failed injection message is just a warning,
>> and that should not stop the image from booting.
>> I.E. you may well have another issue after fixing the injection one.
>>
>> cheers,
>> Pádraig.
>>
>
>
>
> --
> *"Give me a place to stand, and I shall move the earth with a lever"*
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
Follow ups
References
