The officially official Devuan Forum!

theezekielproject

Member

Registered: 2017-11-24

Posts: 3  

Persistent Block Device Names on Ascii

Hello all,
I originally asked this question on linuxquestions but due to the lack of responses, I figured I'd try here.

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. ( Except for one case where /dev/sda did NOT show up as /dev/sda. Not sure what happened there and it hasn't happened since.)

I'm aware that this is usually solved with udev rules, but it seems that having to manually write them nowadays should be rare; I have never had to write them in the past on any of the Debian derivative (or other, for that matter) linux distros I've tested on this computer. Some even running the same kernel version (Though, admittedly, I'm not sure there aren't necessarily significant differences between Debian derivative kernels, I am not sure how these differences would effect udev.rules.)

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 (e.g. device with UUID=X always mapped to /dev/sdX). 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

ralph.ronnquist

Administrator

From: Battery Point, Tasmania, AUS

Registered: 2016-11-30

Posts: 1,253  

Re: Persistent Block Device Names on Ascii

Perhaps you have two examples of namings at two different reboots? E.g., a blkid snap of each? And it probably wouldn't hurt to see an lspci snap as well. (I'm not sure; not really my forte, but I'm guessing what would be useful background info)

With /etc/fstab you assign block devices to mount points, and there you have a few different ways to refer to the block devices, where I think using labels or UUID are the reliable approaches if your hardware is moody. In my experience, most hardware is not moody, and I do well in using the /dev points for identification. But it sounds like that doesn't work for you.

I wouldn't think of using udev to dream up identifications, since it's merely concerned with making sure there are /dev points for the partitions, unless for some reason you want to insist that a partition of a certain label (or UUID) also end up at a certain /dev point. If it works correctly, udev should also be setting up identification mapping for label and UUID and whatnot to the associated /dev.

theezekielproject

Member

Registered: 2017-11-24

Posts: 3  

Re: Persistent Block Device Names on Ascii

I wouldn't think of using udev to dream up identifications, since it's merely concerned with making sure there are /dev points for the partitions, unless for some reason you want to insist that a partition of a certain label (or UUID) also end up at a certain /dev point. If it works correctly, udev should also be setting up identification mapping for label and UUID and whatnot to the associated /dev.

Yes, that's exactly what I want. Normally, I could solve this problem with UUID but this drive has none and as UUID | /dev/sdX can be used in /etc/crypttab, I have to use its /dev/sdX name. I have never had this issue in the many distros I've run on this computer.

With /etc/fstab you assign block devices to mount points, and there you have a few different ways to refer to the block devices, where I think using labels or UUID are the reliable approaches if your hardware is moody. In my experience, most hardware is not moody, and I do well in using the /dev points for identification. But it sounds like that doesn't work for you.

It does not help to define the mount point in /etc/fstab because it is an encrypted disk and /etc/crypttab is read before /etc/fstab. This disk is using plain encryption and there is no header or filesystem on disk, so I relied on it consistently appearing as /dev/sdb in my system which alway has, until now.

Anyhow, 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

lsblk
NAME           MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdd              8:48   0   2.7T  0 disk  
└─sdd2           8:50   0   2.7T  0 part  
sdb              8:16   0   1.8T  0 disk  
└─home         254:1    0   1.8T  0 crypt 
  ├─home-home  254:2    0   1.8T  0 lvm   /home
  └─home-swap  254:3    0    19G  0 lvm   [SWAP]
sr0             11:0    1  1024M  0 rom   
sdc              8:32   0 465.8G  0 disk  
├─sdc2           8:34   0   100M  0 part  
├─sdc3           8:35   0    16M  0 part  
├─sdc1           8:33   0   450M  0 part  
└─sdc4           8:36   0 465.2G  0 part  /media/root/C24673CE4673C1A9
sda              8:0    0 223.6G  0 disk  
├─sda2           8:2    0   244M  0 part  /boot
├─sda3           8:3    0 222.9G  0 part  
│ └─sda3_crypt 254:0    0 222.8G  0 crypt /
└─sda1           8:1    0   512M  0 part  /boot/efi

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!