and you shouldn’t be using any of those, since the order can and will change. The numbers are based on the order the devices and device drivers are initialized in, not based on physical location in the system. The modern approach (assuming you’re using udev) is to use the symlinks in
/dev/disk/by-id/
or/dev/disk/by-uuid/
instead, since both are consistent across reboots (andby-id
should be consistent across reinstalls, assuming the same partitioning scheme on the same physical drives)This is also why Ethernet devices now have names like
enp0s3
- the numbers are based on physical location on the bus. The oldeth0
,eth1
, etc. could swap positions between Linux upgrades (or even between reboots) since they were also just the order the drivers were initialized in.I’m sure you know this, but to to supplement your comment for future readers, UUIDs are also a good solution for partitions.
Labels are better. IMO; they’re semantic.
I agree. Also, I can swap a disk with a new one with the same label, no need to change fstab
I think OP’s point was that UUIDs can still change, but the stuff that makes up the /by-id/ names cannot. Granted, those aren’t applicable to partitions.
How are the uuids going to change unexpectedly?
Depends on your definition of “unexpected”. OP was talking about reinstalls for example, where the root partition is deleted and recreated and its UUID will change as a result. If you copy an fstab from an older system backup you will fail the mount the root partition.
UUIDs can also cause some reverse trouble if you clone them with
dd
in which case they won’t change but they should, and you end up with duplicate UUIDs.
Are UUIDs built into the hardware, or something your computer decides on based on the drive’s serial number and shit?
According to Arch Wiki they get generated and stored in the partition when it is formatted. So kinda like labels but automated and with (virtually) no collision risk.
Uuids are part of the gpt (table) on the disk.
You’re thinking of
partuuid
, regular uuids are part of the filesystem and made at mkfs time
I have a hatred for the enp id thing as it isn’t any better for me. It changes on me every time I add/remove a hard drive or enable/disable the WiFi card in the BIOS. For someone who is building up a server and making changes to it, this becomes a real pain. What happens if a drive dies? Do I have to change the network config yet again over this?
Use a systems rule to give it a consistent name based on its MAC address, driver, etc. I just had this exact same problem setting up my servers.
root@prox1:~# cat /etc/systemd/network/10-persistent-10g.link [Match] Driver=atlantic [Link] Name=nic10g root@prox1:~# cat /etc/systemd/network/10-persistent-1g.link [Match] Driver=igb [Link] Name=nic1g
Mine is easy - /dev/nvme[tab][tab][tab]
Well it’s sdx because they both use the SATA interface. The sdx convention actually comes from scsi though, and the fact that SATA and USB drives use it might point to some code reuse, or maybe a temporary solution that never got fixed due to breaking backwards compatibility.
Fun fact: IDE drives use the hdx naming convention.
Kinda miss the Wild West days where you’d recompile and suddenly there’d be a whole new device naming convention.