If you roll up and deploy your pre-configured ~/.rvm folder and make sure the remote .bashrc is configured to use it, do you get any problems? From what I can tell, rvm is designed to allow you to do this.
The only snags I imagine could be around making sure you have the right gems and packages in place to allow your code to run. But then, you'd prepare your .rvm on the target platform right? Also, take into account any OS packages required by your ruby environment.
Solution is to use a bios_grub partition, which is not the same as the /boot partition.
By default the bios_grub partition is 1MiB, and it must be flagged bios_grub. Mine is the first partition on my disk. If your partition 2 is actually /boot as parted suggests, that would not be correct and you should make another 1MiB partition.
With GPT and GRUB2 the minimum filesystem has three partitions: bios_grub, root, swap. (not perfectly sure swap is required)
Why does grub fail to boot after simply running "grub-install"?
Unknown... You'd think it wouldn't modify anything if it says clearly it cannot embed so it can't work.
Why does it say "file not found"?
/vmlinuz is a symlink that uses the boot partition, and the boot partition is corrupt. The bios_grub code was written on top of its ext3 structure. This probably meant that /boot was not mounted, and the grub files seen there were actually on the root system, which didn't contain the kernel.
Why doesn't grub want to install without this setting I set with parted
A GPT partition table has no space for a bootloader, unlike MBR. So a specific partition must be created to hold the boot code. Before running "grub-install", specify this partition with the command:
parted /dev/sda set 1 bios_grub on
I thought all I needed was a separate /boot. How does the Ubuntu CD installer install it without the bios_grub setting?
This requirement seems to be all that is needed for the Ubuntu installer, but it creates an unstandard system which is broken easily.
When GRUB says "This GPT partition label has no BIOS Boot Partition", it means the bios_grub partition, not /boot.
Best Answer
This issue can be caused by a range of different problems so there isn't a single solution. These steps should work on EC2.
Source:
The issue is caused by a local and remote change conflict in Grub legacy configuration. Grub legacy and Grub2 use different config locations:
/boot/grub/menu.lst
/boot/grub/grub.cfg
Causes:
You're probably using an Amazon EBS-Backed AMI. Instances construct their root file system from a pre-built base image (snapshot). The grub configuration is written in the snapshot, but the UCF registry isn't purged correctly. This means that you have a snapshot that thinks the
menu.lst
config was locally modified. More information can be found here: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1485685Why ubuntu uses UCF for grub is explained here: https://askubuntu.com/a/147079
Solution(s):
One general solution that works is removing menu.list and reconfiguring it. This ensures that ucf registry entry and configuration file resolve to the same hash.
A second solution is modifying the UCF config to auto accept the maintainer changes
Disclaimer:
This issue is very broad and use cases will impact the required solution. If possible its highly recommended to upgrade to grub2. Grub2 can be configured without modifying system files.
There are also a ton of different solutions offered and issue reports opened in the ubuntu tracker. I'd love to link to all of them but don't have the rep.
Good luck :)