disk moves from /dev/sdd to /dev/sde

[Rick Stevens]

On 12/16/2009 02:03 PM, Wolfgang S. Rupprecht wrote:
>
> I'm seeing something strange where a disk appears to change from
> /dev/sdd to /dev/sde under f12.  I have a motherboard (Asus M3A78T) that
> appears to have multiple onboard disk controllers.  When I boot with no
> external storage plugged into the USB, my hard disks are assigned sda,
> sdb, sdc sdd.  When I boot with, say, a flash drive, camera or cell
> phone attached the external device gets the "sdd" name and my last disk
> gets the name sde.  Now, that in itself doesn't cause any problems
> because I don't have the disk sdX names wired into anything.
>
> What is a problem is that after booting, something unknown (perhaps an
> ATA reset?) causes the disk letters to be re-assigned just as if it was
> at boot time.  If I have some flash-like external storage plugged in my
> last disk gets shifted to /dev/sde.  At that point programs like
> smartmon that are looking at the disk under the old name fail to find it
> and generate an error.  "smartmon -a /dev/sde" does show the disk under
> it's new name, but even the kernel appears to look for the disk under
> its old name.  I see lots of the following mailed to me by chron:
>
>    /etc/cron.hourly/zzzdo-backup:
>
>      /dev/dm-0: read failed after 0 of 4096 at 0: Input/output error
>      /dev/dm-0: read failed after 0 of 4096 at 0: Input/output error
>
> How do I nail down the disk numbering a bit tighter so that things don't
> move around after boot-time?

The only way to ensure you're talking to the same drive is to use its
UUID.  Most filesystems and devices on Fedora now have UUIDs associated
with them and most of the necessary utilities support it.  For example,
your /etc/fstab can specify a device either via device name (/dev/sda1),
label ("LABEL=somelabel") or UUID ("UUID=weird-hex-string").

To find the UUID on your devices, try:

     /lib/udev/vol_id /path/to/device

For example, to find where the root filesystem is on my machine:

     [root at prophead ~]# mount | grep " / "
     /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)

So, with that in hand, I can find the UUID:

     [root at prophead ~]# /lib/udev/vol_id /dev/mapper/VolGroup00-LogVol00
     ID_FS_USAGE=filesystem
     ID_FS_TYPE=ext3
     ID_FS_VERSION=1.0
     ID_FS_UUID=f07b9552-a738-4e07-9319-150939a5cd42
     ID_FS_UUID_ENC=f07b9552-a738-4e07-9319-150939a5cd42
     ID_FS_LABEL=
     ID_FS_LABEL_ENC=

So I could use the data in "ID_FS_UUID" to uniquely identify my root
filesystem, regardless of how the system re-enumerates my drives.  In
fact, the first mount line of my /etc/fstab reads:

     UUID=f07b9552-a738-4e07-9319-150939a5cd42  /  ext3  defaults 1 1

Anaconda built that line during the installation.  Other utilities
(without UUID support) can then refer to the mountpoint and be assured
they're talking to the right things.

Perhaps there's an easier way, but this has always been an issue with
newer Linux kernels (since 2.4.10 or there about) and the conversion to
"all block devices are treated as SCSI now" has only exacerbated things.

I sure wish there was a standard on the order in which things get
scanned.  Even network NICs vary.  On Dell 1850s and 1950s, the PCI bus
was scanned for NICs before the on-board stuff, so any PCI NICs got the
first "ethX" numbers.  The bigger 2850/2950 machines scanned the
on-boards first.  GRRRRR!  It's enough to drive one absolutely mad at
times.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer                      ricks at nerd.com -
- AIM/Skype: therps2        ICQ: 22643734            Yahoo: origrps2 -
-                                                                    -
-    If Windows isn't a virus, then it sure as hell is a carrier!    -
----------------------------------------------------------------------