Alright. I decided to write this because the tutorials I could find on the internet weren’t really tailored specifically for Ubuntu and it turned out that extra care might be needed.
So as we all know, t1 instances are paravirtualization and t2 are hardware virtual machines, and naïvely re-attching Linux root device EBS created for t1 instances onto new t2 instance as-is wouldn’t work due to potential boot loader and kernel issues — we need some manual operations.
My Ubuntu installation was a 32-bit 14.04.2 server with all updates applied. I installed 32-bit back in 2012 because at that time t1.micro’s less than 700MB available RAM didn’t seem enough to warrant 64-bit for me. It’s not possible to “upgrade” (if that’s a suitable word at all) the installation to 64-bit in-place so my resulting t2.micro installation would still be 32-bit (anyway it’s just 1GB RAM). Also, I had already had grub installed (not sure if that’s default, though).
Anyway, I mostly followed Javier Sianes‘s steps. His steps are for Amazon Linux instances, and in adaptation to Ubuntu instances there are some things to note:
- Choose Amazon Linux AMI when launching the working instance, even though we’re migrating Ubuntu instances. When I launched Ubuntu as my working instance and attached the two (t1 & t2) EBS volumes onto it, the working instance booted on the t2 volume (located at /dev/xvdg), instead of its root device attached at /dev/sda1 (as shown in EC2 console). I couldn’t understand why this happened as everything indicated normal at EC2 console. I guess you could launch an Ubuntu working instance and attach the t1 & t2 volumes only after the working instance boots up, but I didn’t try.
- I chose 12GB EBS storage when launching the t2 instance to match my t1 instance storage space. However the Ubuntu AMI’s root partition/filesystem was only 8GB large. I needed to re-create the partition table and resize the filesystem. Not that hard as I’d did that quite a few times.
- Remember that the root device node for Ubuntu is /dev/sda1.
- Replacing the /boot and kernel folders was necessary for first boot after the migration of the files. I guess it’s because the 64-bit kernel was still needed for that boot. After that, I just manually re-installed the (32-bit) kernel images by apt-get and let apt-get configure boot-related mechanisms.
- Another thing to note is t2.micro instances must be incorporated in a VPC network. My old Elastic IP didn’t seem to be a VPC-capable public IP (in 126.96.36.199/19, in Tokyo) so I had to redo all the binding and DNS setup.