ide drives show up as special device.

oskar · 04-10-2007, 02:55 AM

After another kernel update (feisty testing) I get this... I've had this before with single drives, but I can't figure out what it's about.

Code:

/dev/sda1               1        2627    21101346   83  Linux
/dev/sda2            9075        9729     5261287+   5  Extended
/dev/sda3   *        2628        9074    51785527+  83  Linux
/dev/sda5            9356        9729     3004123+  82  Linux swap / Solaris
/dev/sda6            9075        9355     2257069+  82  Linux swap / Solaris

Partition table entries are not in disk order

Disk /dev/sdb: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1       36481   293033601   83  Linux

Other than that I get no errors, and they mount just fine. I'm just a little confused. As I mentioned this happens every now and then, and then they just show up as hda and hdb again.

ideas?

kilgoretrout · 04-10-2007, 05:52 AM

I assume that's your fdisk-l output and you have two ide drives on hda and hdb. sda and sdb are normally associated with either sata drives, scsi drives or external usb drives, all of which operate under the scsi protocol.

These are naming conventions for humans. The kernel deals with devices based on their "type"(block or character) and their device major and minor numbers. All drives are block devices and the major and minor numbers are determined by where they are on the ide bus for ide devices or their designation under the scsi protocol for scsi, sata or usb mass storage devices. You can see the major and minor device file numbers for all recognized partitions by running:

$ cat /proc/partitions

The fact is you can create device files for any block device partition and give it whatever name you want using the mknod command and the kernel will deal with device just fine if you set it up correctly with the right major and minor numbers. For consistency there are naming conventions that are followed, however. In most modern linux systems, the udev system is responsible for generating the device file names with the right major and minor numbers. udev does this dynmically, recreating the device files every time you boot depending on what is detected. Older linux systems used a different static system where /dev/ was populated with every possible device file imaginable whether it was present or not.

Since everything works OK no matter what you get from fdisk-l, one would have to assume that this is some error in fdisk's read of the partitions. Your system must still be seeing things as hda and hdb at the kernel level otherwise fstab would have to be dynamically rewritten when things went to sda and sdb. The cat /proc/partitions output may shed some light on what's going on. Also, run:

$ mount

under the different fdisk output conditions as that will list your mounted partitions. My hunch is they will always be listed as hda, hdb format even when fdisk indicates sda, sdb.

Gethyn · 04-10-2007, 06:53 AM

This might be related to recent changes in the kernel. A large part of the IDE driver interface was rewritten, and hdx devices changed to sdx devices under the new version. This article might shed some light.

kilgoretrout · 04-10-2007, 08:35 AM

That would explain a permanent switch from hdx to sdx but not going back and forth and still having everything mount OK and run. To switch from hdx to sdx you would have to load the libata driver module and edit fstab to get proper mounting with the new sdx device files. Perhaps libata could be loading or not on a given boot up and things somehow revert to hdx later in the boot process.

oskar · 04-11-2007, 09:21 AM

Quote:

Originally Posted by kilgoretrout

I assume that's your fdisk-l output and you have two ide drives on hda and hdb. sda and sdb are normally associated with either sata drives, scsi drives or external usb drives, all of which operate under the scsi protocol.

correct.

Quote:

These are naming conventions for humans. The kernel deals with devices based on their "type"(block or character) and their device major and minor numbers. All drives are block devices and the major and minor numbers are determined by where they are on the ide bus for ide devices or their designation under the scsi protocol for scsi, sata or usb mass storage devices. You can see the major and minor device file numbers for all recognized partitions by running:

$ cat /proc/partitions

Code:

$ cat /proc/partitions
major minor  #blocks  name

   8     0   78150744 sda
   8     1   21101346 sda1
   8     2          1 sda2
   8     3   51785527 sda3
   8     5    3004123 sda5
   8     6    2257069 sda6
   8    16  293036184 sdb
   8    17  293033601 sdb1

Ok...

Quote:

The fact is you can create device files for any block device partition and give it whatever name you want using the mknod command and the kernel will deal with device just fine if you set it up correctly with the right major and minor numbers. For consistency there are naming conventions that are followed, however. In most modern linux systems, the udev system is responsible for generating the device file names with the right major and minor numbers. udev does this dynmically, recreating the device files every time you boot depending on what is detected. Older linux systems used a different static system where /dev/ was populated with every possible device file imaginable whether it was present or not.

Since everything works OK no matter what you get from fdisk-l, one would have to assume that this is some error in fdisk's read of the partitions. Your system must still be seeing things as hda and hdb at the kernel level otherwise fstab would have to be dynamically rewritten when things went to sda and sdb. The cat /proc/partitions output may shed some light on what's going on. Also, run:

$ mount

under the different fdisk output conditions as that will list your mounted partitions. My hunch is they will always be listed as hda, hdb format even when fdisk indicates sda, sdb.

Code:

$ mount
/dev/sda3 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
lrm on /lib/modules/2.6.20-14-lowlatency/volatile type tmpfs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/scd0 on /media/FARCRY_1 type udf (ro,nosuid,nodev,uid=1000)

Ok, now more strange stuff.
/dev/hdb1 does not exist.

Code:

$ ls /dev/hdb1
ls: /dev/hdb1: No such file or directory

sdb1 does, so that's how I mount it.

The ubuntu people probably saw something like that coming, so in the default fstab entrys the disks are defined by UUID.

Code:

cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/hda3
UUID=31d56145-8404-4c1b-97e0-b1f132d54642 /               ext3    defaults,errors=remount-ro 0       1
# /dev/hda6
UUID=4dc3e617-58cb-48c2-b876-048994236ee3 none            swap    sw              0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0

Quote:

Originally Posted by Gethyn

This might be related to recent changes in the kernel. A large part of the IDE driver interface was rewritten, and hdx devices changed to sdx devices under the new version. This article might shed some light.

Note to self: read all commments before replying.
Yes that makes sense. But that's not good. I really hope they'll fix that. Otherwise there'll be some people like me who take naming conventions for granted and erase sda1 while trying to format their usb stick. Not to mention all the mounting errors after a distribution upgrade.

thanks for the informative post, Trout.

Eliot Rosewater