Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Understanding drives names
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4518

PostPosted: Sat Jan 03, 2015 10:51 pm    Post subject: Understanding drives names Reply with quote

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
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3177
Location: The Peanut Gallery

PostPosted: Mon Jan 05, 2015 2:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4518

PostPosted: Tue Jan 06, 2015 11:34 am    Post subject: Reply with quote

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
View user's profile Send private message
steveL
Advocate
Advocate


Joined: 13 Sep 2006
Posts: 3177
Location: The Peanut Gallery

PostPosted: Wed Jan 07, 2015 2:23 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Page 1 of 1

 
Jump to:  
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