| View previous topic :: View next topic |
| Author |
Message |
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
 Posted: Sat Jan 03, 2015 10:51 pm Post subject: Understanding drives names |
 |
|
As many users have trouble understanding naming of their disks, here are some explains to understand it.
For the example i will use 2 controllers (an intel and adaptec) each holding 2 drives. (if you don't yet figure out it mean 4 drives, this is really going to be difficult reading for you).
The two drives for the intel are: DRIVE_I_1 and DRIVE_I_2 (assigning them some names so you will never mistake which drives i'm are speaking of).
The intel controller use ahci driver
For the adaptec: DRIVE_A_1 and DRIVE_A_2.
The adaptec controller use aacraid driver
Our /boot partition will be on DRIVE_I_2 on partition #2 and our bootloader (grub in my case) will be on the mbr of DRIVE_A_2 and our /root will be on DRIVE_A_1 partition #1, and /home will be on DRIVE_I_1 partition #3
| Code: | 00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA AHCI Controller
Subsystem: ASUSTeK Computer Inc. P5Q Deluxe Motherboard
Kernel driver in use: ahci
01:00.0 RAID bus controller: Adaptec AAC-RAID (rev 09)
Subsystem: Adaptec 5405
Kernel driver in use: aacraid
|
DRIVE_A_1: partition #1 /root
DRIVE_A_2: not even a partition is need, we install grub in its mbr
DRIVE_I_1: partition #1 & #2 something, partition #3 /home
DRIVE_I_2: partition #1 something, partition #2: /boot
BIOS:
Bios list drives by controller detecting order and per drive attach to each controller.
It depend how bios list the controllers itself, generally they list them by pci ids ; the first one should be the lowest bus id (the same order as in lspci)
So for bios, drives would be list as:
disk0: DRIVE_I_1 (because intel controller appears before adaptec controller, or in our case the adaptec is an external controller and will be handle later by the bios)
disk1: DRIVE_I_2
disk2: DRIVE_A_1
disk3: DRIVE_A_2
The bootloader:
For the bootloader, they are list by the bios "given" order list. It could be different from the bios "detected order" because of the bios option "boot from".
- if boot from is set to "boot from intel" the list will be: DRIVE_I_1, DRIVE_I_2, DRIVE_A_1, DRIVE_A_2
So for grub, it mean:
hd0: DRIVE_I_1
hd1: DRIVE_I_2
hd2: DRIVE_A_1
hd3: DRIVE_A_2
- if boot from is set to "boot from adaptec"
The list is set to: DRIVE_A_1, DRIVE_A_2, DRIVE_I_1, DRIVE_I_2
And for grub it mean:
hd0: DRIVE_A_2
hd1: DRIVE_A_1
hd2: DRIVE_I_1
hd3: DRIVE_I_2
The kernel:
Kernel assign drives letter by "first seen, first serve", so it could be different than bios or grub order.
kernel also use enumeration list by pci ids, but it also depend on what controller driver is loaded first. Just remember it if you have two controllers using the same drivers (classic for ahci controllers)
- if we have both controllers drivers build inside kernel (the adaptec is aacraid, the intel one use ahci)
first controller seen will be intel so:
sda DRIVE_I_1
sdb DRIVE_I_2
sdc DRIVE_A_1
sdd DRIVE_A_2
- if we have controller driver for adaptec set as build-in and intel one set as module:
sda DRIVE_A_1
sdb DRIVE_A_2
sdc DRIVE_I_1 (because built as module it could only appears after the adaptec)
sdd DRIVE_I_2
- if we have controller driver for adaptec set as module and intel one set as build-in: (notice as our /root is on DRIVE_A_1 this will not work, as when kernel reach the part where it should load /root the drive will not be present as the driver isn't loaded yet, kernel will complains and panic and only DRIVE_I_1 and DRIVE_I_2 partitions will be list by the kernel error message)
sda DRIVE_I_1
sdb DRIVE_I_2
sdc DRIVE_A_1
sdd DRIVE_A_2
Now let's see how we translate this mess into a working configuration:
example #1: If we set adaptec driver build-in (we must), and intel driver as build-in, bios boot is set to intel (if you boot from a disk without bootflag, bios jump on next disk until it find one valid)
grub list is now: DRIVE_I_1 (hd0), DRIVE_I_2 (hd1), DRIVE_A_1 (hd2), DRIVE_A_2 (hd3)
the grub.conf should be set as:
| Code: | root (hd1,1) <-- it should aim the /boot partition, even it's name "root", so DRIVE_I_2 is hd1 and our /boot is on its partition #2 ->> hd1,1
kernel /vmlinuz root=/dev/sdc1 <-- we aim the /root partition, as intel driver is loaded before adaptec, intel controller will steal sda and sdb, and the DRIVE_A_1 disk holding our /root partition is now sdc
|
the /etc/fstab entry
| Code: | /dev/sdb2 /boot (our /boot is on DRIVE_I_2, partition #2)
/dev/sda3 /home (our /home is on DRIVE_I_1, partition #3)
/dev/sdc1 / (our /root is on DRIVE_A_1, partition #1)
|
example #2: If we set adaptec driver build-in (we must), and intel driver as module, bios boot from is set to intel
the grub.conf should be set as:
| Code: | root (hd1,1)
kernel /vmlinuz root=/dev/sda1 <--- we aim the /root partition, but as adaptec will be loaded before intel, sda is taken by DRIVE_A_1
|
the /etc/fstab entry
| Code: | /dev/sdd2 /boot (our /boot is on DRIVE_I_2, partition #2)
/dev/sdc3 /home (our /home is on DRIVE_I_1, partition #3)
/dev/sda1 / (our /root is on DRIVE_A_2, partition #1)
|
example #3: If we set adaptec driver build-in (we must), and intel driver as build-in, bios boot is set to adaptec (this is the same case as example #1 except we set the bios to boot from the adaptec instead of intel controller)
grub list is now: DRIVE_A_1 (hd0), DRIVE_A_2 (hd1), DRIVE_I_1 (hd2), DRIVE_I_2 (hd3)
the grub.conf should be set as:
| Code: | root (hd3,1) <-- look how the DRIVE_I_2 was pushed to end of list and is now hd3.
kernel /vmlinuz root=/dev/sdc1
|
the /etc/fstab entry
| Code: | /dev/sdb2 /boot (our /boot is on DRIVE_I_2, partition #2)
/dev/sda3 /home (our /home is on DRIVE_I_1, partition #3)
/dev/sdc1 / (our /root is on DRIVE_A_1, partition #1)
|
hint: don't forget kernel list will be: DRIVE_I_1 (sda), DRIVE_I_2 (sdb), DRIVE_A_1 (sdc) and DRIVE_A_2 (sdd) because intel driver will appears before adaptec one, this case show extreme difference of kernel list and grub list of drives. And even the grub list has change from example #1 because of "boot from" was change to boot from adaptec, the kernel list itself will remain as example #1 because we didn't affect the order of how kernel will load the controllers drivers.
Common problem: booting from a livecd.
When you boot a livecd, the livecd will do its best to detect the controllers in use and load the drivers to handle them. But as you already seen, kernel list names according to "first seen" priority.
So if the livecd bootup and loaded intel drivers before the adaptec ones, adaptec disks will get sdc and sdd names (and intel ones sda sdb)
People then build grub, fstab using that info, while the info may not be correct, it depend how YOUR kernel will see them and not how the livecd kernel has seen them.
Remember:
- even if livecd see the adaptec disks itself as sdc and sdd, they could be sda and sdb when your kernel boot.
- grub names depend on "boot from" bios setting, not on how livecd see your disks.
Howto: know what disk is attach to what kernel name.
| Code: | ls -l /sys/block
total 0
lrwxrwxrwx 1 root root 0 3 janv. 11:17 sda -> ../devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:0/0:0:0:0/block/sda
lrwxrwxrwx 1 root root 0 3 janv. 11:17 sdb -> ../devices/pci0000:00/0000:00:01.0/0000:01:00.0/host0/target0:0:1/0:0:1:0/block/sdb
lrwxrwxrwx 1 root root 0 3 janv. 11:17 sdc -> ../devices/pci0000:00/0000:00:1f.2/ata5/host5/target5:0:0/5:0:0:0/block/sdc
lrwxrwxrwx 1 root root 0 3 janv. 23:04 sr0 -> ../devices/pci0000:00/0000:00:1f.2/ata6/host6/target6:0:0/6:0:0:0/block/sr0
|
You could match their ref with scsi listing of disks:
...:00.0/host0/target0:0:0/0:0:0:0/block/sda
| Code: | cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: Adaptec Model: Raptor36 Rev: V1.0
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 01 Lun: 00
Vendor: Adaptec Model: Cheetah Rev: V1.0
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 01 Id: 00 Lun: 00
Vendor: SEAGATE Model: ST3146356SS Rev: 0006
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi0 Channel: 01 Id: 01 Lun: 00
Vendor: SEAGATE Model: ST3146356SS Rev: 0005
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi0 Channel: 01 Id: 02 Lun: 00
Vendor: WDC Model: WD360ADFD-00 Rev: 20.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi0 Channel: 01 Id: 03 Lun: 00
Vendor: WDC Model: WD360ADFD-00 Rev: 20.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi5 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: WDC WD5000AADS-0 Rev: 05.0
Type: Direct-Access ANSI SCSI revision: 05
Host: scsi6 Channel: 00 Id: 00 Lun: 00
Vendor: TSSTcorp Model: CDDVDW SH-S223F Rev: SB03
Type: CD-ROM ANSI SCSI revision: 05
|
As sr0 is 6:0:0:0/block/sr0 it match Host: scsi6 Channel: 00 Id: 00 Lun: 00 so sr0 is: Vendor: TSSTcorp Model: CDDVDW SH-S223F Rev: SB03
As sdb is 0:0:1:0/block/sdb it match Host: scsi0 Channel: 00 Id: 01 Lun: 00 so sdb is: Vendor: Adaptec Model: Cheetah Rev: V1.0
Last edited by krinn on Tue Jan 06, 2015 11:35 am; edited 1 time in total |
|
| Back to top |
|
 |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Jan 05, 2015 2:28 pm Post subject: |
|
|
Nice post, krinn.
Might be worth mentioning kernel-level PARTUUID fstab parameter. ISTR that applies to MBR too, but can't recall the thread where it was discussed. Neddy knows more about it (as usual;) |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Tue Jan 06, 2015 11:34 am Post subject: |
|
|
Couldn't mention it as i don't use PARTUUID myself and don't really have the knowledge to share that so.
I use myself the /dev/disk/by-label trick for my fstab, but a bit like PARTUUID it doesn't help understanding drives naming, it help to not understand them 
And this should already be done by another doc&trick thread.
I think it still worth value to really understand how your drives names are assign ; the problem with PARTUUID is that it really target well a drive, when sometimes it could be handy to have a less strict entry (ie: ability to use many drives as boot drive... while keeping common fstab/grub conf ; per example using two external drives with same label, they may still share the same name or label while PARTUUID should be different for each ; preventing swapping them). |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jan 07, 2015 2:23 am Post subject: |
|
|
| krinn wrote: | | Couldn't mention it as i don't use PARTUUID myself and don't really have the knowledge to share that so. |
Well I extracted it from this topic to a tip here (to avoid polluting your thread;)
| Quote: | | I use myself the /dev/disk/by-label trick for my fstab, but a bit like PARTUUID it doesn't help understanding drives naming, it help to not understand them ;) I think it still worth value to really understand how your drives names are assign |
Oh absolutely; it's just that the next question people ask is "how do I make it always mount some drive at a particular point", most critically root. And PARTUUID is good because it's kernel-level, with no need for filesystem involvement, so it's more robust for the usual case.
| Quote: | | the problem with PARTUUID is that it really target well a drive, when sometimes it could be handy to have a less strict entry (ie: ability to use many drives as boot drive... while keeping common fstab/grub conf ; per example using two external drives with same label, they may still share the same name or label while PARTUUID should be different for each ; preventing swapping them). |
That seems like a corner-case by comparison to ensuring root is always what you think it is. Not knocking it: just that people should know PARTUUID first, imo, for the above reason. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
