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 (and by-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 old eth0, 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 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.
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.
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.
No. Since each partition gets its own UUID, it means it's generated by the OS on creation, no matter the number of partitions. On boot kernel will scan all UUIDs and then mount and map according to them, which is sightly less efficient method than naming block device directly, but far easier for humans and allows you to throw your drives to whichever port you like.
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?
How is that happening? The number on the bus shouldn't change from adding or removing drives. I could imagine this with disabling a card in UEFI / BIOS if that basically stops reporting the bus entry completely. But drives?
Anyhow, if I'm not mistaken, you can assign a fixed name based on the reported MAC.
It is only the nvme drives that do it. That damn PCI busses and iommu groups get renumbered every damn time I remove or add one. The SATA is safe though.
Having used gentoo for quite some time, there have been several occations where my network broke because the changing names and naming conventions of the network interfaces.
Back in my day, /dev/hda was the primary master, hdb was the primary slave, hdc was the secondary master and hdd was the secondary slave.
Nothing ever changed between reboots. Primary/secondary depended on which port the ribbon cable connected to on the motherboard, and primary/secondary master/slave was configured by a jumper on the drive itself.
If you had a Sound Blaster 16, you had an extra IDE port on the board, which DOS couldn't see and you had to load special drivers to use them. Usually it was used for the CD-ROM.
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.
No, they decided that nvme were too fancy to be modeled by mundane 'sdxn' scheme. They hypothetically have 'namespaces' and 'controller paths' and they wanted to have the naming scheme model that fully.
In the scenario of having to constantly update an fstab yes it is. As an end user I shouldn't have to keep updating configuration files because something on a lower level keeps changing its alias.
No granted I'm not familiar with this type of mount. Maybe there is a better way to do it that absolves needing to use the UUID but if not that's shit architecture IMHO.
The alternative being running os-prober at boottime, on every boot.
Currently, we set UUID using os-prober whenever we remake grub.cfg, analogous to that would be registering web-server static IPs with a DNS, which provides the domain name aliases (we don't need to see UUID in the GRUB menu right? We see the OS names).
An analogy to the alternative would be to ask all devices on the internet to send their usage methods everytime you try to look for another site.
I got two drives with one being nvme1pX and the other nvme2pX and I don't know why but they just swap names sometime. I'm new to linux though so it may be some misconfiguration on my part and I rarely need to access them with their name.
Namespaces are the construct in NVMe technology that hold user data. An NVMe controller can have multiple namespaces attached to it. Most NVMe SSDs today just use a single namespace, but multi-tenant applications, virtualization and security have use cases for multiple namespaces.
device v
/dev/nvme0n1p1 < partition
namespace ^
There are two types of people: Those who are able to identify gaps in their knowledge and actively seek to fill them... and whatever this meme is.
Funny? In a meme? C'mon man, we're trying to be serious here and know which technologies we can shame to feel good about ourselves. Stop ruining my quest for self-egrandifying tech-snobbery with your so-called humour!!1!
P.S. thanks to @vampire even so; that was interesting to learn
In short; sd stands for SCSI Disk and SSD and USB all use the SCSI protocol. While SD-cards/emmc (flash-on-CPU) are named emmcblkpX for emmc block device, partition X. And NVME have additionally namespaces, which is the nX part.
NVMe device names follow this pattern: nvme <number> n <namespace> , where: <number> is an integer that is assigned by Linux during the boot process. The first NVMe device that is detected is assigned 0
I still don't understand the point of namespaces. I guess it's less overhead to pass through a namespace to a VM rather than having a virtualised disk image or bind mount.
I once had to do GRUB related stuff with CentOS 5 (or was it 3?).
Stuff started with 0 in it and I was kept wondering what I was selecting, because the naming convention in GRUB was different from that in the OS.
Back in the olden times the Linux kernel had a dedicated parallel-ATA subsystem with /dev/hda devices. It was then rolled up in to the scsi subsystem to simplify maintaining drivers (everything using the same library for disk access). I'm old :(
