Mailing List Archive: Gentoo: User

Udev rules for identical hard drives

Index | Next | Previous | View Threaded

wonko at wonkology

Aug 1, 2012, 4:34 PM

Post #1 of 22 (867 views)
Permalink

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

caneko at gmail

Aug 1, 2012, 4:59 PM

Post #2 of 22 (852 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko [at] wonkology> 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

caneko at gmail

Aug 1, 2012, 5:01 PM

Post #3 of 22 (850 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Wed, Aug 1, 2012 at 6:59 PM, Canek Peláez Valdés <caneko [at] gmail> wrote:
> On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko [at] wonkology> 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

wonko at wonkology

Aug 1, 2012, 5:42 PM

Post #4 of 22 (886 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Canek Pel�ez Vald�s writes:

> On Wed, Aug 1, 2012 at 6:59 PM, Canek Pel�ez Vald�s <caneko [at] gmail>
> wrote:
> > On Wed, Aug 1, 2012 at 6:34 PM, Alex Schuster <wonko [at] wonkology>
> > 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

caneko at gmail

Aug 1, 2012, 5:53 PM

Post #5 of 22 (850 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Wed, Aug 1, 2012 at 7:42 PM, Alex Schuster <wonko [at] wonkology> 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

wonko at wonkology

Aug 2, 2012, 2:20 AM

Post #6 of 22 (843 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Canek Pel�ez Vald�s writes:

> On Wed, Aug 1, 2012 at 7:42 PM, Alex Schuster <wonko [at] wonkology>
> 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

wonko at wonkology

Aug 2, 2012, 3:38 AM

Post #7 of 22 (841 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

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

markknecht at gmail

Aug 2, 2012, 6:11 AM

Post #8 of 22 (840 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, Aug 2, 2012 at 3:38 AM, Alex Schuster <wonko [at] wonkology> 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

wonko at wonkology

Aug 2, 2012, 8:02 AM

Post #9 of 22 (841 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

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

rdalek1967 at gmail

Aug 2, 2012, 8:50 AM

Post #10 of 22 (838 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

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 [at] firebal / # 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 [at] firebal / #

Dale

:-) :-)

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

markknecht at gmail

Aug 2, 2012, 8:50 AM

Post #11 of 22 (842 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, Aug 2, 2012 at 8:02 AM, Alex Schuster <wonko [at] wonkology> 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
>

Dunno about the python-3.2 thing. Are you set to use 3.2 by default?
(How aggressive of you!) ;-) I'm set to use 2.7 as default which I
think is the overall recommendation of dummies like me:

c2stable ~ # eselect python list
Available Python interpreters:
[1] python2.7 *
[2] python3.2
c2stable ~ #

The script has been around awhile and updated now and again. Possibly
it's just not tested with python-3.2?

Anyway, the folks on the mdadm RAID list often ask people who had a
RAID completely fail if they had the info this script provides taken
from prior to the crash so I do it for all my machines and then keep
the output in my GMail account for safety.

HTH,
Mark

waltdnes at waltdnes

Aug 2, 2012, 9:59 AM

Post #12 of 22 (855 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, Aug 02, 2012 at 01:34:04AM +0200, Alex Schuster wrote

> 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?

You can get the ATTRS{serial} (i.e. serial number). See the printer
example at http://www.reactivated.net/writing_udev_rules.html and adapt
to your hard drive. Serial numbers should be unique, even amongst
otherwise identical drives...

======================================================================
I power on my printer, and it is assigned device node /dev/lp0. Not
satisfied with such a bland name, I decide to use udevinfo to aid me in
writing a rule which will provide an alternative name:

# udevinfo -a -p $(udevinfo -q path -n /dev/lp0)
looking at device '/class/usb/lp0':
KERNEL=="lp0"
SUBSYSTEM=="usb"
DRIVER==""
ATTR{dev}=="180:0"

looking at parent device
'/devices/pci0000:00/0000:00:1d.0/usb1/1-1':
SUBSYSTEMS=="usb"
ATTRS{manufacturer}=="EPSON"
ATTRS{product}=="USB Printer"
ATTRS{serial}=="L72010011070626380"

My rule becomes:

SUBSYSTEM=="usb", ATTRS{serial}=="L72010011070626380", SYMLINK+="epson_680"
======================================================================

--
Walter Dnes <waltdnes [at] waltdnes>

peter at humphrey

Aug 2, 2012, 10:43 AM

Post #13 of 22 (843 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thursday 02 August 2012 16:50:36 Mark Knecht wrote:

> Dunno about the python-3.2 thing. Are you set to use 3.2 by default?
> (How aggressive of you!) ;-) I'm set to use 2.7 as default which I
> think is the overall recommendation of dummies like me:

I thought so too, so I was surprised to find a few weeks ago that
something had set 3.2 as default. With 3.2 I get similar results to
Alex's but with 2.7 it works properly.

--
Rgds
Peter

wonko at wonkology

Aug 2, 2012, 10:43 AM

Post #14 of 22 (863 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Walter Dnes writes:

> You can get the ATTRS{serial} (i.e. serial number). See the printer
> example at http://www.reactivated.net/writing_udev_rules.html and adapt
> to your hard drive. Serial numbers should be unique, even amongst
> otherwise identical drives...
>
> ======================================================================
> I power on my printer, and it is assigned device node /dev/lp0. Not
> satisfied with such a bland name, I decide to use udevinfo to aid me in
> writing a rule which will provide an alternative name:
>
> # udevinfo -a -p $(udevinfo -q path -n /dev/lp0)
> looking at device '/class/usb/lp0':
> KERNEL=="lp0"
> SUBSYSTEM=="usb"
> DRIVER==""
> ATTR{dev}=="180:0"
>
> looking at parent device
> '/devices/pci0000:00/0000:00:1d.0/usb1/1-1':
> SUBSYSTEMS=="usb"
> ATTRS{manufacturer}=="EPSON"
> ATTRS{product}=="USB Printer"
> ATTRS{serial}=="L72010011070626380"
>
> My rule becomes:
>
> SUBSYSTEM=="usb", ATTRS{serial}=="L72010011070626380",
> SYMLINK+="epson_680"

That's exactly what I would like to have! I have a working solution, but
using UDEV would seem more adequate.

But: I cannot find a serial number for my hard drives in the output. And
shouldn't there be a file named 'serial' in /sys? I have some, but not
for my block devices, only for USB and in /sys/{bus,pci}/drivers/.

BTW, sys-fs/udev-187 does not have the 'udevinfo' command, it seems to be
'udevadm info' now.

Wonko

markknecht at gmail

Aug 2, 2012, 11:28 AM

Post #15 of 22 (845 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, Aug 2, 2012 at 10:43 AM, Peter Humphrey
<peter [at] humphrey> wrote:
> On Thursday 02 August 2012 16:50:36 Mark Knecht wrote:
>
>> Dunno about the python-3.2 thing. Are you set to use 3.2 by default?
>> (How aggressive of you!) ;-) I'm set to use 2.7 as default which I
>> think is the overall recommendation of dummies like me:
>
> I thought so too, so I was surprised to find a few weeks ago that
> something had set 3.2 as default. With 3.2 I get similar results to
> Alex's but with 2.7 it works properly.
>
> --
> Rgds
> Peter
>

I haven't found any official Gentoo documentation that says we should
be using anything other than 2.7 as default.

If something changed a setting like that (during an install or
otherwise) it could be quite frustrating to find. Sorry for your
problems.

I've seen one package in an overlay that's starting to look for python-4. Scary!

Cheers,
Mark

wonko at wonkology

Aug 2, 2012, 11:29 AM

Post #16 of 22 (840 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Dale writes:

> 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.
[...]
> I'm amd64 and it works here.
>
> root [at] firebal / # 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

Um, but did you use eselect to make 3.2 the current version?

Wonko

wonko at wonkology

Aug 2, 2012, 11:47 AM

Post #17 of 22 (840 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Mark Knecht writes:

> On Thu, Aug 2, 2012 at 8:02 AM, Alex Schuster <wonko [at] wonkology>
> 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!

> Dunno about the python-3.2 thing. Are you set to use 3.2 by default?
> (How aggressive of you!) ;-) I'm set to use 2.7 as default which I
> think is the overall recommendation of dummies like me:

Portage should work well with 3.2 now, but I wouldn't wonder much if
something would break. I don't mind much about this, when it happens I
file a bug report, and use 2.7 again. But the problem with
os.path.exists() seems weird to me.

> c2stable ~ # eselect python list
> Available Python interpreters:
> [1] python2.7 *
> [2] python3.2
> c2stable ~ #
>
> The script has been around awhile and updated now and again. Possibly
> it's just not tested with python-3.2?

I guess so. Hmm, does anybody want to provide an ebuild on
bugs.gentoo.org for it? It would be nice to have it in portage.

Wonko

neil at digimed

Aug 2, 2012, 11:55 AM

Post #18 of 22 (844 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, 2 Aug 2012 12:59:19 -0400, Walter Dnes wrote:

> You can get the ATTRS{serial} (i.e. serial number).

Not all drives supply this. I have a pair of Seagate drives and a pair of
WD drives. Neither drive is distinguishable from its twin with udev
attributes.

--
Neil Bothwick

If nothing sticks to Teflon, how do they stick teflon on the pan?

Attachments:

signature.asc (0.19 KB)

neil at digimed

Aug 2, 2012, 11:57 AM

Post #19 of 22 (844 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Thu, 2 Aug 2012 19:43:50 +0200, Alex Schuster wrote:

> BTW, sys-fs/udev-187 does not have the 'udevinfo' command, it seems to
> be 'udevadm info' now.

udevinfo disappeared a long time ago. I wrote a script called udevinfo to
call mdadm info so that I didn't need thchage my setup, it is dated
October 2008 :-O

--
Neil Bothwick

"RAM DISK is NOT an installation procedure!"

Attachments:

signature.asc (0.19 KB)

rdalek1967 at gmail

Aug 2, 2012, 11:40 PM

Post #20 of 22 (838 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Alex Schuster wrote:
> Dale writes:
>
>> 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.
> [...]
>> I'm amd64 and it works here.
>>
>> root [at] firebal / # 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
> Um, but did you use eselect to make 3.2 the current version?
>
> Wonko
>
>

Nope. I didn't notice he was trying to use 3.2 until after I hit send.
Bad thing about emails, you can't delete them after they are sent. :/

I thought we were supposed to have 2.7 selected for the default and I
guess I just assumed that was what he was doing. I guess I am not the
only one getting ahead of myself. lol

Dale

:-) :-)

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

paul.hartman+gentoo at gmail

Aug 3, 2012, 8:31 AM

Post #21 of 22 (822 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

On Fri, Aug 3, 2012 at 1:40 AM, Dale <rdalek1967 [at] gmail> wrote:
> Nope. I didn't notice he was trying to use 3.2 until after I hit send.
> Bad thing about emails, you can't delete them after they are sent. :/

In the good old days you could compose offline, and not send them
until the next time you dialed up, so you had ample opportunity to
retract what you had written if you had second thoughts. :)

In the gmail web interface, you can able "Undo send" feature in Labs,
which will give you 5 or 10 seconds to change your mind after clicking
"send" on a message.

rdalek1967 at gmail

Aug 3, 2012, 10:50 PM

Post #22 of 22 (819 views)
Permalink

Re: Udev rules for identical hard drives [In reply to]

Paul Hartman wrote:
> On Fri, Aug 3, 2012 at 1:40 AM, Dale <rdalek1967 [at] gmail> wrote:
>> Nope. I didn't notice he was trying to use 3.2 until after I hit send.
>> Bad thing about emails, you can't delete them after they are sent. :/
> In the good old days you could compose offline, and not send them
> until the next time you dialed up, so you had ample opportunity to
> retract what you had written if you had second thoughts. :)
>
> In the gmail web interface, you can able "Undo send" feature in Labs,
> which will give you 5 or 10 seconds to change your mind after clicking
> "send" on a message.
>
>

But then I wouldn't look like the idiot I am. ^-^

Dale

:-) :-)

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads