Disk blockdevice detecting order scrambled after every boot

TCH · 2023-01-29 14:54:24

Hello there,

For the last 11 years, Ubuntu 10.04, Debian 7, Debian 8 and finally Devuan 2 all detected my disk devices in this order (save for Ubuntu, when i did not have the SSD-s yet, but the disk detecting order was constant there too):
/dev/sda: primary SSD where the system resides
/dev/sdb: secondary SSD where i back up the system with rsync regularly
/dev/sdc: secondary HDD where i back up the data with rsync regularly
/dev/sdd: primary HDD where the data resides
This order was constant, it never changed. This is the same order as the disks are plugged into the motherboard. (Yes, this is the same motherboard from 2012.) Clean, obvious, logical. Working.

A few days ago i've upgraded to Devuan 4 and now the order is entirely random. At every boot.
I tried to check how can i set up a persistent order, but all i found is how to write fstab entries by disk id; but this is not a partition problem, it is a disk blockdevice detecting order problem, it cannot be solved from fstab.

Any tips on this?

Head_on_a_Stick · 2023-01-29 15:31:27

PSA: I've already told the OP that this is the normal, expected behaviour (unless I'm wrong):

https://daemonforums.org/showthread.php?t=12340

TCH · 2023-01-29 15:46:24

Well, the order was the same for 11 years, across several versions of several distributions, including Devuan. Is there a chance that this was only coincidence?

fsmithred · 2023-01-29 18:34:09

TCH wrote:

Well, the order was the same for 11 years, across several versions of several distributions, including Devuan. Is there a chance that this was only coincidence?

Yes, there's a chance it's coincidence. I've gotten away with using device names instead of uuids many times, even though the recommendation to use uuids in fstab goes back to some older version of debian that pre-dates devuan. I forget which one. (squeeze? wheezy?)

rolfie · 2023-01-29 20:22:22

Can only recommend to use UUIDs or labels, everything else is coincidence. Device detection order is ambiguous since a while already.

TCH · 2023-01-29 23:35:11

What could cause that the order only started to be random after upgrading to Devuan 4?

ralph.ronnquist · 2023-01-30 02:44:17

I guess it would be kernel related since it's the kernel modules that invent the names.

Or, does the naming coincide with PCI numbering?
Eg that the PCI address for /dev/sda is lesser than the PCI address for /dev/sdb ?

TCH · 2023-01-30 09:57:24

But the PCI addresses should be the same as they are connected to the same slot, should not they?

Footnote: today "morning" (1:30-2:00 AM) i rewrote my backup script. Now it backups via the disklabels and i simply give the labels in a list, so the random order is no longer a concern.

Still, out of technological curiousity, i would like to know, why was it constant for 11 years and why it is random now.

ralph.ronnquist · 2023-01-30 11:22:15

I would hope the PCI enumeration is the same, but I would also check rather than just guessing.
Though I suppose it doesn't matter any more.

rolfie · 2023-01-30 11:45:09

Maybe I am wrong, but I think it is because the "enumeration" has been parallelised instead of looking at ata, then scsi, then usb in serial order. And since usb has become more important over the years chances are much higher nowadays that additional usb devices pop up as block devices.

Edith: Just checked, I already had issues with that when setting up my file server with Debian 3 Sarge. Adding/removing a scsi disk screwed the device naming, in my early Linux days I started to use uuid.

Last edited by rolfie (2023-01-30 11:55:56)

TCH · 2023-01-30 19:29:20

ralph.ronnquist wrote:

I would hope the PCI enumeration is the same, but I would also check rather than just guessing.
Though I suppose it doesn't matter any more.

How can i check this? lspci?

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD9x0/RX980 Host Bridge (rev 02)
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD/ATI] RD890S/RD990 I/O Memory Management Unit (IOMMU)
00:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GFX port 0)
00:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 0)
00:05.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 1)
00:09.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 4)
00:0a.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RD890/RD9x0/RX980 PCI to PCI bridge (PCI Express GPP Port 5)
00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)
00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 SMBus Controller (rev 42)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 LPC host controller (rev 40)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller
00:15.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] SB700/SB800/SB900 PCI to PCI bridge (PCIE port 0)
00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller
00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 15h Processor Function 5
01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GM206 High Definition Audio Controller (rev a1)
02:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
03:00.0 Parallel controller: Oxford Semiconductor Ltd Device c110
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
05:00.0 Serial controller: Device 1c00:3250 (rev 10)
06:06.0 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:06.1 Serial controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:06.2 Parallel controller: MosChip Semiconductor Technology Ltd. PCI 9865 Multi-I/O Controller
06:07.0 Multimedia controller: Philips Semiconductors SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
07:00.0 PCI bridge: Tundra Semiconductor Corp. Tsi381 PCIe to PCI Bridge (rev 02)
08:00.0 Multimedia audio controller: Creative Labs CA0108/CA10300 [Sound Blaster Audigy Series]

It does not shows the SATA disks separately, just the controller.

rolfie wrote:

Maybe I am wrong, but I think it is because the "enumeration" has been parallelised instead of looking at ata, then scsi, then usb in serial order. And since usb has become more important over the years chances are much higher nowadays that additional usb devices pop up as block devices.
Edith: Just checked, I already had issues with that when setting up my file server with Debian 3 Sarge. Adding/removing a scsi disk screwed the device naming, in my early Linux days I started to use uuid.

But all my disks are SATA (even the DVD drives) and they are unchanged for years.

ralph.ronnquist · 2023-01-30 22:37:20

To get an association table between PCI address and device node name, I think I might do:

ralph@stolpe:~$ realpath /sys/class/block/sd?/ 
/sys/devices/pci0000:00/0000:00:1f.2/ata5/host4/target4:0:0/4:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sdb
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.1/2-1.1:1.0/host6/target6:0:0/6:0:0:0/block/sdc
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.4/2-1.4:1.0/host7/target7:0:0/7:0:0:0/block/sdd
/sys/devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1.2/2-1.2:1.0/host8/target8:0:0/8:0:0:0/block/sde

My example case shows 2 SATA disks and 3 USB disks. You may note that sdd and sde got enumerated in "wrong" order by the scsi module (relative to the USB host/port enumeration) for some reason. This appears to be consistent for that setup, but on occasion sdc and sdd are swapped, which is something I deal with by repeated monkey handson (= unplug+plugin) until order returns.

As @rolfie noted, the reason those "reorderings" happen is probably because the kernel+module code is multi-threaded with separate threads handling separate devices independently and these threads then compete and synchronize about "acquire the next device node name" on a first-come, first-served basis.

The answer to why it turns up as a new thing for you would probably be that the kernel+module code involved has been updated to include a more refined multi-threading in one way or another. Or, it might be hardware related that something has changed with some parts of the hardware due to aging, causing the startup timings to be slightly different now compared to how they have been previously. I think we can agree to that magic is not involved.

TCH · 2023-01-31 12:37:44

This is what realpath /sys/class/block/sd?/ gave back:

/sys/devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sda
/sys/devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sdb
/sys/devices/pci0000:00/0000:00:11.0/ata3/host2/target2:0:0/2:0:0:0/block/sdc
/sys/devices/pci0000:00/0000:00:11.0/ata4/host3/target3:0:0/3:0:0:0/block/sdd
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:0/block/sde
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:1/block/sdf
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:2/block/sdg
/sys/devices/pci0000:00/0000:00:12.2/usb1/1-3/1-3:1.0/host6/target6:0:0/6:0:0:3/block/sdh

Note: When i've ran this command, the order was correct.

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 119,2G  0 disk 
└─sda1   8:1    0 119,2G  0 part /
sdb      8:16   0 119,2G  0 disk 
└─sdb1   8:17   0 119,2G  0 part 
sdc      8:32   0 465,8G  0 disk 
├─sdc1   8:33   0     8G  0 part [SWAP]
├─sdc3   8:35   0    64G  0 part 
├─sdc4   8:36   0 137,8G  0 part 
├─sdc5   8:37   0   128G  0 part 
└─sdc6   8:38   0   128G  0 part 
sdd      8:48   0 465,8G  0 disk 
├─sdd1   8:49   0     8G  0 part [SWAP]
├─sdd3   8:51   0    64G  0 part /media/GAMEDISK
├─sdd4   8:52   0 137,8G  0 part /media/WORKDISK
├─sdd5   8:53   0   128G  0 part /media/UTILDISK
└─sdd6   8:54   0   128G  0 part /media/SOFTDISK
sr0     11:0    1  1024M  0 rom  
sr1     11:1    1  1024M  0 rom

I suspect i need to compare this to that, when the order will be scrambled up.

ralph.ronnquist wrote:

The answer to why it turns up as a new thing for you would probably be that the kernel+module code involved has been updated to include a more refined multi-threading in one way or another.

That might be the reason.

ralph.ronnquist wrote:

Or, it might be hardware related that something has changed with some parts of the hardware due to aging, causing the startup timings to be slightly different now compared to how they have been previously.

That could be a reason, but why it only occurred after the update? Coincidence? Again? The other reason seems more likely.

ralph.ronnquist wrote:

I think we can agree to that magic is not involved.

It was never hypothesised at all.

The officially official Devuan Forum!

#1 2023-01-29 14:54:24

Disk blockdevice detecting order scrambled after every boot

#2 2023-01-29 15:31:27

Re: Disk blockdevice detecting order scrambled after every boot

#3 2023-01-29 15:46:24

Re: Disk blockdevice detecting order scrambled after every boot

#4 2023-01-29 18:34:09

Re: Disk blockdevice detecting order scrambled after every boot

#5 2023-01-29 20:22:22

Re: Disk blockdevice detecting order scrambled after every boot

#6 2023-01-29 23:35:11

Re: Disk blockdevice detecting order scrambled after every boot

#7 2023-01-30 02:44:17

Re: Disk blockdevice detecting order scrambled after every boot

#8 2023-01-30 09:57:24

Re: Disk blockdevice detecting order scrambled after every boot

#9 2023-01-30 11:22:15

Re: Disk blockdevice detecting order scrambled after every boot

#10 2023-01-30 11:45:09

Re: Disk blockdevice detecting order scrambled after every boot

#11 2023-01-30 19:29:20

Re: Disk blockdevice detecting order scrambled after every boot

#12 2023-01-30 22:37:20

Re: Disk blockdevice detecting order scrambled after every boot

#13 2023-01-31 12:37:44

Re: Disk blockdevice detecting order scrambled after every boot

Board footer