Summary: | wrong /dev/sdx assignments with gentoo-sources-2.6.34-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Marco DR <marco.dr> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | linux-2.6.34-regression | ||
Package list: | Runtime testing required: | --- |
Description
Marco DR
2010-07-12 20:46:39 UTC
Maybe 2.6.34 behaves as it should. afaik kernel looks on bios device order before we assigns letters to the drives If this were true, how do you explain the order given to the scsi devices? With kernel 2.6.34, I have: sd 0:0:0:0: [sda] (sata disk 1) sd 1:0:0:0: [sdb] (sata disk 2) sd 9:0:0:0: [sdc] (card reader device 1) sd 9:0:0:1: [sdd] (card reader device 2) sd 9:0:0:2: [sde] (card reader device 3) sd 9:0:0:3: [sdf] (card reader device 4) sd 2:0:0:0: [sdg] (sata disk 3) the numbers (0,1,9,2) assigned to the scsi devices do not correspond to the letters chosen by the kernel (a,b,c...). It seems like two kernel components (AHCI and USB_STORAGE) take the letters concurrently, "first come first served". (In reply to comment #2) > If this were true, how do you explain the order given to the scsi devices? With > kernel 2.6.34, I have: > > sd 0:0:0:0: [sda] (sata disk 1) > sd 1:0:0:0: [sdb] (sata disk 2) > sd 9:0:0:0: [sdc] (card reader device 1) > sd 9:0:0:1: [sdd] (card reader device 2) > sd 9:0:0:2: [sde] (card reader device 3) > sd 9:0:0:3: [sdf] (card reader device 4) > sd 2:0:0:0: [sdg] (sata disk 3) > > the numbers (0,1,9,2) assigned to the scsi devices do not correspond to the > letters chosen by the kernel (a,b,c...). It seems like two kernel components > (AHCI and USB_STORAGE) take the letters concurrently, "first come first > served". > Due to asynchronous probing you can't guarantee that device names will be intuitionally ordered. This is not much of a problem though since you can easily manage device nodes using udev. Even though this might look like a regression, this is not a bug and I'd suggest you use udev with labels or uuids to control your device nodes instead of relying on the kernel :) |