Hi, how does this solve the problem where you want to create a partition, say you have symlinked /dev/nvme1n1 to /dev/sdb, and you want to create a partition at /dev/sdb1. If i try this, it creates the partition but does not create any symlink under /dev for sdb1, because udev only looks at the main block device, not its partitions. So having this block device symlink doesn't allow me to do anything with the device - am I missing something? Ryan
Thanks for this! Works like a charm, although I had to use the python3 version of ebsnvme-id (found at https://gist.github.com/jalaziz/c22c8464cb602bc2b8d0a339b013a9c4#gistcomment-2747749) as newer ubuntu AMIs don't have python 2.7 anymore.
How do you persist mapped devices across reboots? Do you run nvme-to-block-mapping earlier at boot so when fstab arrives the /dev/sd*
links are there or do you use UUIDs? I could not find a robust way for the former, so I had to modify my deploy scripts to update fstab with UUIDs (obtained with blkid -s UUID -o value /dev/sd*
). Besides that, your script saved my day.
I know I'm several months late to the party on this, but you can also get the ebs and ephemeral block device mapping from the EC2 metadata endpoint (169.254.169.254/latest/meta-data/block-device-mapping/). EBS devices that were attached before the last cold boot wont show up, so in my system provisioning after attaching additional EBS volumes I just have an initial step of stopping and starting the instance to refresh the metadata endpoint contents.
And more recent linux distributions already parse this information with Cloud-Init so the mapping is also available in a local file in json format. On Ubunutu 18 AMIs its at /run/cloud-init/instance-data.json, at the key ds.meta-data.block-device-mapping.ebsN