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.
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.
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.
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
NVMe device names follow this pattern: nvme n , where: 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.
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.
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 :(
It's a lot better than the system that just randomly throws in your USB drives with your SCSI/SAS/SATA/PATA drives. Or the systems that calls everything a SCSI drive when it usually isn't a SCSI drive.
Yeah wasn't it something like SATA and USB got lumped in with the SATA SCSI storage controller or whatever which is why it's practically all /dev/sdx? Back in the days of yore when men were men and sheep were scared there'd be /dev/hdx and /dev/fdx for hard and floppy drives?
I will take a look at it, but the fundamental issue is it screws with the iommu groups too and then I have to go fix that in proxmox. If I can at least guarantee a network connection then I can remote in and fix it in the event something goes really wrong.
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-idshould 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.
Right. I don't think they and I are in disagreement - just trying to help expand their statement. Thanks!
Right :) the original meme was just talking about drive names (/dev/sdX)
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
ddin 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?
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 timeAh. Makes sense.
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.
I could have RTFM but you guys are more fun.
Yeah, you get the best Linux info when reading meme comments π.
I tried a gentoo stage 2 or 3 like 20 years ago. I'm still good.
It's fun to have people around who read the friendly manual
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.
So if we swap drives about, the OS will see them as the same drive and/or partition?
Understood. Ty.
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/secondarymaster/slave was configured by a jumper on the drive itself.Yeah, and ide only supported 4 drives at a time in most systems
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.
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.
The arch wiki lists some methods to permanently name network interfaces at https://wiki.archlinux.org/title/Network_configuration#Change_interface_name
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.
hardware-configuration.nix has entered the chat
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.
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.
I still muscle-memory type
/dev/hd[TAB]once in a while when looking for storage devices.I thought they standardized on sd* even for IDE drive a few years back...
Yeah, that's what I think as well...
Got a few old rigs with IDE drives in them running Void x86, the drives in
/devare namedsdx.I didn't know that. Maybe nvme hasn't been added to the standard yet then.
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.
Yeah, but I think they switched to also use sdx for IDE devices as well.
Virtual drives also have a fun and relevant prefix!
Yea, I get that the s in sdX stands for sata, but why cant we have an ndX with n for nvme?
A yes, my beloved nvme1p2 partition that changes name every reboot
thats a reason to use the uuid in the fstab
Anyone else chuckle on the parallel in saying to use the UUID is no different than saying "just hardcore the IP bro"
I'm not hating on you, but it's an extremely flawed system where you are forced to use a direct ID mapping as a reference.
From what I'm understanding from people you can assign an alias to the UUID that sounds better?
It's more like setting a static IP. The UUID is set when you create the partition and won't change unless you force it to change.
You can also use any of the GUI utilities which can add it to your fstab.
There's a lot of things that are made way too difficult on Linux for seemingly no reason. This isn't one of them.
I mean you can also use partition labels but who does that
Oh really? That seems interesting and better than a random uuid
If filesystem UUIDs are IP equivalents. Then device paths are MAC addresses. FS labels are DNS. Device mapper entries are service discovery.
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.
What? Using uuids is the solution to having to change the file (that, or stable name rules). You can also use labels if you want to.
The UUID never fucking changes. It is a hardware level identier use the UUID in your configs and they will work until the day you change drives.
The alternative being running
os-proberat boottime, on every boot.Currently, we set UUID using
os-proberwhenever we remakegrub.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.
Lol I seem to remember that I once had /home mapped to a partition that did that for all sorts of fun and games for a while.
my nvme is always nvme1pX, with X being 1-4 depending on the partition, and its always the same.
Wonder why? Weird that some change and some dont.
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.
Ah, sorry. I only have 1 nvme drive, so thats probably why. Didnt realize until your post that it was a multi-drive issue.
https://wiki.archlinux.org/title/Solid_state_drive/NVMe
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.
Dude, chill, it's a funny take on naming conventions.
I can't chill ever
It's a curse
It's like you're sucking the fun out of us... Wait a minute
Username checks out π€·.
We can enjoy the meme and also use it as a learning opportunity :)
I for one didn't know about NVMe namespaces.
Or an opportunity to be technically correct! Wouldn't want to waste one!
Actually, what you're referring to as...
Aaw, fuck it, I'm not that kind of a guy π€· π.
Great going.
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
"I am irrationally angry, but you are also right, now fuck off"
I can respect this
Oh god damn it I came here to look at memes and now I friggin learned something that's going to make my life easier
Interesting. I learned something. Again.
π€
Ackhsually
I know my role. Someone's gotta do it.
The unsung hero is often the least paid
All this and you missed the chance to also point out that the meme misspelled "conventions."
What a rookie.
Well, I hadn't actively searched for what the NVMe naming convention was for, but this meme made me learn something new. Thanks!
Of course the offended guy links arch wiki article
Who's offended?
Who fucking isn't these days, amirite?
Its always the guy asking the stupid question.
nvme0n1p1
mmcblkxpy
(SD Card)
x = device number
y = partition number
NVMe device names follow this pattern: nvme n , where: is an integer that is assigned by Linux during the boot process. The first NVMe device that is detected is assigned 0
You also can have a 'c' in there, when it wants to model multipath nvme...
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.
The other dragons aren't specifying a partition
So the 3rd dragon should just be
/dev/nvme%dONIPI
This made me chuckle, thank you!!
https://superuser.com/questions/1449499/why-does-linux-list-nvme-drives-as-dev-nvme0-instead-of-dev-sda#1449520
In short;
sdstands for SCSI Disk and SSD and USB all use the SCSI protocol. While SD-cards/emmc (flash-on-CPU) are namedemmcblkpXfor emmc block device, partition X. And NVME have additionally namespaces, which is thenXpart.So, EMMC is even worse
Itβs called that because itβs Never the Value you Might Expect.
Can you elaborate? I like mine a lot. It's super fast.
If you reboot, it might have a different name in /dev/, just like ethernet ports.
This is a feature of SATA devices too. Use UUIDs in your fstab unless you enjoy playing musical chairs with your mount points
Forgot
/dev/hdx?That one hasn't been around for a long time, since the Linux kernel started using a SCSI abstraction layer above many of the other storage protocols. Really cool stuff: https://upload.wikimedia.org/wikipedia/commons/thumb/f/fb/The_Linux_Storage_Stack_Diagram.svg/1161px-The_Linux_Storage_Stack_Diagram.svg.png
I always thought my drive names changed from hdx to sdx because I started using an SSD, and yet...
You always learn something new
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.
Different bus, different naming.
Now, memory kinda hazy, but weren't ide devices /dev/hdX?
Yeah, they used to be, but they switched a few years back to consistently call all block devices sdx.
srsly? so it's just all "grab whatever dev" and not at all associated with the bus?
ATA was rolled into the SCSI subsystem, so both sata and pata are covered by SDX.
Makes sense, I mean... they're all essentialy long term memory storage devices.
I'm guessing it's for some shit to make sure some ridiculous setup with two gazillion drives doesn't have conflicts
obligatory xkcd? Nah, you know exactly which one I mean.
I'm not sure if it is the standards one or the usecase one
No one mentioned the Solaris convention yet ?
/dev/cXtXdXsX
The letters mean controller, SCSI target, disk and slice (Solaris equivalent to a partition).
I always thought this was the most elegant naming scheme in the Unix world.
Mine is easy - /dev/nvme[tab][tab][tab]
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 :(
Raises a glass in Debian 3.0
And who could forget /dev/fd0 for floppies
Having both IDE and SATA together was awesome. "Sooo which one is which?". Good times.
Doesn't work for some things unfortunately
It's a lot better than the system that just randomly throws in your USB drives with your SCSI/SAS/SATA/PATA drives. Or the systems that calls everything a SCSI drive when it usually isn't a SCSI drive.
I thought this was a Wendy's.
Yeah wasn't it something like SATA and USB got lumped in with the
SATASCSI storage controller or whatever which is why it's practically all /dev/sdx? Back in the days of yore when men were men and sheep were scared there'd be /dev/hdx and /dev/fdx for hard and floppy drives?/dev/sdx wasn't originally for SATA, it was for SCSI drives. Back when men were men indeed!
That is correct, unlike my typo.
Yes, /dev/hdX was IDE disks.
It all falls under the SCSI protocol now, they get separated at low level by another driver.
Kinda miss the Wild West days where you'd recompile and suddenly there'd be a whole new device naming convention.
I just run arch. It self compiled.
Of course not. It hadn't compiled yet.
Depends on how far you wanna go back, but Arch was released in 2002 which definitely covers the time period of the drive naming changes in this meme.
Shouldn't that be
hdX, sdX, and nvmewtfisthisp1
Yes but with zeros also.
PATA HDDs are
hdXSATA and SCSI HDDs are
sdXThat USED to be true. Now every block device is sdx... except to nvme.
You mean Linux? Other Unixes don't necessarily use this naming convention.
Also I'm quite sure /dev/hdx is a thing
That's for IDE drives. And there's /dev/vdX for virtual block devices.
babe wake up, we heard you like dynamic interface IDs that happen to be mostly static, so we applied it to your nvme drives, because fuck it, why not.
Same with SD cards and similar interfaces.
/dev/nvme0n1actually, but sure. Change badNO IT IS YOU WHO DONT UNDERSTAND IT IS PERFECT LOGIC
Dude, chill, it's a meme... sheesh.
You're a meme
I'm a Linux admin
Grovel before me or I will go through your browsing history
(hit me up if you want to hear what distro i run btw)
What distro? Tho if you're an admin it should be multiple distros, no?
Nope. Just the one.
He did say BTW in the end, so... it's NOT Arch!
I will take a look at it, but the fundamental issue is it screws with the iommu groups too and then I have to go fix that in proxmox. If I can at least guarantee a network connection then I can remote in and fix it in the event something goes really wrong.
Ummm... replying to the wrong thread I think π.
Thank you! I will give that a shot tomorrow and test it