Walrus unable to decrypt image for NC

Bug #565043 reported by Kevin Jordan on 2010-04-16
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Eucalyptus
Invalid
Medium
Unassigned
2.0
Confirmed
Medium
Unassigned

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.

Neil Soman (neilsoman) wrote :

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.

Neil Soman (neilsoman) wrote :

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

Kevin Jordan (kevin-kjordan) wrote :
Download full text (21.3 KiB)

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...

Neil Soman (neilsoman) 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?

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
>

Kevin Jordan (kevin-kjordan) wrote :

log files

Kevin Jordan (kevin-kjordan) wrote :

Any insight from these log files?

Changed in eucalyptus:
assignee: nobody → Neil Soman (neilsoman)

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.

Changed in eucalyptus:
assignee: Neil Soman (neilsoman) → graziano obertelli (graziano.obertelli)
assignee: graziano obertelli (graziano.obertelli) → nobody
importance: Undecided → High
status: New → Confirmed

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

Changed in eucalyptus:
status: Confirmed → Invalid

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.

Changed in eucalyptus:
importance: High → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments