LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 11-20-2017, 03:19 AM   #1
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Rep: Reputation: 190Reputation: 190
Block device name scheme inconsistent on newer kernel versions


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
 
Old 11-20-2017, 05:33 AM   #2
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 3,391
Blog Entries: 9

Rep: Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895
The persistent names come from udev. I think Devuan uses eudev instead, but the rules files should be similar.
 
Old 11-21-2017, 08:28 PM   #3
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Original Poster
Rep: Reputation: 190Reputation: 190
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.
 
Old 11-21-2017, 08:59 PM   #4
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,843

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
/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.
 
Old 11-21-2017, 09:14 PM   #5
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Original Poster
Rep: Reputation: 190Reputation: 190
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.
 
Old 11-22-2017, 01:56 AM   #6
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 3,391
Blog Entries: 9

Rep: Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895
@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.
 
Old 11-22-2017, 05:21 AM   #7
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,843

Rep: Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472Reputation: 1472
Quote:
Originally Posted by hazel View Post
@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.
 
Old 11-22-2017, 05:45 AM   #8
hazel
Senior Member
 
Registered: Mar 2016
Location: Harrow, UK
Distribution: LFS, AntiX, Slackware
Posts: 3,391
Blog Entries: 9

Rep: Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895Reputation: 1895
Quote:
Originally Posted by jpollard View Post
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.
That doesn't seem to match the order of events in dmesg:
Code:
[    0.851439] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:23:7d:c3:17:d9
[    0.851471] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    0.851515] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: 1042FF-0FF
..........................................
[    2.705828] e1000e 0000:00:19.0 enp0s25: renamed from eth0
 
Old 11-25-2017, 04:39 AM   #9
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Original Poster
Rep: Reputation: 190Reputation: 190
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
Code:
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!
 
Old 11-26-2017, 07:41 PM   #10
AwesomeMachine
LQ Guru
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,513

Rep: Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004
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.
 
Old 11-26-2017, 09:36 PM   #11
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Original Poster
Rep: Reputation: 190Reputation: 190
Quote:
Originally Posted by AwesomeMachine View Post
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.
 
Old 11-26-2017, 10:56 PM   #12
AwesomeMachine
LQ Guru
 
Registered: Jan 2005
Location: USA and Italy
Distribution: Debian testing/sid; OpenSuSE; Fedora; Mint
Posts: 5,513

Rep: Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004Reputation: 1004
That is kind of weird. I can't explain it.
 
Old 11-27-2017, 01:47 AM   #13
TheEzekielProject
Member
 
Registered: Dec 2016
Distribution: Devuan+lxde
Posts: 656

Original Poster
Rep: Reputation: 190Reputation: 190
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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Need to block later versions of Linux kernel but don't know how. NewbProgrammer Gentoo 4 06-10-2017 06:44 AM
[SOLVED] Newer versions of software? Steve W Linux - Newbie 2 12-03-2012 10:53 AM
[SOLVED] newer kernel versions only use one core David the H. Linux - Kernel 2 07-05-2010 01:36 AM
USB Modems etc. (CDCEther) in newer kernel versions fnoble Linux - Networking 0 07-31-2003 07:49 AM
Just to make sure (slackware/newer versions) vexer Slackware 1 01-17-2003 03:28 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 12:59 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration