Re: disk moves from /dev/sdd to /dev/sde
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?
This is a new one on me,m as I've never seen a device name change except a boot
time. Obviously when a new device comes on line, USB or similar, it will get a
name, but I've never seen the name change on a continuously connected device.
Therefore, it would be worth investigating carefully to see how and when this
happens. Might I suggest running a script every ten minutes or so, so you can
see what changes, and look at /var/log/messages for the time when the change
happened.
Maybe something like this, so you are sure which device is which:
#!/bin/bash
# blkdevtrc 1.1 2009-12-20 12:53:07-05 root Exp
# trace which devices are connected to which names
cd /sys/block || exit 1
# NOTE: works for real devices, not member of fakeraid
# controllers.
# Typical values for this define are "Serial" or "Capacity"
LastLine="Serial"
echo "block device trace for host $(hostname) $(date +%Y%m%d-%H%M)"
SepLine=""
for dev in sd*; do
echo "${SepLine}"
echo "Device name /dev/${dev}"
echo -n "Device connection: "
cat ${dev}/dev; echo
smartctl --all /dev/$dev | sed -n "1,/INFORMATION/d;1,/${LastLine}/p"
SepLine="=="
done
I swiped tis from my tool kit, later versions are more complex, but this will
show when a device moves, and where.
--
Bill Davidsen
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: disk moves from /dev/sdd to /dev/sde
Wolfgang S. Rupprecht wrote:
>
> Thanks. I (at the /etc/fstab level) do use a label that goes with the
> drive, mainly the lvm VG and LV names. The problem is that the lvm
> mapper *internally* must still use the name that the drive had when the
> computer first booted. It gets confused when the drive gets renamed at
> runtime (long after boot).
>
>
> Ditto. I have my machine dual ported and I'd really like eth0 to be the
> internal ethernet and eth1 to be the external. (Some programs like
> multicast progs seem to default to the first ethernet and it would be
> nice for me not to spew packets towards the public internet.)
>
I think you can address both problems with udev or HAL.
I've done it in the past, but these things are changing too fast
and with almost no documentation around.
It could be that on newer Fedora things are different.
My /etc/udev/rules.d/70-persistent-net.rules contains (xx where I removed my
data): (on Fedora 10)
# PCI device 0x8086:0x1049 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:xx:xx:xx:xx:xx", ATTR{type}=="1", NAME="eth0"
# PCI device 0x8086:0x4230 (iwl4965)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:xx:xx:xx:xx:xx", ATTR{type}=="1", NAME="wlan0"
# PCMCIA device 0x0202:0x021b (axnet_cs)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:xx:xx:xx:xx:xx", ATTR{type}=="1", NAME="eth1"
I created a /etc/udev/rules.d/11-ROB.rules for the external usb disks
containing: (on Fedora 5)
BUS=="usb", SYSFS{serial}=="5743",
SYSFS{product}=="External HDD",KERNEL=="sd?1", NAME="external_bup_disk"
BUS=="usb", SYSFS{serial}=="5744xx",
SYSFS{product}=="My Book ",KERNEL=="sd?1", NAME="external_bup_disk2"
The serial has to be found in the lshal output (a lot of output, not easy).
In both cases the NAME part is where you decide what you want to have in /dev.
--
Roberto Ragusamail at robertoragusa.it
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: disk moves from /dev/sdd to /dev/sde
On 12/16/2009 05:14 PM, Wolfgang S. Rupprecht wrote:
Rick Stevens writes:
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").
Thanks. I (at the /etc/fstab level) do use a label that goes with the
drive, mainly the lvm VG and LV names. The problem is that the lvm
mapper *internally* must still use the name that the drive had when the
computer first booted. It gets confused when the drive gets renamed at
runtime (long after boot).
Ok, if the drives are being renamed during runtime, then something else
is going on. That shouldn't happen. The only time I've seen confusion
is if the removable (USB) drive has a PV or VG name that's colliding
with one of the existing ones, and usually LVM won't let you activate
the "new" VG.
In your first post, you mentioned that the renumbering occurred after
you had added a USB drive and rebooted (the USB drive became sdd and
your internal one sde). Using UUIDs would block that completely.
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. GR! It's enough to drive one absolutely mad at
times.
Ditto. I have my machine dual ported and I'd really like eth0 to be the
internal ethernet and eth1 to be the external. (Some programs like
multicast progs seem to default to the first ethernet and it would be
nice for me not to spew packets towards the public internet.)
The solution to that is to block multicast packets on the public NIC via
iptables. Not elegant, but functional.
--
- Rick Stevens, Systems Engineer ri...@nerd.com -
- AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 -
--
- C program run. C program crash. C programmer quit. -
--
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: disk moves from /dev/sdd to /dev/sde
Rick Stevens writes:
> 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").
Thanks. I (at the /etc/fstab level) do use a label that goes with the
drive, mainly the lvm VG and LV names. The problem is that the lvm
mapper *internally* must still use the name that the drive had when the
computer first booted. It gets confused when the drive gets renamed at
runtime (long after boot).
> 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. GR! It's enough to drive one absolutely mad at
> times.
Ditto. I have my machine dual ported and I'd really like eth0 to be the
internal ethernet and eth1 to be the external. (Some programs like
multicast progs seem to default to the first ethernet and it would be
nice for me not to spew packets towards the public internet.)
-wolfgang
--
Wolfgang S. Rupprecht
If the airwaves belong to the public why does the public only get 3
non-overlapping WIFI channels?
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: disk moves from /dev/sdd to /dev/sde
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:
[r...@prophead ~]# mount | grep " / "
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
So, with that in hand, I can find the UUID:
[r...@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. GR! It's enough to drive one absolutely mad at
times.
--
- Rick Stevens, Systems Engineer ri...@nerd.com -
- AIM/Skype: therps2ICQ: 22643734Yahoo: origrps2 -
--
-If Windows isn't a virus, then it sure as hell is a carrier!-
--
--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
