Hello all,
I don't generally consider myself a newb to linux but I can't quite figure out what's going on here; I'm hoping a more knowledgeable member can enlighten me.

I've installed Devuan on my main computer which is currently a laptop but am having an issue with block device naming. With the 3.16.0-4 kernel, I get persistent block device names. E.g. /dev/sdX always shows up as /dev/sdX. But, when running Ascii (Testing), kernel (4.9.0-4), the names seem to be random with the exception of /dev/sda.

I've looked into persistent block device naming but the results I've found seem to refer to mountpoints (and how to "fix" them via fstab, which I am aware of, and is not the issue.), rather than how the the system refers to such devices in output from commands such as lsblk. Can someone point me in the right the direction of how to fix this? I would think this should not be difficult, so I wouldn't be surprised if I'm missing something basic. I feel like persistent naming was implemented out of ease in the first place so this seems like a regression. Any help appreciated. My googlefu seems to be failing me

The persistent names come from udev. I think Devuan uses eudev instead, but the rules files should be similar.

Yes, I had seen mentions of udev and was reading how to write udev in the Arch wiki but I am confused with what they are saying. They mention both "Static" and "Persistent" device naming, and I'm not really understanding the difference.

This Arch wiki page talks about writing udev rules, while the specific section (titled=Setting Static device names) links to a page titled "Peristent Block device naming" and mentions various ways of setting this up, but doesn't say how they are done. There is also a link on this page linking back to "Setting static device names" page. And then a section talking about using UUID's in fstab, but that seems relative to setting mountpoints, rather than what devices are mapped to /dev/sdX.

I am also confused as to why I am seeing this behavior in the 4.9 kernel, but not in the 3.16 kernel, when they should be using the same udev rules.

/dev/sdX depends on which drive spins up ready first. /dev/sda is the one spun up by the BIOS/UEFI to load boot loader from.

After that, each controller is scanned independently - thus whatever drive responds next is given the sdX name by the kernel.

What udev/eudev does is generate matching information - thus things like the /dev/disk/by-id, by-label, by-partlabel, by-partuuuid, by-path, and by-uuid.

This is why the dev/sdX appears random. All the other names are symbolic links to the physical drive (still /dev/sdX name, even though you can't tell which one is what) assigned by udev/eudev.

I find the /dev/disk/by-id useful when I need to refer to a specific disk drive. It uses the manufacturer labels to identify the disk (<connector type>-<vendor model name>-<version><serial number> [-part#]. I use this when passing raw disks to a VM for testing. If the tests pass, then I can take it and boot from it.

Any idea why the naming is consistent with one kernel and not another? This doesn't make any sense to me. I don't understand how which kernel is running is effecting udev.rules files

My main problem is with mounting a plain dmcrypt encrypted disk at boot which does not have a UUID so I am having to refer to it by its /dev/sdX in crypttab, but with the /dev location changing this is not effective and results in boot issues.

@jpollard Does this mean that udev can't actually rename a drive? I know it can rename network devices because the kernel initially calls my ethernet card eth0 but udev changes the name to enp0s25. I always assumed the same thing happened with disk drives.

Other way around. The kernel names the ethernet enp0s25 (based on pci bus number, address on that bus, and device id), and udev/eudev provides the name eth0 for compatibility.

On my system it is identified by /sys/devices/pci0000:00/0000:00:1c.4/0000:06:00.0/net/enp6s0. The name is from the device id "0000:06:00.0" (I'm not sure which field the "s0" bit comes from, but I think it is the 00.0). It always gets the same name because of the bus architecture.

Disks, however, don't - but that is because the bus architecture only reaches the controller designation. After that it is the controller doing the identification - and that depends on when the disk spins up. SCSI controllers report the SCSI target and unit number (most SCSI targets only have one unit, but are permitted up to 16), but ATA controllers don't seem to report...

Personally, I liked the old AT&T naming - devc<nn>t<nn>d<nn> (I think that was) where the cnn is the backplane controller, the tnn was the target controller, and dnn was the specific device. You could tell where things went wrong in errors, and gave a decent idea of the system configuration as the cnn was from the system bus map, the tnn from the controller bus, and dnn the specific unit. But it still didn't identify the physical device very well. When a disk went bad, it was still hard to tell which one it was except when the dnn was the SCSI unit number specified on the disk. With two SCSI controllers you couldn't tell which one it was very easily, and you had to know the cabling connected to which controller inside the system. Again, easily confused when there might be 10s of disks involved. (and now, 100s).

With the current setup, the /dev/by_id will let you find a specific vendor id, model number, and serial number...

Though that does tend to fail when when the system removes the device... or doesn't include it on boot because it failed to spin up.

That doesn't seem to match the order of events in dmesg:

Well, the problem ended up resolving itself. I put a usb hub in between the external harddrive bay and the computer which seems to delay those disks from being read before the "second" internal drive bay, and have rebooted a number of times without issue. Though they are still read funny by the system
But that's not really an issue so much as it is just bothersome lol.

Though it's not really the solution I thought I would find, it's also not a problem I thought I would face.

And I had actually ordered the usb hub before I even had installed this distro or had this problem. And what I planned on using it for, ended up solving the problem I didn't even know I was going to have in the first place!

So that's exciting.

Anyway, thanks for the input!

I have found the order in which devices are plugged into the USB hub determines the order they are given device nodes. If you switch the order, the device files change. This obviously depends somewhat on the kernel, so it may have been changed in 4.x kernel.

Yes that's normally what I see as well except for with this specific distro and kernel. My laptop has 2 internal drive bays which are normally read as /dev/sda and /dev/sdb and anything plugged in via usb gets the next consecutive number. However, with this distro and kernel, It reads one internal bay /dev/sda, then reads other drives plugged into usb, then reads the second internal bay. I have never had that happen before on any distro or kernel that I've ran on this laptop.

That is kind of weird. I can't explain it.

Either can I. Especially with the older kernel working as expected. The only reason I don't use the older kernel is because it doesn't support my wireless card and does not recognize one of my disks