When running tests with packit using tmt which runs the tests in AWS I noticed the NVMe drive present on the system has /dev/sda1 symlink created for the /dev/nvme0n1 device. Similarly /dev/sda11, /dev/sda12 etc. symlinks are created for partitions on the NVMe. udev version: systemd-udev-0:256.5-1.fc41 udev properties for /dev/nvme0n1: ----- 'CURRENT_TAGS': ':systemd:', 'DEVLINKS': '/dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0dd9d3f42ab640d3f /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0dd9d3f42ab640d3f-ns-1 /dev/disk/by-diskseq/1 /dev/disk/by-id/nvme-uuid.ae346bed-d818-5ce0-b2f1-cae0e3bdfdc8 /dev/sda1 /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0dd9d3f42ab640d3f_1 /dev/disk/by-path/pci-0000:00:04.0-nvme-1', 'DEVNAME': '/dev/nvme0n1', 'DEVPATH': '/devices/pci0000:00/0000:00:04.0/nvme/nvme0/nvme0n1', 'DEVTYPE': 'disk', 'DISKSEQ': '1', 'ID_MODEL': 'Amazon Elastic Block Store', 'ID_NSID': '1', 'ID_PART_GPT_AUTO_ROOT_UUID': 'cf4ad69d-fe1d-4c10-addd-1d3b2ed99d29', 'ID_PART_TABLE_TYPE': 'gpt', 'ID_PART_TABLE_UUID': '3dd46407-ccbc-436f-8400-6d6928832861', 'ID_PATH': 'pci-0000:00:04.0-nvme-1', 'ID_PATH_TAG': 'pci-0000_00_04_0-nvme-1', 'ID_REVISION': '2.0', 'ID_SERIAL': 'Amazon_Elastic_Block_Store_vol0dd9d3f42ab640d3f_1', 'ID_SERIAL_SHORT': 'vol0dd9d3f42ab640d3f', 'ID_WWN': 'uuid.ae346bed-d818-5ce0-b2f1-cae0e3bdfdc8', 'MAJOR': '259', 'MINOR': '0', 'SUBSYSTEM': 'block', 'TAGS': ':systemd:', 'USEC_INITIALIZED': '3933501' ----- udev properties for /dev/nvme0n1p1: ----- 'CURRENT_TAGS': ':systemd:', 'DEVLINKS': '/dev/disk/by-diskseq/1-part1 /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0cb54fb95bd126c62_1-part1 /dev/disk/by-partuuid/56befb49-9d1c-4863-a956-a13cebc6ce9c /dev/disk/by-partlabel/p.legacy /dev/disk/by-path/pci-0000:00:04.0-nvme-1-part/by-partlabel/p.legacy /dev/disk/by-path/pci-0000:00:04.0-nvme-1-part/by-partnum/1 /dev/sda11 /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0cb54fb95bd126c62-ns-1-part1 /dev/disk/by-id/nvme-Amazon_Elastic_Block_Store_vol0cb54fb95bd126c62-part1 /dev/disk/by-path/pci-0000:00:04.0-nvme-1-part1 /dev/disk/by-path/pci-0000:00:04.0-nvme-1-part/by-partuuid/56befb49-9d1c-4863-a956-a13cebc6ce9c /dev/disk/by-id/nvme-uuid.6dd6db11-29a0-5c99-b13c-7fcd49f035fa-part1', 'DEVNAME': '/dev/nvme0n1p1', 'DEVPATH': '/devices/pci0000:00/0000:00:04.0/nvme/nvme0/nvme0n1/nvme0n1p1', 'DEVTYPE': 'partition', 'DISKSEQ': '1', 'DM_MULTIPATH_DEVICE_PATH': '0', 'ID_MODEL': 'Amazon Elastic Block Store', 'ID_NSID': '1', 'ID_PART_ENTRY_DISK': '259:0', 'ID_PART_ENTRY_NAME': 'p.legacy', 'ID_PART_ENTRY_NUMBER': '1', 'ID_PART_ENTRY_OFFSET': '2048', 'ID_PART_ENTRY_SCHEME': 'gpt', 'ID_PART_ENTRY_SIZE': '4096', 'ID_PART_ENTRY_TYPE': '21686148-6449-6e6f-744e-656564454649', 'ID_PART_ENTRY_UUID': '56befb49-9d1c-4863-a956-a13cebc6ce9c', 'ID_PART_GPT_AUTO_ROOT_UUID': 'cf4ad69d-fe1d-4c10-addd-1d3b2ed99d29', 'ID_PART_TABLE_TYPE': 'gpt', 'ID_PART_TABLE_UUID': '3dd46407-ccbc-436f-8400-6d6928832861', 'ID_PATH': 'pci-0000:00:04.0-nvme-1', 'ID_PATH_TAG': 'pci-0000_00_04_0-nvme-1', 'ID_REVISION': '2.0', 'ID_SERIAL': 'Amazon_Elastic_Block_Store_vol0cb54fb95bd126c62_1', 'ID_SERIAL_SHORT': 'vol0cb54fb95bd126c62', 'ID_WWN': 'uuid.6dd6db11-29a0-5c99-b13c-7fcd49f035fa', 'MAJOR': '259', 'MINOR': '1', 'PARTN': '1', 'PARTNAME': 'p.legacy', 'SUBSYSTEM': 'block', 'TAGS': ':systemd:', 'USEC_INITIALIZED': '3994407', '_NS_ID': '1' ----- Reproducible: Always
It seems that there is some Amazon mapping from nvme names to sd ones https://docs.aws.amazon.com/ebs/latest/userguide/identify-nvme-ebs-device.html
So, in case the nvme id-ctrl structure contains something vendor-specific like the encoded "sda" string, what mechanism is used to extract this field and make a symlink?
https://github.com/amazonlinux/amazon-ec2-utils/blob/main/70-ec2-nvme-devices.rules
Anyway, this seems to be related to amazon infrastructure and not related to systemd itself.
Thanks Lukas! Let's reopen and reassign to amazon-ec2-utils as this really needs to be fixed. One possible solution might be to lower priority of such symlinks so that they get properly overwritten by regular device rules. If there's no real scsi device that the name should belong to, it won't change anything to the users. If a real device appears, then the Amazon symlinks should become invalid.
See udev(7) and link_priority= option, in this case negative numbers might help.
Duplicate of bug 2284397 Upstream issue: https://github.com/amazonlinux/amazon-ec2-utils/issues/37
*** This bug has been marked as a duplicate of bug 2284397 ***