Mailing List Archive: Contribution for the Gentoo udev Guide

Contribution for the Gentoo udev Guide

Sep 13, 2004, 1:44 PM

Post #1 of 11 (3323 views)

Hi,

My name is Toon van der Pas. I live in the Netherlands and I
administer a bunch of servers that all run Gentoo Linux
since 1 1/2 year.

Today, as I was setting up a new Proliant DL380 server, I felt
courageous and decided to make use of udev instead of devfs.
To start with the good news: the machine is running with a
pure udev environment at this moment. But I thought that
maybe you would appreciate to hear about my experiences.
Some of the issues could probably be solved preliminary by adding
some hints to the document http://www.gentoo.org/doc/en/udev-guide.xml

1. This system contains a HP Smart Array 5i RAID controller, which
makes use of the cciss kernel module. The device names by which
the configured RAID volumes can be accessed will change when one
migrates from devfs to udev. This means that references to them
in /etc/fstab and /boot/grub/grub.conf (or /etc/lilo.conf) will
have to be changed accordingly.

For instance: /dev/discs/disc0/part1 becomes /dev/cciss/c0d0p1.

2. The udev daemon gets it's device names from sysfs.
Unfortunately sysfs only produces it's own internal enumerated
representation of device-mapper devices, instead of the name
as it is known internally to device-mapper.
This is very annoying when using LVM2. For instance, with udev
the device name changes from /dev/mapper/vg01-home to /dev/dm-1.

I don't know what the final solution is going to be, but as a
temporary solution a devmap_name utility was developed by the
multipath development team. It is part of their multipath-tools
package. Alas, this package isn't carried by Gentoo (yet).
So I downloaded the tarball from their web site, compiled/installed
it on our server, and changed /etc/udev/rules.d/50-udev.rules as
follows:

I commented out this line...

KERNEL="dm-[0-9]*", NAME=""

...and uncommented this line:

KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"

And lo and behold: it works like a charm!
The resulting udev device names are compatible with those from devfs.
It looks like this:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/cciss/c0d0p1 51342 7744 40947 16% /boot
/dev/cciss/c0d0p3 963768 51532 863276 6% /
/dev/vg01/home 3096336 32884 2906168 2% /home
/dev/vg01/opt 3096336 164304 2774748 6% /opt
/dev/vg01/tmp 1032088 32836 946824 4% /tmp
/dev/vg01/usr 3096336 2006420 932632 69% /usr
/dev/vg01/var 3096336 69504 2869548 3% /var
none 1037752 0 1037752 0% /dev/shm

# ls -l /dev/dm*
brw-r----- 1 root root 254, 0 Sep 12 17:34 /dev/dm-0
brw-r----- 1 root root 254, 1 Sep 12 17:34 /dev/dm-1
brw-r----- 1 root root 254, 2 Sep 12 17:34 /dev/dm-2
brw-r----- 1 root root 254, 3 Sep 12 17:34 /dev/dm-3
brw-r----- 1 root root 254, 4 Sep 12 17:34 /dev/dm-4

# ls -l /dev/mapper/
total 0
crw-rw---- 1 root root 10, 63 Sep 12 17:34 control
brw------- 1 root root 254, 2 Sep 12 17:34 vg01-home
brw------- 1 root root 254, 3 Sep 12 17:34 vg01-opt
brw------- 1 root root 254, 4 Sep 12 17:34 vg01-tmp
brw------- 1 root root 254, 0 Sep 12 17:34 vg01-usr
brw------- 1 root root 254, 1 Sep 12 17:34 vg01-var

# ls -l /dev/vg*
lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-home -> dm-2
lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-opt -> dm-3
lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-tmp -> dm-4
lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-usr -> dm-0
lrwxrwxrwx 1 root root 4 Sep 12 17:34 /dev/vg01-var -> dm-1

/dev/vg01:
total 0
lrwxrwxrwx 1 root root 21 Sep 12 17:34 home -> /dev/mapper/vg01-home
lrwxrwxrwx 1 root root 20 Sep 12 17:34 opt -> /dev/mapper/vg01-opt
lrwxrwxrwx 1 root root 20 Sep 12 17:34 tmp -> /dev/mapper/vg01-tmp
lrwxrwxrwx 1 root root 20 Sep 12 17:34 usr -> /dev/mapper/vg01-usr
lrwxrwxrwx 1 root root 20 Sep 12 17:34 var -> /dev/mapper/vg01-var

That's all. It would be nice if this information was made available
in the Gentoo udev guide, for instance in a `hints' section.
Is the maintainer of the guide present on this mailing list?

Thank you for all the good work.
Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

swift at gentoo

Sep 14, 2004, 4:34 AM

Post #2 of 11 (3243 views)

Permalink

On Mon, Sep 13, 2004 at 10:44:37PM +0200, Toon van der Pas wrote:
> 1. This system contains a HP Smart Array 5i RAID controller, which
> makes use of the cciss kernel module. The device names by which
> the configured RAID volumes can be accessed will change when one
> migrates from devfs to udev. This means that references to them
> in /etc/fstab and /boot/grub/grub.conf (or /etc/lilo.conf) will
> have to be changed accordingly.
>
> For instance: /dev/discs/disc0/part1 becomes /dev/cciss/c0d0p1.

Actually, I believe that DevFS also has /dev/cciss/* device nodes and that
/dev/discs/disc./part. are symlinks. I might be mistaken though, I have
access to a Proliant with SA5300 but it's running neither devfs or udev
and I'm not allowed to go alther that :)

Can you still verify this, or is the transition finalized?

I'll probably add a section to the "Known Issues" about device node names
that could be different.

> 2. The udev daemon gets it's device names from sysfs.
> Unfortunately sysfs only produces it's own internal enumerated
> representation of device-mapper devices, instead of the name
> as it is known internally to device-mapper.
> This is very annoying when using LVM2. For instance, with udev
> the device name changes from /dev/mapper/vg01-home to /dev/dm-1.
>
> I don't know what the final solution is going to be, but as a
> temporary solution a devmap_name utility was developed by the
> multipath development team. It is part of their multipath-tools
> package. Alas, this package isn't carried by Gentoo (yet).
> So I downloaded the tarball from their web site, compiled/installed
> it on our server, and changed /etc/udev/rules.d/50-udev.rules as
> follows:
>
> I commented out this line...
>
> KERNEL="dm-[0-9]*", NAME=""
>
> ...and uncommented this line:
>
> KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"
>
> And lo and behold: it works like a charm!

Cool. I'm not in favor of having people download stuff manually, especially
since we could easily provide this ourselves and if it's a general solution
(i.e. every person with LVM2 and udev needs this) we better make it work
out-of-the-box. Moreover, I'm getting the feeling that your solution isn't
"the" solution, just one of the workarounds (see later). And the udev
ebuilds contains the appropriate steps to install devmap_name but just never
comes to it (if false ... fi).

I've found a couple of bugs regarding LVM2 and udev in bugs.gentoo.org,
perhaps you can search too and see if one of those is the exact problem you
are facing?

http://bugs.gentoo.org/show_bug.cgi?id=52042 looks like a valid one and sais
that one workaround is to build the device mapper in-kernel instead of as a
module.

http://bugs.gentoo.org/show_bug.cgi?id=62679 has the same issue; their
workaround is to run udevstart during bootup.

It looks like the issue is a race condition (which is probably why all the
workarounds function) but that's way over my head.

Wkr,
Sven Vermeulen

--
^__^ And Larry saw that it was Good.
(oo) Sven Vermeulen
(__) http://www.gentoo.org Documentation & PR

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 14, 2004, 1:00 PM

Post #3 of 11 (3251 views)

Permalink

On Tue, Sep 14, 2004 at 01:34:15PM +0200, Sven Vermeulen wrote:
> On Mon, Sep 13, 2004 at 10:44:37PM +0200, Toon van der Pas wrote:
> > 1. This system contains a HP Smart Array 5i RAID controller, which
> > makes use of the cciss kernel module. The device names by which
> > the configured RAID volumes can be accessed will change when one
> > migrates from devfs to udev. This means that references to them
> > in /etc/fstab and /boot/grub/grub.conf (or /etc/lilo.conf) will
> > have to be changed accordingly.
> >
> > For instance: /dev/discs/disc0/part1 becomes /dev/cciss/c0d0p1.
>
> Actually, I believe that DevFS also has /dev/cciss/* device nodes and that
> /dev/discs/disc./part. are symlinks. I might be mistaken though, I have
> access to a Proliant with SA5300 but it's running neither devfs or udev
> and I'm not allowed to go alther that :)

Well, I do understand why you're asking (answer: my example).

> Can you still verify this, or is the transition finalized?

Yes I can.
I've reversed the changes in /etc/fstab to the devfs version,
and rebooted the machine with the gentoo=noudev.
Here's how the /dev/cciss directory subtree looks while running with devfs:

# tree /dev/cciss/
/dev/cciss/
|-- c0d0 -> host0/target0/disc
|-- c0d1 -> host0/target1/disc
`-- host0
|-- target0
| |-- disc
| |-- part1
| |-- part2
| |-- part3
| `-- part4
`-- target1
|-- disc
`-- part1

3 directories, 9 files

So it's like you sayd; there IS a /dev/cciss directory onder devfs.
But it looks completely different from the udev version (see below):

# tree /dev/cciss/
/dev/cciss/
|-- c0d0
|-- c0d0p1
|-- c0d0p2
|-- c0d0p3
|-- c0d0p4
|-- c0d1
`-- c0d1p1

0 directories, 7 files

> I'll probably add a section to the "Known Issues" about device node names
> that could be different.
>
> > 2. The udev daemon gets it's device names from sysfs.
> > Unfortunately sysfs only produces it's own internal enumerated
> > representation of device-mapper devices, instead of the name
> > as it is known internally to device-mapper.
> > This is very annoying when using LVM2. For instance, with udev
> > the device name changes from /dev/mapper/vg01-home to /dev/dm-1.
> >
> > I don't know what the final solution is going to be, but as a
> > temporary solution a devmap_name utility was developed by the
> > multipath development team. It is part of their multipath-tools
> > package. Alas, this package isn't carried by Gentoo (yet).
> > So I downloaded the tarball from their web site, compiled/installed
> > it on our server, and changed /etc/udev/rules.d/50-udev.rules as
> > follows:
> >
> > I commented out this line...
> >
> > KERNEL="dm-[0-9]*", NAME=""
> >
> > ...and uncommented this line:
> >
> > KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"
> >
> > And lo and behold: it works like a charm!
>
> Cool. I'm not in favor of having people download stuff manually,
> especially since we could easily provide this ourselves and if it's
> a general solution (i.e. every person with LVM2 and udev needs
> this) we better make it work out-of-the-box. Moreover, I'm getting
> the feeling that your solution isn't "the" solution, just one of
> the workarounds (see later). And the udev ebuilds contains the
> appropriate steps to install devmap_name but just never comes to it
> (if false ... fi).

I agree with you 100% on all accounts.
And this is why I reported this to Martin Schlemmer already.
But in his answer he indicated that it could well take a while before
this issue would be resolved.
It would be nice to have this work-around documented somewhere in the
mean time, so other people don't have to solve the same puzzle I had
to.

Maybe I'll open a case in bugzilla, so it won't be forgotten...

> I've found a couple of bugs regarding LVM2 and udev in
> bugs.gentoo.org, perhaps you can search too and see if one of those
> is the exact problem you are facing?

I will do that.
But please note that my system seems to function very well now.

> http://bugs.gentoo.org/show_bug.cgi?id=52042 looks like a valid one
> and sais that one workaround is to build the device mapper
> in-kernel instead of as a module.

I do have device mapper compiled into the kernel, so that's already
taken care of. It has nothing to do with the subject of this thread.
I don't have this problem.

> http://bugs.gentoo.org/show_bug.cgi?id=62679 has the same issue;
> their workaround is to run udevstart during bootup.

Nor do I have this problem. Let me explain:
Before I installed devmap_name and activated the devmap_name rule,
I had this in my /dev directory tree:

# cd /dev
# ls -l mapper/
total 0
crw-rw---- 1 root root 10, 63 Sep 14 21:15 control
# ls -l dm*
brw-r----- 1 root root 254, 0 Sep 14 21:16 dm-0
brw-r----- 1 root root 254, 1 Sep 14 21:16 dm-1
brw-r----- 1 root root 254, 2 Sep 14 21:16 dm-2
brw-r----- 1 root root 254, 3 Sep 14 21:16 dm-3
brw-r----- 1 root root 254, 4 Sep 14 21:16 dm-4

After I installed the devmap_name stuff I got what I needed:

# cd /dev
# ls -l vg01-*
lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-home -> dm-2
lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-opt -> dm-3
lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-tmp -> dm-4
lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-usr -> dm-0
lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-var -> dm-1
# ls -l vg01/
total 0
lrwxrwxrwx 1 root root 21 Sep 14 21:15 home -> /dev/mapper/vg01-home
lrwxrwxrwx 1 root root 20 Sep 14 21:15 opt -> /dev/mapper/vg01-opt
lrwxrwxrwx 1 root root 20 Sep 14 21:15 tmp -> /dev/mapper/vg01-tmp
lrwxrwxrwx 1 root root 20 Sep 14 21:15 usr -> /dev/mapper/vg01-usr
lrwxrwxrwx 1 root root 20 Sep 14 21:15 var -> /dev/mapper/vg01-var

> It looks like the issue is a race condition (which is probably why
> all the workarounds function) but that's way over my head.

Nah, the current udev setup doesn't even TRY to make it work.
Look at the rule that the ebuild comes with:

# dm devices (ignore them)
KERNEL="dm-[0-9]*", NAME=""

To solve this sad situation I exchanged this rule for:

KERNEL="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK="%c"

I hope I answered your questions satisfyingly.
Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 14, 2004, 1:36 PM

Post #4 of 11 (3246 views)

Permalink

On Tue, Sep 14, 2004 at 10:00:57PM +0200, Toon van der Pas wrote:
>
> Before I installed devmap_name and activated the devmap_name rule,
> I had this in my /dev directory tree:
>
> # cd /dev
> # ls -l mapper/
> total 0
> crw-rw---- 1 root root 10, 63 Sep 14 21:15 control
> # ls -l dm*
> brw-r----- 1 root root 254, 0 Sep 14 21:16 dm-0
> brw-r----- 1 root root 254, 1 Sep 14 21:16 dm-1
> brw-r----- 1 root root 254, 2 Sep 14 21:16 dm-2
> brw-r----- 1 root root 254, 3 Sep 14 21:16 dm-3
> brw-r----- 1 root root 254, 4 Sep 14 21:16 dm-4
>
> After I installed the devmap_name stuff I got what I needed:
>
> # cd /dev
> # ls -l vg01-*
> lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-home -> dm-2
> lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-opt -> dm-3
> lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-tmp -> dm-4
> lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-usr -> dm-0
> lrwxrwxrwx 1 root root 4 Sep 14 21:16 vg01-var -> dm-1
> # ls -l vg01/
> total 0
> lrwxrwxrwx 1 root root 21 Sep 14 21:15 home -> /dev/mapper/vg01-home
> lrwxrwxrwx 1 root root 20 Sep 14 21:15 opt -> /dev/mapper/vg01-opt
> lrwxrwxrwx 1 root root 20 Sep 14 21:15 tmp -> /dev/mapper/vg01-tmp
> lrwxrwxrwx 1 root root 20 Sep 14 21:15 usr -> /dev/mapper/vg01-usr
> lrwxrwxrwx 1 root root 20 Sep 14 21:15 var -> /dev/mapper/vg01-var

The df output looks like this:

# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/cciss/c0d0p3 963768 51536 863272 6% /
/dev/vg01/home 3096336 32884 2906168 2% /home
/dev/vg01/opt 3096336 164304 2774748 6% /opt
/dev/vg01/tmp 1032088 32836 946824 4% /tmp
/dev/vg01/usr 3096336 2006500 932552 69% /usr
/dev/vg01/var 3096336 69444 2869608 3% /var
none 1037752 0 1037752 0% /dev/shm

After installing devmap_name I can now use the same LVM device nodes
with udev as I used to do with devfs. (/dev/vg01/home etc.)

Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

swift at gentoo

Sep 22, 2004, 5:00 AM

Post #5 of 11 (3250 views)

Permalink

On Tue, Sep 14, 2004 at 10:36:51PM +0200, Toon van der Pas wrote:
> After installing devmap_name I can now use the same LVM device nodes
> with udev as I used to do with devfs. (/dev/vg01/home etc.)

Thanks. devmap_name should be installed though, I believe it is part of
device-mapper (which is a dependency of lvm2). If this isn't the case,
please do mention this, then I can create a bugreport (as it isn't
documentation-related) unless you want to take the honours.

Wkr,
Sven Vermeulen

--
^__^ And Larry saw that it was Good.
(oo) Sven Vermeulen
(__) http://www.gentoo.org Documentation & PR

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 22, 2004, 5:27 AM

Post #6 of 11 (3248 views)

Permalink

On Wed, Sep 22, 2004 at 02:00:36PM +0200, Sven Vermeulen wrote:
> On Tue, Sep 14, 2004 at 10:36:51PM +0200, Toon van der Pas wrote:
> > After installing devmap_name I can now use the same LVM device nodes
> > with udev as I used to do with devfs. (/dev/vg01/home etc.)
>
> Thanks. devmap_name should be installed though, I believe it is
> part of device-mapper (which is a dependency of lvm2). If this
> isn't the case, please do mention this, then I can create a
> bugreport (as it isn't documentation-related) unless you want to
> take the honours.

No, it is not part of the device-mapper package.
Instead, it is part of the multipath-tools package, for which no
ebuild is available. I downloaded the tarball from this URI:
http://christophe.varoqui.free.fr/multipath-tools/multipath-tools-0.2.8.tar.bz2

I told this to Martin Schlemmer, who agreed with me that this package
should be made available through portage. He appeared to be willing
to do this, but he also told me that he was very busy right now.

You may file a bug report if you like.
I didn't do it yet, because it seemed wise to wait for your reaction.
If you will do it, then please tell me. Otherwise we run the risc of
doing it twice.

Thanks,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

swift at gentoo

Sep 22, 2004, 7:30 AM

Post #7 of 11 (3249 views)

Permalink

On Wed, Sep 22, 2004 at 02:27:37PM +0200, Toon van der Pas wrote:
> No, it is not part of the device-mapper package.
> Instead, it is part of the multipath-tools package, for which no
> ebuild is available. I downloaded the tarball from this URI:
> http://christophe.varoqui.free.fr/multipath-tools/multipath-tools-0.2.8.tar.bz2

Darn.

> I told this to Martin Schlemmer, who agreed with me that this package
> should be made available through portage. He appeared to be willing
> to do this, but he also told me that he was very busy right now.

Who isn't :)

> You may file a bug report if you like.
> I didn't do it yet, because it seemed wise to wait for your reaction.
> If you will do it, then please tell me. Otherwise we run the risc of
> doing it twice.

You go ahead, you found the bug(ger) :)

Wkr,
Sven Vermeulen

--
^__^ And Larry saw that it was Good.
(oo) Sven Vermeulen
(__) http://www.gentoo.org Documentation & PR

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 22, 2004, 2:36 PM

Post #8 of 11 (3253 views)

Permalink

On Wed, Sep 22, 2004 at 04:30:23PM +0200, Sven Vermeulen wrote:
>
> > should be made available through portage. He appeared to be willing
> > to do this, but he also told me that he was very busy right now.
>
> Who isn't :)
>
> > You may file a bug report if you like.
> > I didn't do it yet, because it seemed wise to wait for your reaction.
> > If you will do it, then please tell me. Otherwise we run the risc of
> > doing it twice.
>
> You go ahead, you found the bug(ger) :)

OK. I'll do so as soon as I find an opportunity. :-^

Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 24, 2004, 6:12 AM

Post #9 of 11 (3249 views)

Permalink

On Wed, Sep 22, 2004 at 11:36:27PM +0200, Toon van der Pas wrote:
> >
> > You go ahead, you found the bug(ger) :)
>
> OK. I'll do so as soon as I find an opportunity. :-^

For the record, I just entered this bug report in Bugzilla:

http://bugs.gentoo.org/show_bug.cgi?id=65191

Regards,
Toon.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

toon at hout

Sep 28, 2004, 6:09 AM

Post #10 of 11 (3277 views)

Permalink

By the way, I reported _TWO_ issues in the message that started this
thread. As the thread developed, it's focus shifted to the second
issue completely and the first issue got neglected.
I still think the first issue is worth to be added to the udev guide
in the 'hints' -- ehrm, 'known issues' -- section, don't you think?

Regards,
Toon.

On Tue, Sep 14, 2004 at 10:00:57PM +0200, Toon van der Pas wrote:
> On Tue, Sep 14, 2004 at 01:34:15PM +0200, Sven Vermeulen wrote:
> > On Mon, Sep 13, 2004 at 10:44:37PM +0200, Toon van der Pas wrote:
> > > 1. This system contains a HP Smart Array 5i RAID controller, which
> > > makes use of the cciss kernel module. The device names by which
> > > the configured RAID volumes can be accessed will change when one
> > > migrates from devfs to udev. This means that references to them
> > > in /etc/fstab and /boot/grub/grub.conf (or /etc/lilo.conf) will
> > > have to be changed accordingly.
> > >
> > > For instance: /dev/discs/disc0/part1 becomes /dev/cciss/c0d0p1.
> >
> > Actually, I believe that DevFS also has /dev/cciss/* device nodes and that
> > /dev/discs/disc./part. are symlinks. I might be mistaken though, I have
> > access to a Proliant with SA5300 but it's running neither devfs or udev
> > and I'm not allowed to go alther that :)
>
> Well, I do understand why you're asking (answer: my example).
>
> > Can you still verify this, or is the transition finalized?
>
> Yes I can.
> I've reversed the changes in /etc/fstab to the devfs version,
> and rebooted the machine with the gentoo=noudev.
> Here's how the /dev/cciss directory subtree looks while running with devfs:
>
> # tree /dev/cciss/
> /dev/cciss/
> |-- c0d0 -> host0/target0/disc
> |-- c0d1 -> host0/target1/disc
> `-- host0
> |-- target0
> | |-- disc
> | |-- part1
> | |-- part2
> | |-- part3
> | `-- part4
> `-- target1
> |-- disc
> `-- part1
>
> 3 directories, 9 files
>
> So it's like you sayd; there IS a /dev/cciss directory under devfs.
> But it looks completely different from the udev version (see below):
>
> # tree /dev/cciss/
> /dev/cciss/
> |-- c0d0
> |-- c0d0p1
> |-- c0d0p2
> |-- c0d0p3
> |-- c0d0p4
> |-- c0d1
> `-- c0d1p1
>
> 0 directories, 7 files

--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

--
gentoo-doc@gentoo.org mailing list

Re: Contribution for the Gentoo udev Guide [ In reply to ]

swift at gentoo

Sep 28, 2004, 8:43 AM

Post #11 of 11 (3254 views)

Permalink

On Tue, Sep 28, 2004 at 03:09:59PM +0200, Toon van der Pas wrote:
> By the way, I reported _TWO_ issues in the message that started this
> thread. As the thread developed, it's focus shifted to the second
> issue completely and the first issue got neglected.
> I still think the first issue is worth to be added to the udev guide
> in the 'hints' -- ehrm, 'known issues' -- section, don't you think?

Ah yes, the difference in naming thingie. Sorry about that, slipped my mind.
I'll add it in when I'm back but if someone else wants to take a stab at it,
go ahead.

Wkr,
Sven Vermeulen

--
^__^ And Larry saw that it was Good.
(oo) Sven Vermeulen
(__) http://www.gentoo.org Documentation & PR