Udev rules for identical hard drives
 

Hi there!

I do not understand the numbering of my hard drives. There may be some
inherent logic, but whenever I make some changes, like replacing drives,
or changing BIOS settings, the order changes. Maybe it's even more random.

So I made some udev rules like this, and my drives are called /dev/hd1,
hd2 and hd3:

SUBSYSTEMS=="scsi", KERNEL=="sd?", ATTRS{model}=="SAMSUNG HD154UI",
SYMLINK="hd1"

This works fine, and this way I can address them in scripts, smartd and
hdparm config files and such. But now I have two identical drives. I had
this before with the drive above, but while being identical models, the
two drives differed a little in size, so I just had to add ATTR{size}.
This does not help with my current drives, and I find nothing
in /sys/block/sd?/device/ that differs. Could there be another way to
distinguish the drives, like looking at the partition scheme or something?

Wonko

Udev rules for identical hard drives
 

On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko@wonkology.org> wrote:
> Hi there!
>
> I do not understand the numbering of my hard drives. There may be some
> inherent logic, but whenever I make some changes, like replacing drives,
> or changing BIOS settings, the order changes. Maybe it's even more random.
>
> So I made some udev rules like this, and my drives are called /dev/hd1,
> hd2 and hd3:
>
> SUBSYSTEMS=="scsi", KERNEL=="sd?", ATTRS{model}=="SAMSUNG HD154UI",
> SYMLINK="hd1"
>
> This works fine, and this way I can address them in scripts, smartd and
> hdparm config files and such. But now I have two identical drives. I had
> this before with the drive above, but while being identical models, the
> two drives differed a little in size, so I just had to add ATTR{size}.
> This does not help with my current drives, and I find nothing
> in /sys/block/sd?/device/ that differs. Could there be another way to
> distinguish the drives, like looking at the partition scheme or something?

If you want to distinguish partitions, I would recommend using labels
(in fstab too); those never change unless you specifically change
them. Then, no matter how you put them in your machine, they will get
mounted correctly, and then you don't need to fuzz with udev rules.
Also, as a superficial bonus, they get mounted using the label and it
looks nice in your file browser.

The drives themselves I see no reason to recognize them, why do you
need to do that?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e IngenierÃ*a de la Computación
Universidad Nacional Autónoma de México


Thu Aug 2 02:30:01 2012
Return-Path: <anaconda-devel-list-bounces@redhat.com>
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
eagle542.startdedicated.com
X-Spam-Level:
X-Spam-Status: No, score=-4.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_HI,SPF_HEL O_PASS,SPF_PASS,
T_DKIM_INVALID,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-Original-To: tom@linux-archive.org
Delivered-To: tom-linux-archive.org@eagle542.startdedicated.com
Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24])
by eagle542.startdedicated.com (Postfix) with ESMTP id C9A8C20E02CF
for <tom@linux-archive.org>; Thu, 2 Aug 2012 02:07:28 +0200 (CEST)
Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33])
by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7204YZV016395;
Wed, 1 Aug 2012 20:04:36 -0400
Received: from int-mx02.intmail.prod.int.phx2.redhat.com
(int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id q7204Xpi016109
for <anaconda-devel-list@listman.util.phx.redhat.com>;
Wed, 1 Aug 2012 20:04:33 -0400
Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com
[10.5.110.19])
by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
id q7204Sb9025962
for <anaconda-devel-list@redhat.com>; Wed, 1 Aug 2012 20:04:28 -0400
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com
[74.125.82.174])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7204RNF008867
for <anaconda-devel-list@redhat.com>; Wed, 1 Aug 2012 20:04:27 -0400
Received: by weyx8 with SMTP id x8so6216779wey.33
for <anaconda-devel-list@redhat.com>;
Wed, 01 Aug 2012 17:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=CTEgHemZmmwEqa4RYl2fOOsOHe139JdnC6ZeFHIYJuk=;
b�3oisTTLlRztm1LVG41hjZCJ80mMf1rfNMTY44KdVoL727C HONyNkONbHz/kwXt
QkTqUBuWIhC0wq8ltyStaZjDp/de2KrQ2kg6HoUbTuIU5YlbF4vdvhNbZkWXZ9jzym1f
zXdeInHWG/KhP7eqzCEepaPFYT0S/Pn4Od3H/SijWr7IEhVqXoeTQQYWCcjdUoeSfYOe
ONfdSfhz28NcGQcPSAN14gYuBZa6AIvcZOs8SxTMJ1iNivApEM 12O66bgQ41oTWbcvyy
4yL2UKvdGR7702bllhLRZ5TiHQlTXhQP8s/Z88n9VMUcYnVFvtN4pAHMm9CPQZuvnaHU
jEqQ=Received: by 10.180.84.1 with SMTP id u1mr20428787wiy.15.1343865866644;
Wed, 01 Aug 2012 17:04:26 -0700 (PDT)
Received: from localhost.localdomain (85-220-55-128.dsl.dynamic.simnet.is.
[85.220.55.128])
by mx.google.com with ESMTPS id fr4sm12669092wib.8.2012.08.01.17.04.15
(version=TLSv1/SSLv3 cipher=OTHER);
Wed, 01 Aug 2012 17:04:25 -0700 (PDT)
Message-ID: <5019C3CC.2080000@gmail.com>
Date: Thu, 02 Aug 2012 00:03:24 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==? <johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:14.0) Gecko/20120717 Thunderbird/14.0
MIME-Version: 1.0
To: anaconda-devel-list@redhat.com
Subject: Re: Key installer functionality for F18: rescue mode, text/serial
console mode
References: <1343677980.6396.92.camel@adam>
<20120801150154.GO26765@exeter.usersys.redhat.co m>
<50194A41.9030407@gmail.com>
<20120801153333.GQ26765@exeter.usersys.redhat.co m>
<501951CA.4030204@gmail.com> <1343849719.6396.159.camel@adam>
In-Reply-To: <1343849719.6396.159.camel@adam>
X-RedHat-Spam-Score: -2.7 (BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU,
FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS)
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
X-Scanned-By: MIMEDefang 2.68 on 10.5.110.19
X-loop: anaconda-devel-list@redhat.com
X-BeenThere: anaconda-devel-list@redhat.com
X-Mailman-Version: 2.1.12
Precedence: junk
Reply-To: Discussion of Development and Customization of the Red Hat Linux
Installer <anaconda-devel-list@redhat.com>
List-Id: Discussion of Development and Customization of the Red Hat Linux
Installer <anaconda-devel-list.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/anaconda-devel-list>,
<mailto:anaconda-devel-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/anaconda-devel-list>
List-Post: <mailto:anaconda-devel-list@redhat.com>
List-Help: <mailto:anaconda-devel-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/anaconda-devel-list>,
<mailto:anaconda-devel-list-request@redhat.com?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: anaconda-devel-list-bounces@redhat.com
Errors-To: anaconda-devel-list-bounces@redhat.com

On 08/01/2012 07:35 PM, Adam Williamson wrote:
> So it would help to direct the discussion if those who are worried about
> losing rescue mode define more precisely exactly what they feel we lose
> by dropping it. That'll help us in determining exactly what is needed to
> compensate for it.

Exactly that "dropping it" which results in users having to keep in
handy an additional media if shit hits the fan

Now the exact thing that is needed ( for now ) to compensate my worries
for alpha is a grub entry called "Rescue" or "Fedora Rescue" which
contains "rd.break" without having the reporter to "know" that kernel
parameter off hand but instead offers him a select-able entry so we can
start gathering feedback from reporters in as painless manner as possible.

There are couple of issues that I'm aware of and will be discussing with
Harald which I personally would like to see resolved before we use this
as a replacement either altogether or until a noob friendly gui mode is
implemented.

JBG

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Udev rules for identical hard drives
 

On Wed, Aug 1, 2012 at 6:59 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko@wonkology.org> wrote:
>> Hi there!
>>
>> I do not understand the numbering of my hard drives. There may be some
>> inherent logic, but whenever I make some changes, like replacing drives,
>> or changing BIOS settings, the order changes. Maybe it's even more random.
>>
>> So I made some udev rules like this, and my drives are called /dev/hd1,
>> hd2 and hd3:
>>
>> SUBSYSTEMS=="scsi", KERNEL=="sd?", ATTRS{model}=="SAMSUNG HD154UI",
>> SYMLINK="hd1"
>>
>> This works fine, and this way I can address them in scripts, smartd and
>> hdparm config files and such. But now I have two identical drives. I had
>> this before with the drive above, but while being identical models, the
>> two drives differed a little in size, so I just had to add ATTR{size}.
>> This does not help with my current drives, and I find nothing
>> in /sys/block/sd?/device/ that differs. Could there be another way to
>> distinguish the drives, like looking at the partition scheme or something?
>
> If you want to distinguish partitions, I would recommend using labels
> (in fstab too); those never change unless you specifically change
> them. Then, no matter how you put them in your machine, they will get
> mounted correctly, and then you don't need to fuzz with udev rules.
> Also, as a superficial bonus, they get mounted using the label and it
> looks nice in your file browser.
>
> The drives themselves I see no reason to recognize them, why do you
> need to do that?

Oh, and I forgot; doesn't the links in /dev/disk/by-id,
/dev/disk/by-label, /dev/disk/by-uuid do what you want to?

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Udev rules for identical hard drives
 

Canek Peláez Valdés writes:

> On Wed, Aug 1, 2012 at 6:59 PM, Canek Peláez Valdés <caneko@gmail.com>
> wrote:
> > On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko@wonkology.org>
> > wrote:
[...]
> >> Could there be another way to distinguish the drives, like looking
> >> at the partition scheme or something?
> >
> > If you want to distinguish partitions, I would recommend using labels
> > (in fstab too); those never change unless you specifically change
> > them. Then, no matter how you put them in your machine, they will get
> > mounted correctly, and then you don't need to fuzz with udev rules.
> > Also, as a superficial bonus, they get mounted using the label and it
> > looks nice in your file browser.

I'm aware of that, and I would use this, if I weren't using LVM and
encryption on top of that. So I do not deal with raw partitions at all,
but with partitions like /dev/mapper/root or /dev/weird/portage.

Oh, this gives me an idea of what to use as workaround: If what I would
like to have is not possible, I will add a little start script
in /etc/local.d/ which calls pvscan to check which volume groups belong
to which drives, and creates the symlinks.

> > The drives themselves I see no reason to recognize them, why do you
> > need to do that?

Well, I don't really *need* this. But it's convenient.

- I have a monitoring plasmoid on my desktop that shows whether a drive
is active or on standby, and also gives the temperature of my always
running system drive. If there were a mixup, calling hddtemp on a
sleeping drive would wake it up.

- I have different idle time settings in /etc/conf.d/hdparm, and I spin
down two drives immediately after I have booted.

- Same goes for a little script I use for suspend-to-ram. It makes use of
the rtcwake command to make the PC wake up in the morning (before I get
up), and along other stuff spins down drives.

- And I have different settings in /etc/smartd.conf.

> Oh, and I forgot; doesn't the links in /dev/disk/by-id,
> /dev/disk/by-label, /dev/disk/by-uuid do what you want to?

Those seem to list partitions only, not whole drives. A label for a drive
would be nice to have.

Uh, and here's the little start script I just wrote. No idea why I call
my drives hd1 to hd4 instead of using the name of the only volume group
they have, but I'll keep it like that for now.

str=$( pvscan )

hd()
{
hd=$( echo "$str" | grep "$1" | head -n 1 | awk '{print $2}' )
echo ${hd//[0-9]/}
}

ln -s $( hd "weird " ) /dev/hd1
ln -s $( hd "weird2" ) /dev/hd2
ln -s $( hd "weird3" ) /dev/hd3
ln -s $( hd "pata1" ) /dev/hd4


Wonko

Udev rules for identical hard drives
 

On Wed, Aug 1, 2012 at 7:42 PM, Alex Schuster <wonko@wonkology.org> wrote:
> Canek Peláez Valdés writes:
[ snip ]
>> Oh, and I forgot; doesn't the links in /dev/disk/by-id,
>> /dev/disk/by-label, /dev/disk/by-uuid do what you want to?
>
> Those seem to list partitions only, not whole drives. A label for a drive
> would be nice to have.

I'm pretty sure whole drives are there also:

$ ll /dev/disk/by-id
...
ata-SAMSUNG_HD160JJ_S08HJ10YC13279 -> ../../sda
...

That's a whole drive right there.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Udev rules for identical hard drives
 

Canek Peláez Valdés writes:

> On Wed, Aug 1, 2012 at 7:42 PM, Alex Schuster <wonko@wonkology.org>
> wrote:
> > Canek Peláez Valdés writes:
> [ snip ]
> >> Oh, and I forgot; doesn't the links in /dev/disk/by-id,
> >> /dev/disk/by-label, /dev/disk/by-uuid do what you want to?
> >
> > Those seem to list partitions only, not whole drives. A label for a
> > drive would be nice to have.
>
> I'm pretty sure whole drives are there also:
>
> $ ll /dev/disk/by-id
> ...
> ata-SAMSUNG_HD160JJ_S08HJ10YC13279 -> ../../sda
> ...
>
> That's a whole drive right there.

Wow, now I feel really stupid :) You are so right, they are there, and I
don't why I overlooked them... too many entries there maybe, I have 140.
But still. Stuuupid!

Thanks, Canek!

Wonko

Udev rules for identical hard drives
 

Alex Schuster writes:

> Canek Peláez Valdés writes:

> > $ ll /dev/disk/by-id
> > ...
> > ata-SAMSUNG_HD160JJ_S08HJ10YC13279 -> ../../sda
> > ...
> >
> > That's a whole drive right there.
>
> Wow, now I feel really stupid :) You are so right, they are there, and I
> don't why I overlooked them... too many entries there maybe, I have 140.
> But still. Stuuupid!

I looked again in the terminal at what I did this night, and at least
feel a little less stupid now. I had searched for my /dev/sdd drive, and
this one just has no label. Only its partitions do, they appear twice, as
ata-SAMSUNG_SP1614N_0735J1FW815459-part[15678] and
wwn-0x50f0000000000000-part[15678].

This drive is an older PATA drive, maybe that's the difference?

Wonko

Udev rules for identical hard drives
 

On Thu, Aug 2, 2012 at 3:38 AM, Alex Schuster <wonko@wonkology.org> wrote:
> Alex Schuster writes:
>
>> Canek Peláez Valdés writes:
>
>> > $ ll /dev/disk/by-id
>> > ...
>> > ata-SAMSUNG_HD160JJ_S08HJ10YC13279 -> ../../sda
>> > ...
>> >
>> > That's a whole drive right there.
>>
>> Wow, now I feel really stupid :) You are so right, they are there, and I
>> don't why I overlooked them... too many entries there maybe, I have 140.
>> But still. Stuuupid!
>
> I looked again in the terminal at what I did this night, and at least
> feel a little less stupid now. I had searched for my /dev/sdd drive, and
> this one just has no label. Only its partitions do, they appear twice, as
> ata-SAMSUNG_SP1614N_0735J1FW815459-part[15678] and
> wwn-0x50f0000000000000-part[15678].
>
> This drive is an older PATA drive, maybe that's the difference?
>
> Wonko
>

Check out the very nice 'lsdrv' script by Phil Turmel. Run it, save a
copy of the output for bad times.

https://github.com/pturmel/lsdrv

HTH,
Mark

Udev rules for identical hard drives
 

Mark Knecht writes:

> Check out the very nice 'lsdrv' script by Phil Turmel. Run it, save a
> copy of the output for bad times.
>
> https://github.com/pturmel/lsdrv

That doesn't work here, and I do not understand why. In line 305 it tries
and fails to create /dev/block, which is already existing.

if not os.path.exists('/dev/block'):
os.mkdir('/dev/block', 0755)

Uh, is this a python bug? It works fine with python 2.7, but not with
3.2. But os.path.exists() is quite a basic function, if that wouldn't
work, I'd expect all things to break, including emerge.

Nice script. Much similar to lshw I think, but it shows more stuff, like
LVM names and UUIDS. Thanks!

Wonko

Udev rules for identical hard drives
 

Alex Schuster wrote:
> Mark Knecht writes:
>
>> Check out the very nice 'lsdrv' script by Phil Turmel. Run it, save a
>> copy of the output for bad times.
>>
>> https://github.com/pturmel/lsdrv
> That doesn't work here, and I do not understand why. In line 305 it tries
> and fails to create /dev/block, which is already existing.
>
> if not os.path.exists('/dev/block'):
> os.mkdir('/dev/block', 0755)
>
> Uh, is this a python bug? It works fine with python 2.7, but not with
> 3.2. But os.path.exists() is quite a basic function, if that wouldn't
> work, I'd expect all things to break, including emerge.
>
> Nice script. Much similar to lshw I think, but it shows more stuff, like
> LVM names and UUIDS. Thanks!
>
> Wonko
>
>


I'm amd64 and it works here.

root@fireball / # equery l python
* Searching for python ...
[IP-] [ ] dev-lang/python-2.7.3-r2:2.7
[IP-] [ ] dev-lang/python-3.2.3:3.2
root@fireball / #

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!