Re: Improper Naming in /dev/disk/by-id and Drives Offline

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Fri, Sep 12, 2014 at 12:03 PM, Greg KH <greg@xxxxxxxxx> wrote:
> On Fri, Sep 12, 2014 at 11:52:30AM -0600, Brandon R Schwartz wrote:
>> On Wed, Sep 10, 2014 at 8:53 PM, Greg KH <greg@xxxxxxxxx> wrote:
>> > On Wed, Sep 10, 2014 at 08:34:06PM -0600, Brandon R Schwartz wrote:
>> >> Hi,
>> >>
>> >> I'm working on a particular issue (possibly two separate issues) where
>> >> our HDDs are (1) getting mislabeled in /dev/disk/by-id and (2)
>> >> dropping offline even though drive and controller logs show that the
>> >> drive is communicating and working as expected.  I don't have much
>> >> knowledge on the udev side of things so it would be great if someone
>> >> could offer some insight into the way udev assigns device names and if
>> >> there are thoughts as to why the OS cannot see the drive in certain
>> >> cases (timing issue?).
>> >>
>> >> The first issue, the mislabeling problem, is that on reboots or power
>> >> cycles we occasionally see our drives become mislabeled in
>> >> /dev/disk/by-id.  We expect to see something like:
>> >>
>> >> ata-ST3000DM001-1CH166_W1F26HKK
>> >> ata-ST3000DM001-1CH166_Z1F2FBBY
>> >>
>> >> But instead we see:
>> >>
>> >> ata-ST3000DM001-1CH166_W1F26HKK
>> >> scsi-35000c500668a9bdb
>> >>
>> >> The "scsi" drive is assigned a drive letter and the OS can communicate
>> >> with the drive.  Drives logs and controller logs show the drive is
>> >> working properly, but for some reason it's getting labeled incorrectly
>> >> in /dev/disk/by-id.  We have looked through dmesg and enabled logging
>> >> in udev (udevadm control --log-priority=debug), but we have not seen
>> >> where these labels are coming from.
>> >
>> > Sounds like blkid didn't read the uuid properly.  Is this happening in
>> > your initrd?  Is this a systemd init system, or something else?  What
>> > distro / version is this?  What kernel version is this?
>> >
>> Hi Greg,
>> The distro is RHEL 6.3 with kernel version 2.6.32.
> Then I strongly suggest you get support from Red Hat, as you are paying
> for it :)
>> We have also seen
>> the issue on a Debian based system with kernel  3.2.45.  We ran into
>> this issue again yesterday on RHEL and tested the command 'udevadm
>> trigger' and it repopulated /dev/disk/by-id with the correct
>> information.  Is there another level of debugging that we can enable
>> to see where the information might be getting read improperly?
> I don't know how RHEL is set up at all, it's such an old kernel, and
> userspace, the community can't help you out, sorry.

Haha, that is true, but we do see the failures more often on the
Debian based system.  If you think we'd be better off working with the
RHEL community or the Debian forums we'll try our luck there.  Thanks
for all the help so far!

> Work with Red Hat, you are paying them, might as well take advantage of
> it.
> good luck,
> greg k-h


Brandon Schwartz
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux Kernel]     [Linux DVB]     [Asterisk Internet PBX]     [DCCP]     [Netdev]     []     [Util Linux NG]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux