TipsAndTricks/Running YP Image On AWS

From Yocto Project
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


Creating an AMI from a Yocto Image

While it is no longer well documented, AWS does still allow custom built linux AMI images so long as they have the following requirements:

  1. MBR partition table
  2. Grub bootloader
    1. AWS support claims that grub legacy is required; we suspect this is for licensing reasons. Due to grub 0.97 issues installing onto loopback devices, we failed to get grub legacy up and running on our image, but we were able to get grub 2 booting just fine on AWS. Future work would involve finding a way to use grub 0.97 since that’s what AWS is specifically wanting.
  3. Cloud-init
    1. AWS claims to have a specific cloud-init package, though it seems likely that an up to date package would probably work. Future work would include closely examining running AMIs to determine cloud-init versioning and functionality, and ensure that Yocto layer that supplies cloud-init is providing the proper version.

Procedure to Build, Upload, and Register the AMI

Build Yocto image

Note: This was done with Yocto Project version 2.4.

  1. Add the following to local.conf
  MACHINE ?= "genericx86-64"
  IMAGE_INSTALL_append=" wget \                                                                                                                                                                           
  cloud-init \                                                                                                                                                                                            
  packagegroup-core-full-cmdline \                                                                                                                                                                        
  grub \                                                                                                                                                                                                  
  connman \                                                                                                                                                                                               
  kernel-module-xen-acpi-processor \       
                                                                                                                                                              
  IMAGE_FEATURES += " ssh-server-openssh"
  # Ensure extra space for guest images                                                                                                                                                                  
  IMAGE_ROOTFS_EXTRA_SPACE = "1000000"
  DISTRO_FEATURES_append = " systemd virtualization xen "
  VIRTUAL-RUNTIME_init_manager = "systemd"
  DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

NOTE: These settings work, and allow you to log into your AMI. When I tried a dropbear/sysvinit version, I could no longer ssh into the instance. I am unsure what the minimum sized version consists of that will still allow ssh into the instance.


  1. Add the following to bblayers.conf to include cloudinit
  BBLAYERS ?= " \
    /workdir/meta \
    /workdir/meta-yocto \
    /workdir/meta-poky \
    /workdir/meta-yocto-bsp \
    /workdir/meta-openembedded/meta-oe \
    /workdir/meta-openembedded/meta-python \
    /workdir/meta-openembedded/meta-networking \
    /workdir/meta-openembedded/meta-filesystems \
    /workdir/meta-virtualization \
    /workdir/meta-cloud-services/meta-openstack \
  "
    1. Location of layers can be found from http://layers.openembedded.org
  1. bitbake core-image-base (do NOT use core-image-minimal)

Create AMI image

Note: AWS support claims that grub legacy is required for AMIs, but we found that grub2 worked just fine. We had issues installing grub 0.97 on a loopback device, so we just used grub2. These commands are examples - they were used for Ubuntu development systems. Different systems may have slightly different commands.

Create an empty img file of desired total size

  dd if=/dev/zero of=yoctoami.img bs=1M count=500

Create MBR Partition table and set bootable flag

  (echo n; echo p; echo 1; echo; echo; echo a; echo p; echo w) | fdisk yoctoami.img

Mount to loopback device and create filesystem NOTE: The filesystem is formatted on the PARTITION not the general loopback device.

  sudo kpartx -av yoctoami.img  
  sudo mkfs.ext4 /dev/mapper/loopXp1

Copy a yocto rootfs onto the ext4 partition we just formatted

  sudo mount tmp/deploy/images/genericx86-64/core-image-base.ext4 /mnt/yoctofs
  sudo mount /dev/mapper/loopXp1 /mnt/yoctoami
  rsync -av /mnt/yoctofs/ /mnt/yoctoami/

Populate grub.cfg and Install grub

  • NOTE: Grub is installed onto the loopback device, NOT the partition. To obtain PARTUUID: blkid /dev/mapper/loopXp1
  mkdir -p  /mnt/yoctoami/boot/grub/
  echo "(hd0)   /dev/sda" | sudo tee /mnt/yoctoami/boot/grub/device.map
  vi /mnt/yoctoami/boot/grub/grub.cfg
  menuentry "Yocto Kernel AWS" {
    set root='hd0,msdos1'
    insmod vga
    insmod gzio
    linux /boot/bzImage-4.12.12-yocto-standard  root=PARTUUID=<partid>
  }
  
  sudo grub-install --no-floppy --grub-mkdevicemap=/mnt/yoctoami/boot/grub/device.map --root-directory=/mnt/yoctoami /dev/loopX

Unmount filesystems

  sudo umount /mnt/yoctoami
  sudo kpartx -dv yoctoami.img 
  sudo umount //mnt/yoctofs

Prepare AWS Account

  1. Create a user
    1. I gave admin privileges to make allow uploading bundles to buckets and registering amis. I’m sure there’s a better, more limiting subset of permissions (a custom written policy if nothing else), but for now I just gave blanket permissions.
  2. Each user gets an AWS access key id, which is required for cli and api commands. Make sure you save this somewhere.
  3. Create an S3 Bucket to store your image files
    1. http://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html
    2. Add proper permissions to this bucket so you can interact with the objects via the CLI
    3. Select your bucket from the AWS S3 console
    4. Go to Permissions->Bucket Policy
    5. Following these guidelines, enter a policy with your proper information:
  {
     "Version": "2012-10-17",
     "Statement": [
         {
             "Sid": "Stmt1508534072338",
             "Effect": "Allow",
             "Principal": {
                 "AWS": "arn:aws:iam::<accountnumber>:<role>"
             },
             "Action": "s3:*",
             "Resource": "arn:aws:s3::<:bucketname>"
         }
     ]
  }

AWS Environment Setup

  1. Download the AWS CLI and EC2 AMI tools
  “sudo apt-get install awscli”
  “sudo apt-get install ec2-ami-tools”
  1. Configure your CLI

Follow the directions for “Quick Configuration” here: http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration

  1. More thorough documentation of the install process and CLI here:

http://docs.aws.amazon.com/cli/latest/userguide/installing.html

Bundle, Upload, and Register your AMI

Documentation for these commands can be found here and here. These are examples of what my commands looked like. Uploading your bundles and registering your ami can also be done via UI interfaces in the the AWS console.

  1. Bundle your image
  ec2-bundle-image -c server.cert -k server.key -u userID -i yoctoami.img 
  1. Upload your image
  ec2-upload-bundle -b arn:aws:s3:::bucketname -a accesskey -s secretaccesskey -m /tmp/yoctoami.img.manifest.xml 
  1. Register your AMI
  aws ec2 register-image --image-location bucketname/yoctoami.img.manifest.xml --name "yoctoami" --architecture x86_64 --virtualization-type hvm

Run Your AMI

Once your AMI is registered, it will show up in your AWS EC2 console under Images->AMIs.

  1. Select your new AMI, then click Launch
  2. Select the type of image you want to launch (I used the default of m3.medium), then click through to see if there is any other configuration you would like to add (I didn’t select any).
  3. Launch the instance. Once your instance is launched, you should be able to see it pass the initialization checks and have the state of “running”.
  4. You can now connect to the instance via ssh, per the instructions on the console. Note, the default YP login is root w/ no password, so hopefully you have either overriden this or you have very restrictive inbound rules on your instance.
  5. You can also get a screenshot of the running instance and see that it is patiently waiting at the Yocto login prompt :)