1

So, my adventure started like this: I had an OpenSUSE 13.1 VM, and I wanted to upgrade to 13.2, so one of the main differences between the 2 community amis (13.1 - `` and 13.2 -ami-3a6cc64d) was that the 13.2 image uses HVM - instead of PV - virtualization type.

The first issue I came across was that my CloudFormation template was using a /dev/sda device_name, under the BlockDeviceMappings, BUT apparently that's not the type of device_name an HVM type of image expects (see here for more info). This resulted in the EC2 instance not even going into a running state.

Anyway, I was able to overcome that obstacle by assigning /dev/sda1, as recommended, so my instance was finally able to start properly.

BUT - now on startup several of my services don't start, due to failed dependencies, which I've been able to track down to cloud-config not finishing correctly whatever AWS has told it to do:

If I run $ systemctl ... cloud-init-local.service loaded active exited Initial cloud-init job (pre-networking) cloud-init.service loaded failed failed Initial cloud-init job (metadata service crawler) ...

Upon inspection of the logs (/var/log/syslog), I can see the following: ... Failed to resize filesystem (cmd=('resize2fs', '/dev/hda1'))#012Traceback ... but, i've not set this up myself, this is something that somehow AWS has decided to do on my image via cloud-config...

I have no idea why this happens, and I can't seem to find many relevant posts, so any ideas would be really welcome guys...! : )

Thanks in advance!!

gsaslis
  • 111
  • 4
  • *this is something that somehow AWS has decided to do* ... well, no. This is something that was there all along. AWS doesn't "decide" to do things to your instance's installed software or tell cloud-init what to do. – Michael - sqlbot Jan 15 '16 at 02:04
  • yeah well, you're right (in that it was there all along), but I didn't know that it was!! (i.e. i didn't know it uses cloud-config if you don't specify it in the userdata of the EC2 instance yourself)... – gsaslis Jan 15 '16 at 11:40

1 Answers1

0

Ok, so it turns out that I had to explicitly disable the default cloud-config behaviour, using the resize_rootfs attribute: 

# resize_rootfs should the / filesytem be resized on first boot
# this allows you to launch an instance with a larger disk / partition
# and have the instance automatically grow / to accomoddate it
# set to 'False' to disable
# by default, the resizefs is done early in boot, and blocks
# if resize_rootfs is set to 'noblock', then it will be run in parallel
resize_rootfs: True

setting that to False, removed the error, so the cloud-init.service service no longer failed on startup.

(Most resources I had initially found were leading me to believe that I should be using growpart, but that wasn't the case.)

gsaslis
  • 111
  • 4