Walrus unable to decrypt image for NC

Need more information to be able to reproduce your problem.

Which distro, version, bitness (32 or 64 bit), how did you install it?

What are the exact commands that can be used to reproduce the problem?

thanks.

I forgot, also please provide logfiles (cloud-output.log, cloud-error.log, cloud-debug.log).

Distro: Gentoo
Version: 1.6.2
Arch: 64 bit AMD
Install Method: Using source

I followed the instructions completely on the Install from Source page. I've tried Walrus on a separate machine, on a machine with the CLC, and on a machine with the CLC, SC, and CC and all 3 configs have the same problem.

cloud-error:
19:19:05 [WalrusImageManager:Bukkit.3] ERROR Tired of waiting to cache image: images/debian.5-0.x86-64.img.manifest.xml giving up
19:19:05 [JDBCTransaction:Bukkit.3] ERROR Could not toggle autocommit
java.sql.SQLException: Connection is closed
 at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
 at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
 at org.hsqldb.jdbc.jdbcConnection.checkClosed(Unknown Source)
 at org.hsqldb.jdbc.jdbcConnection.setAutoCommit(Unknown Source)
 at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.logicalcobwebs.proxool.ProxyConnection.invoke(ProxyConnection.java:68)
 at org.logicalcobwebs.cglib.proxy.Proxy$ProxyImpl$$EnhancerByCGLIB$$c44c04f4.setAutoCommit(<generated>)
 at org.hibernate.transaction.JDBCTransaction.toggleAutoCommit(JDBCTransaction.java:228)
 at org.hibernate.transaction.JDBCTransaction.rollbackAndResetAutoCommit(JDBCTransaction.java:220)
 at org.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:196)
 at org.hibernate.ejb.TransactionImpl.rollback(TransactionImpl.java:85)
 at com.eucalyptus.util.TxHandle.rollback(TxHandle.java:76)
 at com.eucalyptus.util.EntityWrapper.rollback(EntityWrapper.java:162)
 at edu.ucsb.eucalyptus.cloud.ws.WalrusImageManager.getDecryptedImage(WalrusImageManager.java:928)
 at edu.ucsb.eucalyptus.cloud.ws.WalrusControl.GetDecryptedImage(WalrusControl.java:372)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.mule.model.resolvers.AbstractEntryPointResolver.invokeMethod(AbstractEntryPointResolver.java:147)
 at org.mule.model.resolvers.ReflectionEntryPointResolver.invoke(ReflectionEntryPointResolver.java:127)
 at org.mule.model.resolvers.DefaultEntryPointResolverSet.invoke(DefaultEntryPointResolverSet.java:50)
 at org.mule.component.DefaultLifecycleAdapter.intercept(DefaultLifecycleAdapter.java:202)
 at org.mule.component.AbstractJavaComponent.invokeComponentInstance(AbstractJavaComponent.java:82)
 at org.mule.component.AbstractJavaComponent.doOnCall(AbstractJavaComponent.java:73)
 at org.mule.component.AbstractComponent.onCall(AbstractComponent.java:87)
 at org.mule.model.seda.SedaService$ComponentStageWorker.run(SedaService.java:533)
 at org.mule.work.WorkerContext.run(WorkerContext.java:310)
 at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
 at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
 at java.lang.Thread.run(Thread...

Don't see anything obviously wrong from the log snippet you posted. Complete logs (all 3) will definitely help.

Two questions,

-Was the image bundled with the correct credentials?

-What is the image cache size (admin web interface -> configuration tab) and are you sure you are not running out of image cache space? How many images have been registered so far?

Yes, it was bundled with the credentials I got from euca_conf
--get-credentials.

I've set that to 500GB. It was initially 30GB. I've only registered the
debian one available from the extras tab this time. Previously I'd
registered both the Debian and Ubuntu images and both got the same error. I
can use euca-download-bundle and get it that way just fine.

On Sat, Apr 17, 2010 at 3:23 PM, Neil Soman <email address hidden> wrote:

> Don't see anything obviously wrong from the log snippet you posted.
> Complete logs (all 3) will definitely help.
>
> Two questions,
>
> -Was the image bundled with the correct credentials?
>
> -What is the image cache size (admin web interface -> configuration tab)
> and are you sure you are not running out of image cache space? How many
> images have been registered so far?
>
> --
> Walrus unable to decrypt image for NC
> https://bugs.launchpad.net/bugs/565043
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Eucalyptus: New
>
> Bug description:
> I've uploaded a couple of the default images and tried to start instances,
> but it times out and ends up erroring out that it's unable to decrypt the
> image.
>
> Two files are created where it would be decrypting it in the bukkit:
> -rw-r--r-- 1 eucalyptus eucalyptus 10M Apr 16 16:28
> debian.5-0.x86-64.img-KTck4EQ..crypt.gz
> -rw-r--r-- 1 eucalyptus eucalyptus 10M Apr 16 16:28
> debian.5-0.x86-64.img-KTck4EQ..tgz
>
> These stay at 10M though and the md5sum doesn't match any other files for
> either.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/eucalyptus/+bug/565043/+subscribe
>

log files

Any insight from these log files?

I suspect this issue is triggered when a user downloads her credentials multiple times.

The workaround is to download a fresh sets of credentials, invalidate and remove all the previously uploaded (and registered images) and re-bundle, re-upload and re-register them.

This issue has been confirmed as fixed in our development code: leaving it open as confirmed for 2.0.

On 12-03-13 03:44 AM, graziano obertelli wrote:
> This issue has been confirmed as fixed in our development code: leaving
> it open as confirmed for 2.0.

Ahhh. Excellent news! It's been a while since I've used Eucalyptus but
should I end up using it again, I'd surely be glad this issue is
resolved. How far away is 2.0?

Cheers,
b.

Downgrading the priority, since, as awful as this bug is, the workaround exists (to not download credentials twice, or to have the image already cached on all the NCs) and there is no loss of data (volumes and buckets are unaffected by this).

Brian, 2.0 is already out. The current devel head is going to be 3.1 and it should be out in few months.