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

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@waltdnes.org>

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

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

On Thu, Aug 2, 2012 at 10:43 AM, Peter Humphrey
<peter@humphrey.ukfsn.org> 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

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

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

Wonko

Mark Knecht writes:

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

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?

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!"

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@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
> 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!