ec2/create-amis.sh: register root device as /dev/xvda

For the case of blkfront drives, there appears to be no difference
between /dev/sda1 and /dev/xvda: the drive always appears as the
kernel device /dev/xvda.

For the case of nvme drives, the root device typically appears as
/dev/nvme0n1.  Amazon provides the 'ec2-utils' package for their first
party linux ("Amazon Linux"), which configures udev to create symlinks
from the provided name to the nvme device name. This name is
communicated through nvme "Identify Controller" response, which can be
inspected with:

  nvme id-ctrl --raw-binary /dev/nvme0n1 | cut -c3073-3104 | hexdump -C

On Amazon Linux, where the device is attached as "/dev/xvda", this
creates:

- /dev/xvda  -> nvme0n1
- /dev/xvda1 -> nvme0n1p1

On NixOS where the device is attach as "/dev/sda1", this creates:

- /dev/sda1  -> nvme0n1
- /dev/sda11 -> nvme0n1p1

This is odd, but not inherently a problem.

NixOS unconditionally configures grub to install to `/dev/xvda`, which
fails on an instance using nvme storage. With the root device name set
to xvda, both blkfront and nvme drives are accessible as /dev/xvda,
either directly or by symlink.
This commit is contained in:
Andrew Childs 2019-08-23 22:15:58 +09:00
parent 917c498534
commit bd61216f55

View file

@ -211,11 +211,11 @@ upload_image() {
log "Registering snapshot $snapshot_id as AMI"
local block_device_mappings=(
"DeviceName=/dev/sda1,Ebs={SnapshotId=$snapshot_id,VolumeSize=$image_logical_gigabytes,DeleteOnTermination=true,VolumeType=gp2}"
"DeviceName=/dev/xvda,Ebs={SnapshotId=$snapshot_id,VolumeSize=$image_logical_gigabytes,DeleteOnTermination=true,VolumeType=gp2}"
)
local extra_flags=(
--root-device-name /dev/sda1
--root-device-name /dev/xvda
--sriov-net-support simple
--ena-support
--virtualization-type hvm