I'm encountering the same problem as here: http://www.quora.com/Amazon-EC2/Is-it-possible-to-rescue-an-EBS-volume-which-has-marketplace-codes.
Basically I've locked myself out of the instance and I don't have any snapshots. I was working on a larger setup and for security reasons I tried setting up UsePam no in sshd_config which borked everything.
I used the official Debian Amazon Marketplace AMI. Now I'm not allowed to mount the volume somewhere else as a secondary device to fix my stupidity.
The solution listed in the quora thread isn't working. I tried it with two ubuntu images and the instance won't boot with that user data set.
Is there a recent workaround? I'm not trying to access anything secret since I have been using the stock Debian AMIs. I just want to fix that issue without having to re-do everything.
I want to start this by saying that this method is immoral, in that is circumvents AWS Marketplace thereby robbing the dev of potential money, but at the same time, I feel it's necessary to ensuring data safety.
I recently had a crash on one of my AWS Marketplace Image created machines (CSF managed to block the gateway IP address!@!). I was aghast to find that I couldn't simply attach the volume to another machine and edit the .conf files.
After (LUCKILY) having the machine boot on its own (temp ban), I rectified the firewall situation and got thinking just how bad this could go down the track.
The answer was to shutdown original instance, create a snapshot from volume, then an image from that snapshot. Be sure to select the same kernel ID as the running machine to be safe. Create a volume that was the exact same size, format it in the same filesystem (ext4 in my case), shutdown all services then simply DD'd the contents of the root drive to the second drive. Test that new volume will boot as SDA1 on newly created instance. If so, shutdown and terminate old instance(MAKE NOTE OF INTERNAL AND EXTERNAL IP'S BEFORE HAND), Boot new instance with correct local IP's, attach external IPs to internal IP's and cross your fingers.
The second drive no longer identifies with marketplace codes and is therefore still mountable to other instances.
DISCLAIMER: I'm more than happy to pay the dev for usage of the original AMI, but until AWS give us a recovery console (they can limit it however they want) for simple tasks such as fsck and vi/NANO then i'm not going to play by their rules on this one.
Eric Hammond's from Quora, which can be summarised as "I doubt it".
Looks like you're experiencing vendor lock-in.
I'm sorry, but I suspect there's sod all you can do about it. Start again from an open AMI, build out with Chef scripts, optionally integrate those with AWS OpsWorks to give you some kind of deployment mechanism.
No... and yes.
I spent several hours on this problem today and documented what I learned. The gist of it is that you can't exactly attach the volume to another device, but you can contact Amazon's support group, take a snapshot, share it with them, and they can give you a new snapshot that you can use to create a volume & recover your data.
I faced a similar problem. An instance wouldn't boot. The typical solution is straightforward:
Now that a marketplace image cannot be attached to a random server, which I already had running. The solution was actually very simple. Just create a new instance from same AWS Marketplace AMI and you can attach the image to that.