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@prophead ~]# mount | grep " / "
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
So, with that in hand, I can find the UUID:
[root@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@xxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- If Windows isn't a virus, then it sure as hell is a carrier! -
----------------------------------------------------------------------
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
