BoxGrinder Build
  1. BoxGrinder Build
  2. BGBUILD-353

Images not bootable on new type of AWS instances

    Details

    • Steps to Reproduce:
      Hide

      boxgrinder-build cybaea-base.appl --trace -p ec2 -d ami
      Launch from AWS console
      Watch it not pass systems checks

      Show
      boxgrinder-build cybaea-base.appl --trace -p ec2 -d ami Launch from AWS console Watch it not pass systems checks
    • Similar Issues:
      Show 10 results 

      Description

      Launched image on AWS (which works with libvirt) but it hangs. mgoldmann on IRC said '/dev/xvdc wasn't mounted and relabelinng requires to have mounted disks' and suggested a bug report. [Warning: newbie with .appl files so I may have done something silly]

      [10:25] cybaea that one is still running and still initializing status checks
      [10:25] cybaea works on my machine with libvirt
      [10:25] mgoldmann yes, /dev/xvdc wasn't mounted and relabelinng requires to have mounted disks
      [10:25] mgoldmann can you log in to that instance?
      [10:25] mgoldmann ah, you cannot
      [10:25] cybaea no
      [10:25] mgoldmann it's in emergency mode
      [10:26] mgoldmann cybaea: please file a new ticket attaching you appliance
      [10:26] mgoldmann https://issues.jboss.org/secure/CreateIssue.jspa?pid=12310920&issuetype=1
      [10:26] mgoldmann appliance definition file of course
      [10:26] cybaea The .appl?

      The running instance is

      --------
      AMI: Unnamed (ami-1e8d5277)

      Zone: us-east-1c
      Security Groups: default

      Type: m1.small
      State: running

      Scheduled Events: No scheduled events
      Owner: 570032957856

      VPC ID: -
      Subnet ID: -

      Source/Dest. Check:
      Virtualization: paravirtual

      Placement Group:
      Reservation: r-64a05e07

      RAM Disk ID: -
      Platform: -

      Key Pair Name: aws2
      Kernel ID: aki-427d952b

      Monitoring: basic
      AMI Launch Index: 0

      Elastic IP: -
      Root Device:

      Root Device Type: instance store
      Tenancy: default
      Lifecycle: normal
      Block Devices:
      Network Interfaces:

      Public DNS: ec2-50-19-53-233.compute-1.amazonaws.com
      Private DNS: ip-10-111-67-127.ec2.internal

      Private IP Address: 10.111.67.127
      Launch Time: 2012-03-17 10:17 GMT (less than an hour)
      State Transition Reason:
      Termination Protection: Disabled
      --------

      Instance created with boxgrinder-build cybaea-base.appl --trace -p ec2 -d ami

      --------
      name: cybaea.base
      summary: Base Fedora system
      version: 0
      release: 4
      packages:

      • @base
      • yum
      • openssh-server
      • openssh-clients
      • system-config-firewall-base
      • sudo
      • acpid
        default_repos: true
        os:
        name: fedora
        version: 16
        password: cybaea
        hardware:
        partitions:
        "/":
        size: 2
        type: ext4
        "/home":
        size: 2
        type: ext4
        files:
        "/":
      • "opt/CYBAEA/setup/services.sh"
      • "opt/CYBAEA/setup/users.sh"
        post:
        base:
      • "echo 'base' > /etc/platform"
      • "chown -R root:root /opt/CYBAEA"
      • "/bin/bash /opt/CYBAEA/setup/services.sh"
      • "/bin/bash /opt/CYBAEA/setup/users.sh"
        vmware:
      • "echo 'vmware' > /etc/platform"
        virtualpc:
      • "echo 'virtualpc' > /etc/platform"
        virtualbox:
      • "echo 'virtualbox' > /etc/platform"
        ec2:
      • "echo 'ec2' > /etc/platform"
        --------

      I assume there will be a place to attach the two files later...

      1. boxgrinder-build.out
        775 kB
        Allan Engelhardt
      2. cybaea-base.appl
        0.8 kB
        Allan Engelhardt
      3. opt.tar
        10 kB
        Allan Engelhardt
      4. system.log
        22 kB
        Allan Engelhardt

        Activity

        Hide
        Marc Savy
        added a comment -

        Have a solution sitting ready here, this is the change we'll merge after we do a bit of testing:

        https://github.com/boxgrinder/boxgrinder-build/commit/73a93645ea3fff6b14180b2ffbdc1f7deb42401d

        Show
        Marc Savy
        added a comment - Have a solution sitting ready here, this is the change we'll merge after we do a bit of testing: https://github.com/boxgrinder/boxgrinder-build/commit/73a93645ea3fff6b14180b2ffbdc1f7deb42401d
        Hide
        Allan Engelhardt
        added a comment -

        Looks like a good solution. Thanks Marc. Will you auto-mount the mapped devices (i.e. (1) add them to /etc/fstab (2) with the auto flag)?

        Show
        Allan Engelhardt
        added a comment - Looks like a good solution. Thanks Marc. Will you auto-mount the mapped devices (i.e. (1) add them to /etc/fstab (2) with the auto flag)?
        Hide
        Marc Savy
        added a comment - - edited

        Allan: http://www.boxgrinder.org/blog/2012/04/20/ebs-and-s3-ami-changes/

        We won't don't do any default attaching or mounting, as this is what was causing the problems. Different instance sizes have different numbers of ephemeral devices, with different device names (e.g. /dev/xvdb in large vs /dev/xvda2 in small) and purposes (i.e. swap vs storage).

        Attaching can still be achieved by using the command-line options shown in the blog.

        The best solution, by far, for mounting is a script like cloud-init (it is in Fedora >=16, there are various RPMs around as Amazon use it internally for their RHEL-based AMIs too!). It can determine at run-time which ephemeral devices should exist, and where they should correctly be mounted.

        When using an S3 based AMI there is a default device attachment mapping provided by AWS - with EBS there is no default device mapping. Again, attaching is different to mounting. As you tend to use S3 AMIs you don't necessarily need to be concerned about the attachment changes - just mounting.

        I'm hoping to make some clear documentation and/or a blog about solutions for mounting such as cloud-init. I'd also like to see what can be done about getting cloud-init or similar available more easily for RHEL/CentOS/SL.

        Clearly hard-coding an fstab can work, but is extremely fragile.

        Show
        Marc Savy
        added a comment - - edited Allan: http://www.boxgrinder.org/blog/2012/04/20/ebs-and-s3-ami-changes/ We won't don't do any default attaching or mounting, as this is what was causing the problems. Different instance sizes have different numbers of ephemeral devices, with different device names (e.g. /dev/xvdb in large vs /dev/xvda2 in small) and purposes (i.e. swap vs storage). Attaching can still be achieved by using the command-line options shown in the blog. The best solution, by far, for mounting is a script like cloud-init (it is in Fedora >=16, there are various RPMs around as Amazon use it internally for their RHEL-based AMIs too!). It can determine at run-time which ephemeral devices should exist, and where they should correctly be mounted. When using an S3 based AMI there is a default device attachment mapping provided by AWS - with EBS there is no default device mapping. Again, attaching is different to mounting. As you tend to use S3 AMIs you don't necessarily need to be concerned about the attachment changes - just mounting. I'm hoping to make some clear documentation and/or a blog about solutions for mounting such as cloud-init. I'd also like to see what can be done about getting cloud-init or similar available more easily for RHEL/CentOS/SL. Clearly hard-coding an fstab can work, but is extremely fragile.
        Hide
        Marc Savy
        added a comment - - edited

        I have a new syntax prepared for specifying arbitrarily nested parameters such as block-device-mappings (along with a load of other cool new features for plugin authors - more description later). It is far more readable and provides a consistent interface, but it is not production ready yet.

        IMO we should launch with the syntax I have outlined above (we have waited too long for the upstream fixes already). I can switch to the new syntax later (with a fallback that supports this legacy format - I've already figured out how it should be possible to do that).

        Old syntax (via command line):
        block_device_mappings:"/dev/sdb=ephemeral0&/dev/sdc=ephemeral1&/dev/sdd=snap-92d333fb::true"

        New syntax will be akin to (via command line):
        block-device-mappings:"

        { /dev/sdb : ephemeral0, /dev/sdc : ephemeral1, /dev/sdd : snap-92d333fb::true }

        "

        Just mentioning this as it is an important related issue, but IMO should not block the release.

        (for those curious about the new syntax and how it works, see this draft: https://gist.github.com/16d3f8c6991409f6e335#advanced)

        Show
        Marc Savy
        added a comment - - edited I have a new syntax prepared for specifying arbitrarily nested parameters such as block-device-mappings (along with a load of other cool new features for plugin authors - more description later). It is far more readable and provides a consistent interface, but it is not production ready yet. IMO we should launch with the syntax I have outlined above (we have waited too long for the upstream fixes already). I can switch to the new syntax later (with a fallback that supports this legacy format - I've already figured out how it should be possible to do that). Old syntax (via command line): block_device_mappings:"/dev/sdb=ephemeral0&/dev/sdc=ephemeral1&/dev/sdd=snap-92d333fb::true" New syntax will be akin to (via command line): block-device-mappings:" { /dev/sdb : ephemeral0, /dev/sdc : ephemeral1, /dev/sdd : snap-92d333fb::true } " Just mentioning this as it is an important related issue, but IMO should not block the release. (for those curious about the new syntax and how it works, see this draft: https://gist.github.com/16d3f8c6991409f6e335#advanced )
        Show
        Marc Savy
        added a comment - https://github.com/boxgrinder/boxgrinder-build/compare/e12a3d5...f5d0b21

          People

          • Assignee:
            Marc Savy
            Reporter:
            Allan Engelhardt
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: