[gentoo-user] udev-197 moves from /usr/lib to /lib

[gentoo-user] udev-197 moves from /usr/lib to /lib

[walt]

This seems to me like very happy news indeed, but I'm interested in contrary
opinions.  There's a recent thread discussing how udev-197 breaks lvm2, but
that's a trivial fix once you know about it.

The problem is caused because many apps including lvm2 install their udev
config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
first place IMO) and they should instead now go in /lib/udev/rules.d/.
All you need to do is to re-emerge all of those packages *after* installing
udev-197 and the config scripts will go in the correct place.

You should do this before rebooting the machine because lvm2 won't work until
its udev scripts are in the correct directory.

Doesn't this seem to fix the problem with booting a separate /usr partition?

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Douglas J Hunley]

On Fri, Jan 11, 2013 at 9:04 AM, walt <w41ter@gmail.com> wrote:
> This seems to me like very happy news indeed, but I'm interested in contrary
> opinions.  There's a recent thread discussing how udev-197 breaks lvm2, but
> that's a trivial fix once you know about it.
>
> The problem is caused because many apps including lvm2 install their udev
> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
> first place IMO) and they should instead now go in /lib/udev/rules.d/.
> All you need to do is to re-emerge all of those packages *after* installing
> udev-197 and the config scripts will go in the correct place.
>
> You should do this before rebooting the machine because lvm2 won't work until
> its udev scripts are in the correct directory.

I dealt with this yesterday and was a little annoyed that the note
detailing this didn't include an example of *how* to identify which
packages needed re-emerged. I figured it out, but i can forsee a lot
of pain on this front from the general user base (everyone on this
list shouldn't have a problem with it, imho).

>
> Doesn't this seem to fix the problem with booting a separate /usr partition?
>

I was wondering the same thing. It would seem to..


--
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd                                               Web:
douglasjhunley.com
G+: http://goo.gl/sajR3

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Nikos Chantziaras]

On 11/01/13 16:04, walt wrote:
> This seems to me like very happy news indeed, but I'm interested in contrary
> opinions.  There's a recent thread discussing how udev-197 breaks lvm2, but
> that's a trivial fix once you know about it.
>
> The problem is caused because many apps including lvm2 install their udev
> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
> first place IMO) and they should instead now go in /lib/udev/rules.d/.
> All you need to do is to re-emerge all of those packages *after* installing
> udev-197 and the config scripts will go in the correct place.
>
> You should do this before rebooting the machine because lvm2 won't work until
> its udev scripts are in the correct directory.

Running this command (all in one line):

emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do 
echo "=$p"; done)

should re-emerge all packages that still have files there.  After that, 
/usr/lib/udev should no longer exist.  If it still does, then there are 
files in it that don't belong to any package.  Check them manually and 
delete them as needed or move them over.  Then delete /usr/lib/udev.

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Stefan G. Weichinger]

Am 11.01.2013 16:14, schrieb Nikos Chantziaras:

> Running this command (all in one line):
> 
> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
> echo "=$p"; done)
> 
> should re-emerge all packages that still have files there.  After that,
> /usr/lib/udev should no longer exist.  If it still does, then there are
> files in it that don't belong to any package.  Check them manually and
> delete them as needed or move them over.  Then delete /usr/lib/udev.

phew, that lists quite a list of packages here:

[ebuild   R    ] sys-fs/fuse-2.9.2
[ebuild   R    ] media-gfx/sane-backends-1.0.23
[ebuild   R    ] sys-apps/hwids-20130108
[ebuild   R    ] media-sound/alsa-utils-1.0.26-r1
[ebuild   R    ] media-libs/libmtp-1.1.5
[ebuild   R    ] media-libs/libgphoto2-2.5.0
[ebuild   R    ] sys-fs/ntfs3g-2012.1.15-r2
[ebuild   R    ] sys-libs/libosinfo-0.2.2
[ebuild   R    ] net-wireless/crda-1.1.2-r4
[ebuild   R    ] sys-fs/mdadm-3.2.6
[ebuild   R    ] x11-drivers/nvidia-drivers-310.19
[ebuild   R    ] sys-auth/consolekit-0.4.5_p20120320-r1
[ebuild   R    ] x11-misc/colord-0.1.26-r1
[ebuild   R    ] sys-power/upower-0.9.19
[ebuild   R    ] sys-fs/udisks-1.0.4-r4
[ebuild   R    ] app-admin/system-config-printer-common-1.3.12
[ebuild   R    ] sys-fs/udisks-2.0.91
[ebuild   R    ] net-print/hplip-3.12.11
[ebuild   R    ] net-wireless/bluez-4.101-r5
[ebuild   R    ] net-misc/networkmanager-0.9.6.4
[ebuild   R    ] sys-fs/udev-init-scripts-19
[ebuild   R    ] net-wireless/gnome-bluetooth-3.6.1
[ebuild   R    ] media-sound/pulseaudio-3.0  USE="(-neon)"
[ebuild   R    ] app-emulation/qemu-1.2.1  USE="(-selinux)"
[ebuild   R    ] app-emulation/vmware-modules-271.1-r1

Stefan

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Stefan G. Weichinger]

Am 11.01.2013 16:14, schrieb Nikos Chantziaras:

> Running this command (all in one line):
> 
> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
> echo "=$p"; done)
> 
> should re-emerge all packages that still have files there.  After that,
> /usr/lib/udev should no longer exist.  If it still does, then there are
> files in it that don't belong to any package.  Check them manually and
> delete them as needed or move them over.  Then delete /usr/lib/udev.

on my thinkpad I had app-laptop/laptop-mode-tools which had its
99-mode-laptop-mode.rules in /usr/lib/udev/rules.d even after re-emerging.

moved that file manually ...

Should that be filed as a bug?

Stefan

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Nikos Chantziaras]

On 11/01/13 19:51, Stefan G. Weichinger wrote:
> Am 11.01.2013 16:14, schrieb Nikos Chantziaras:
>
>> Running this command (all in one line):
>>
>> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
>> echo "=$p"; done)
>>
>> should re-emerge all packages that still have files there.  After that,
>> /usr/lib/udev should no longer exist.  If it still does, then there are
>> files in it that don't belong to any package.  Check them manually and
>> delete them as needed or move them over.  Then delete /usr/lib/udev.
>
> on my thinkpad I had app-laptop/laptop-mode-tools which had its
> 99-mode-laptop-mode.rules in /usr/lib/udev/rules.d even after re-emerging.
>
> moved that file manually ...
>
> Should that be filed as a bug?

Most probably yes.

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Daniel Campbell]

On 01/11/2013 09:14 AM, Nikos Chantziaras wrote:
> On 11/01/13 16:04, walt wrote:
>> This seems to me like very happy news indeed, but I'm interested in
>> contrary
>> opinions.  There's a recent thread discussing how udev-197 breaks
>> lvm2, but
>> that's a trivial fix once you know about it.
>>
>> The problem is caused because many apps including lvm2 install their udev
>> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in
>> the
>> first place IMO) and they should instead now go in /lib/udev/rules.d/.
>> All you need to do is to re-emerge all of those packages *after*
>> installing
>> udev-197 and the config scripts will go in the correct place.
>>
>> You should do this before rebooting the machine because lvm2 won't
>> work until
>> its udev scripts are in the correct directory.
> 
> Running this command (all in one line):
> 
> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
> echo "=$p"; done)
> 
> should re-emerge all packages that still have files there.  After that,
> /usr/lib/udev should no longer exist.  If it still does, then there are
> files in it that don't belong to any package.  Check them manually and
> delete them as needed or move them over.  Then delete /usr/lib/udev.
> 
> 

Thanks for the command line tip. I wasn't aware of the /lib/ move and
would've had a handful of problems had I not read the list.

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[walt]

On 01/11/2013 07:14 AM, Nikos Chantziaras wrote:
> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do echo "=$p"; done)

qfile stopped working for me many weeks ago and I wish I could get it working again.
All the other portage utils work normally, though.  Any idea how to fix it?

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Alan McKinnon]

On Fri, 11 Jan 2013 11:52:14 -0800
walt <w41ter@gmail.com> wrote:

> On 01/11/2013 07:14 AM, Nikos Chantziaras wrote:
> > emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort
> > -u); do echo "=$p"; done)
> 
> qfile stopped working for me many weeks ago and I wish I could get it
> working again. All the other portage utils work normally, though.
> Any idea how to fix it?
> 
> 

Error messages please

-- 
Alan McKinnon
alan.mckinnon@gmail.com

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[walt]

On 01/11/2013 12:18 PM, Alan McKinnon wrote:
> On Fri, 11 Jan 2013 11:52:14 -0800
> walt <w41ter@gmail.com> wrote:
> 
>> On 01/11/2013 07:14 AM, Nikos Chantziaras wrote:
>>> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort
>>> -u); do echo "=$p"; done)
>>
>> qfile stopped working for me many weeks ago and I wish I could get it
>> working again. All the other portage utils work normally, though.
>> Any idea how to fix it?
>>
>>
> 
> Error messages please

#qfile bash
#echo $?
1
#qfile /bin/bash
app-shells/bash (/bin/bash)
#echo $?
0

That's not the behavior I saw a few months back.  Do you see something different?

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Alan McKinnon]

On Fri, 11 Jan 2013 13:36:13 -0800
walt <w41ter@gmail.com> wrote:

> On 01/11/2013 12:18 PM, Alan McKinnon wrote:
> > On Fri, 11 Jan 2013 11:52:14 -0800
> > walt <w41ter@gmail.com> wrote:
> > 
> >> On 01/11/2013 07:14 AM, Nikos Chantziaras wrote:
> >>> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort
> >>> -u); do echo "=$p"; done)
> >>
> >> qfile stopped working for me many weeks ago and I wish I could get
> >> it working again. All the other portage utils work normally,
> >> though. Any idea how to fix it?
> >>
> >>
> > 
> > Error messages please
> 
> #qfile bash
> #echo $?
> 1
> #qfile /bin/bash
> app-shells/bash (/bin/bash)
> #echo $?
> 0
> 
> That's not the behavior I saw a few months back.  Do you see
> something different?
> 

alanm@khamul ~ $ qfile bash
alanm@khamul ~ $ echo $?
1
alanm@khamul ~ $ qfile /bin/bash
app-shells/bash (/bin/bash)
alanm@khamul ~ $ echo $?
0
alanm@khamul ~ $ 

I get the same as you, and Nikos' one-liner works as intended for me.

I don't use qfile much so I can't honestly say if it changed recently,
but it's behaviour is odd to say the least:

alanm@khamul ~ $ pwd
/home/alanm
alanm@khamul ~ $ qfile media
sys-fs/udisks (/media)
alanm@khamul ~ $ 
alanm@khamul ~ $ 
alanm@khamul ~ $ qfile bash
alanm@khamul ~ $ cd /bin/
alanm@khamul /bin $ qfile bash
app-shells/bash (/bin/bash)
alanm@khamul /bin $ 

This is the documented behaviour, explained by the "ROOT VARIABLE"
section in the man page, but it just feels weird. The purpose of qfile
is to tell you what installed a file system object (the argument to the
command). The argument looks exactly like a path/filename and a
reasonable man would treat it as such, but the command is
prepending a hidden[1] string of ROOT VARIABLE when it doesn't get a
hit on the first try.

This might make sense to the dev, but it's
certain to confuse everyone else. I would say that's not a bug, but
it's an odd feature that probably needs to be thought through some more.



[1] It's not really hidden as such. But it does do something very
unexpected by default, and you have to read the man page first to
find it. Feels to me like it violates the Law of Unexpected Behaviour


-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Dustin C. Hatch]

On 1/11/2013 09:14, Nikos Chantziaras wrote:
> On 11/01/13 16:04, walt wrote:
>> This seems to me like very happy news indeed, but I'm interested in
>> contrary
>> opinions.  There's a recent thread discussing how udev-197 breaks
>> lvm2, but
>> that's a trivial fix once you know about it.
>>
>> The problem is caused because many apps including lvm2 install their udev
>> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in
>> the
>> first place IMO) and they should instead now go in /lib/udev/rules.d/.
>> All you need to do is to re-emerge all of those packages *after*
>> installing
>> udev-197 and the config scripts will go in the correct place.
>>
>> You should do this before rebooting the machine because lvm2 won't
>> work until
>> its udev scripts are in the correct directory.
>
> Running this command (all in one line):
>
> emerge -p1 $(for p in $(qfile -Cvq $(find /usr/lib/udev/) | sort -u); do
> echo "=$p"; done)
>
> should re-emerge all packages that still have files there.  After that,
> /usr/lib/udev should no longer exist.  If it still does, then there are
> files in it that don't belong to any package.  Check them manually and
> delete them as needed or move them over.  Then delete /usr/lib/udev.
>
>

Or, without a loop (easier to read and type, IMHO):

qfile -Cvq /usr/lib/udev | awk '{print "="$1}' | xargs emerge -pv

or, using gentoolkit instead of portage-utils (slower, but will not fail 
if the installed version of a package no longer exists):

equery belongs -n /usr/lib/udev | xargs emerge -pv

-- 
♫Dustin

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[James Cloos]

Or, just:

:; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/ | awk -F/ '{print "=" $5 "/" $6}' | xargs emerge -pv

which should be fastest.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Daniel Pielmeier]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

James Cloos schrieb am 11.01.2013 21:30:
> Or, just:
> 
> :; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/ | awk -F/ '{print "=" $5 "/" $6}' | xargs emerge -pv
> 
> which should be fastest.
> 
> -JimC


Or "emerge -av /usr/lib/udev". See "man emerge 1"

-- 
Regards
Daniel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Alan McKinnon]

On Fri, 11 Jan 2013 15:30:54 -0500
James Cloos <cloos@jhcloos.com> wrote:

> Or, just:
> 
> :; find /var/db/pkg -name CONTENTS | xargs -0 grep -l /usr/lib/udev/
> | awk -F/ '{print "=" $5 "/" $6}' | xargs emerge -pv
> 
> which should be fastest.

The original command runs quicker than the time it takes to parse
your's by eye :-)

I'm asking myself what is more valuable - insanely cheap cpu cycles or
this here human's drinking time. And I already know the answer, doubly
so as it's a once-off one-liner :-)

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Fri, Jan 11, 2013 at 8:04 AM, walt <w41ter@gmail.com> wrote:
> This seems to me like very happy news indeed, but I'm interested in contrary
> opinions.  There's a recent thread discussing how udev-197 breaks lvm2, but
> that's a trivial fix once you know about it.
>
> The problem is caused because many apps including lvm2 install their udev
> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
> first place IMO) and they should instead now go in /lib/udev/rules.d/.
> All you need to do is to re-emerge all of those packages *after* installing
> udev-197 and the config scripts will go in the correct place.
>
> You should do this before rebooting the machine because lvm2 won't work until
> its udev scripts are in the correct directory.
>
> Doesn't this seem to fix the problem with booting a separate /usr partition?

No, because the problem has never been in udev (nor systemd, for that
matter). It fixes how *Gentoo* packages udev; probably the devs read
the following comment from Lennart (note it was written almost a month
ago):

https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3

Certainly, <=sys-fs/udev-171-r9 didn't use --with-rootprefix in the ebuilds.

That's the reason Greg and many others were so dubious about eudev:
one of the primary reasons for the fork to exist is supposedly to
support a separate /usr without an initramfs... but that has *always*
been supported by udev. And systemd, for that matter. systemd/udev
prints a warning if it doesn't finds /usr at early boot, but both work
in such configuration without any problem (if configured properly by
the distribution, which apparently in Gentoo's case wasn't true).

So, no, it doesn't "fix" the separate /usr problem, because that has
never been a problem of udev nor systemd. And it's not going to be
"fixed" by eudev either, for the same reason.

But it fixes how udev it's packaged in Gentoo, which is very good
news. I haven't upgraded, since I need systemd-197 also (which wasn't
yet in the tree yesterday), and I don't use LVM, but I'm wondering if
the LVM problem happens when you use an initramfs. I'm guessing it
doesn't, since udev should read rules from /lib/udev/rules.d AND
/usr/lib/udev/rules.d.

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

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Sascha Cunz]

[...]

> But it fixes how udev it's packaged in Gentoo, which is very good
> news. I haven't upgraded, since I need systemd-197 also (which wasn't
> yet in the tree yesterday), and I don't use LVM, but I'm wondering if
> the LVM problem happens when you use an initramfs. I'm guessing it
> doesn't, since udev should read rules from /lib/udev/rules.d AND
> /usr/lib/udev/rules.d.

I don't use an initramfs but neither do i have a separate /usr. Still, lvm2 
hung after the udev upgrade. So it probably did _not_ search the old location.

Though, after pressing ^C, lvm2 terminated and some fall back mechanism kicked 
in and the system worked just fine - i.e. was able to mount the lvm volumes. 
I'm actually not sure what that means (or which "system" was responsible for 
that fall back).

Sascha

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz <sascha-ml@babbelbox.org> wrote:
> [...]
>
>> But it fixes how udev it's packaged in Gentoo, which is very good
>> news. I haven't upgraded, since I need systemd-197 also (which wasn't
>> yet in the tree yesterday), and I don't use LVM, but I'm wondering if
>> the LVM problem happens when you use an initramfs. I'm guessing it
>> doesn't, since udev should read rules from /lib/udev/rules.d AND
>> /usr/lib/udev/rules.d.
>
> I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
> hung after the udev upgrade. So it probably did _not_ search the old location.

You are right, the code in udev only searches for one prefix. All the
other commands the other members of the list have been mentioning
would be necessary for all the people needing udev rules to boot.

I believe this is a kinda serious bug in the packaging. And it's
really easy to fix: the following patch should cover all the udev
Gentoo users:

diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index bb57d2a..027750a 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)

         rules->dirs = strv_new("/etc/udev/rules.d",
                                "/run/udev/rules.d",
+                              "/usr/lib/rules.d",
+                              "/lib/rules.d",
                                UDEVLIBEXECDIR "/rules.d",
                                NULL);
         if (!rules->dirs) {

I thought Gentoo had a patch like that. It's necessary, since not
every package will install rules in /lib.

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

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Fri, Jan 11, 2013 at 4:03 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz <sascha-ml@babbelbox.org> wrote:
>> [...]
>>
>>> But it fixes how udev it's packaged in Gentoo, which is very good
>>> news. I haven't upgraded, since I need systemd-197 also (which wasn't
>>> yet in the tree yesterday), and I don't use LVM, but I'm wondering if
>>> the LVM problem happens when you use an initramfs. I'm guessing it
>>> doesn't, since udev should read rules from /lib/udev/rules.d AND
>>> /usr/lib/udev/rules.d.
>>
>> I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
>> hung after the udev upgrade. So it probably did _not_ search the old location.
>
> You are right, the code in udev only searches for one prefix. All the
> other commands the other members of the list have been mentioning
> would be necessary for all the people needing udev rules to boot.
>
> I believe this is a kinda serious bug in the packaging. And it's
> really easy to fix: the following patch should cover all the udev
> Gentoo users:
>
> diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
> index bb57d2a..027750a 100644
> --- a/src/udev/udev-rules.c
> +++ b/src/udev/udev-rules.c
> @@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
> *udev, int resolve_names)
>
>          rules->dirs = strv_new("/etc/udev/rules.d",
>                                 "/run/udev/rules.d",
> +                              "/usr/lib/rules.d",
> +                              "/lib/rules.d",
>                                 UDEVLIBEXECDIR "/rules.d",
>                                 NULL);
>          if (!rules->dirs) {
>
> I thought Gentoo had a patch like that. It's necessary, since not
> every package will install rules in /lib.

I hit click too quickly: Gentoo *does* include a patch like the one I presented:

From d2a922619a466c47a88ff11aea43bc2dbb4ea324 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= <mgorny@gentoo.org>
Date: Fri, 13 Jul 2012 16:15:14 +0200
Subject: [PATCH 1/2] udev: add /lib/udev/rules.d to rules directories

This adds /lib if split-usr is enabled
to the directories where udev searches for rules.d.

This is needed if split-usr is enabled because some software still
installs rules in /lib/udev/rules.d.
---
 src/udev/udev-rules.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index e6f0f5d..f6b0c01 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1603,6 +1603,9 @@ struct udev_rules *udev_rules_new(struct udev
*udev, int resolve_names)
         rules->dirs = strv_new("/etc/udev/rules.d",
                                "/run/udev/rules.d",
                                UDEVLIBEXECDIR "/rules.d",
+#ifdef HAVE_SPLIT_USR
+                               "/lib/udev/rules.d",
+#endif
                                NULL);
         if (!rules->dirs) {
                 log_error("failed to build config directory array");
-- 

It should be in udev-197-patches-1.tar.bz2 (it is in
udev-196-patches-1.tar.bz2). So Gentoo *does* read the rules from /lib
if the patch is present. If that's the case, the problem with LVM is
not because it can't read the rules.

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

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Fri, Jan 11, 2013 at 4:07 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 4:03 PM, Canek Peláez Valdés <caneko@gmail.com> wrote:
>> On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz <sascha-ml@babbelbox.org> wrote:
>>> [...]
>>>
>>>> But it fixes how udev it's packaged in Gentoo, which is very good
>>>> news. I haven't upgraded, since I need systemd-197 also (which wasn't
>>>> yet in the tree yesterday), and I don't use LVM, but I'm wondering if
>>>> the LVM problem happens when you use an initramfs. I'm guessing it
>>>> doesn't, since udev should read rules from /lib/udev/rules.d AND
>>>> /usr/lib/udev/rules.d.
>>>
>>> I don't use an initramfs but neither do i have a separate /usr. Still, lvm2
>>> hung after the udev upgrade. So it probably did _not_ search the old location.
>>
>> You are right, the code in udev only searches for one prefix. All the
>> other commands the other members of the list have been mentioning
>> would be necessary for all the people needing udev rules to boot.
>>
>> I believe this is a kinda serious bug in the packaging. And it's
>> really easy to fix: the following patch should cover all the udev
>> Gentoo users:
>>
>> diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
>> index bb57d2a..027750a 100644
>> --- a/src/udev/udev-rules.c
>> +++ b/src/udev/udev-rules.c
>> @@ -1602,6 +1602,8 @@ struct udev_rules *udev_rules_new(struct udev
>> *udev, int resolve_names)
>>
>>          rules->dirs = strv_new("/etc/udev/rules.d",
>>                                 "/run/udev/rules.d",
>> +                              "/usr/lib/rules.d",
>> +                              "/lib/rules.d",
>>                                 UDEVLIBEXECDIR "/rules.d",
>>                                 NULL);
>>          if (!rules->dirs) {
>>
>> I thought Gentoo had a patch like that. It's necessary, since not
>> every package will install rules in /lib.
>
> I hit click too quickly: Gentoo *does* include a patch like the one I presented:
>
> From d2a922619a466c47a88ff11aea43bc2dbb4ea324 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Micha=C5=82=20G=C3=B3rny?= <mgorny@gentoo.org>
> Date: Fri, 13 Jul 2012 16:15:14 +0200
> Subject: [PATCH 1/2] udev: add /lib/udev/rules.d to rules directories
>
> This adds /lib if split-usr is enabled
> to the directories where udev searches for rules.d.
>
> This is needed if split-usr is enabled because some software still
> installs rules in /lib/udev/rules.d.
> ---
>  src/udev/udev-rules.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
> index e6f0f5d..f6b0c01 100644
> --- a/src/udev/udev-rules.c
> +++ b/src/udev/udev-rules.c
> @@ -1603,6 +1603,9 @@ struct udev_rules *udev_rules_new(struct udev
> *udev, int resolve_names)
>          rules->dirs = strv_new("/etc/udev/rules.d",
>                                 "/run/udev/rules.d",
>                                 UDEVLIBEXECDIR "/rules.d",
> +#ifdef HAVE_SPLIT_USR
> +                               "/lib/udev/rules.d",
> +#endif
>                                 NULL);
>          if (!rules->dirs) {
>                  log_error("failed to build config directory array");
> --
>
> It should be in udev-197-patches-1.tar.bz2 (it is in
> udev-196-patches-1.tar.bz2). So Gentoo *does* read the rules from /lib
> if the patch is present. If that's the case, the problem with LVM is
> not because it can't read the rules.

OK, I downloaded the patchset for 197, and it dropped the patch that
supported both locations for rules.d. I don't understand why, it's a
simple patch, and given that (most) Gentoo users have their rules
files in both /lib and /usr/lib, don't having it will break a lot of
systems (as we can see at the moment).

Just to be clear: no change in udev caused the LVM problem. The Gentoo
ebuild dropped a patch that it's necessary, and that it was included
in previous versions. A bug should be filled explaining that
0001-udev-add-lib-udev-rules.d-to-rules-directories.patch should be
added again to the patchset; I would do it, but can't right now.

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

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Walter Dnes]

On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote

> No, because the problem has never been in udev (nor systemd, for that
> matter). It fixes how *Gentoo* packages udev; probably the devs read
> the following comment from Lennart (note it was written almost a month
> ago):
> 
> https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3

  The systemd defenders are using "separate /usr" as a "wookie defense"
in an attempt to divert attention form the main issue.  Separate /usr
is actually a secondary issue.  The main issue is whether or not we get
systemd rammed down our throats.  Lennart and Kay are the people
responsible for scaring others into mdev and/or eudev.

First Kay...
http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html

> We promised to keep udev properly *running* as standalone, we never
> told that it can be *build* standalone. And that still stands.
> 
> We never claimed, that all the surrounding things like documentation
> always fully match, if only udev is picked out of systemd.
> 
> I would welcome if people stop reading that "promise" into the
> announcement, it just wasn't written there.

And then Lennart...
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html

> (Yes, udev on non-systemd systems is in our eyes a dead end, in case
> you haven't noticed it yet. I am looking forward to the day when we
> can drop that support entirely.)
> 
> Lennart
> 
> -- Lennart Poettering - Red Hat, Inc.

  The only assumption I'm making is that Kay and Lennart aren't lying.

  Kay tells us that we may eventually not be able to build udev
standalone; i.e. we may have to build systemd in order to run udev.
Gentoo users are familiar with cascading dependancies which tend to
bloat our systems, as well as introducing additional points of failure.
Lennart goes one step further and looks forward to the day that we may
not be able to run udev without running systemd.

  For those of us who do not want to build, let alone run, systemd,
these 2 messages are more than sufficient justification for the eudev
fork.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[Nikos Chantziaras]

On 12/01/13 00:33, Walter Dnes wrote:
> On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote
>
>> No, because the problem has never been in udev (nor systemd, for that
>> matter). It fixes how *Gentoo* packages udev; probably the devs read
>> the following comment from Lennart (note it was written almost a month
>> ago):
>>
>> https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3
> [...]
>
>    For those of us who do not want to build, let alone run, systemd,
> these 2 messages are more than sufficient justification for the eudev
> fork.

This is about udev, not eudev.  Obviously, people using udev don't care 
about the systemd dependency (if they do, they should switch to eudev) 
*and* expect separate /usr to work, because upstream udev works just 
fine with it.

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Fri, Jan 11, 2013 at 4:33 PM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Fri, Jan 11, 2013 at 10:42:37AM -0600, Canek Pel??ez Vald??s wrote
>
>> No, because the problem has never been in udev (nor systemd, for that
>> matter). It fixes how *Gentoo* packages udev; probably the devs read
>> the following comment from Lennart (note it was written almost a month
>> ago):
>>
>> https://plus.google.com/u/0/115547683951727699051/posts/jcCjMct3SJ3
>
>   The systemd defenders are using "separate /usr" as a "wookie defense"
> in an attempt to divert attention form the main issue.  Separate /usr
> is actually a secondary issue.  The main issue is whether or not we get
> systemd rammed down our throats.  Lennart and Kay are the people
> responsible for scaring others into mdev and/or eudev.

Ubuntu wants systemd even less than Gentoo. I will not be surprised if
Gentoo makes systemd the recommended default before Ubuntu. And yet,
Ubuntu doesn't want to fork udev, and actually a Canonical employee
has git access to the udev/systemd tree.

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

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Bruce Hill]

On Fri, Jan 11, 2013 at 05:33:30PM -0500, Walter Dnes wrote:
> 
>   The systemd defenders are using "separate /usr" as a "wookie defense"
> in an attempt to divert attention form the main issue.  Separate /usr
> is actually a secondary issue.  The main issue is whether or not we get
> systemd rammed down our throats.  Lennart and Kay are the people
> responsible for scaring others into mdev and/or eudev.
> 
> First Kay...
> 
> And then Lennart...
> http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
> 
>   For those of us who do not want to build, let alone run, systemd,
> these 2 messages are more than sufficient justification for the eudev
> fork.

If only it were as easy to fork a government.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Bruce Hill]

On Fri, Jan 11, 2013 at 06:04:01AM -0800, walt wrote:
> This seems to me like very happy news indeed, but I'm interested in contrary
> opinions.  There's a recent thread discussing how udev-197 breaks lvm2, but
> that's a trivial fix once you know about it.
> 
> The problem is caused because many apps including lvm2 install their udev
> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
> first place IMO) and they should instead now go in /lib/udev/rules.d/.
> All you need to do is to re-emerge all of those packages *after* installing
> udev-197 and the config scripts will go in the correct place.
> 
> You should do this before rebooting the machine because lvm2 won't work until
> its udev scripts are in the correct directory.
> 
> Doesn't this seem to fix the problem with booting a separate /usr partition?
 
So, what you're telling us is that those "shmart fellers" who've been messing
up the init system That Just Works (TM) since at least last March, are finally
getting back to where they were with the last sane version of udev?

mingdao@server ~ $ eshowkw sys-fs/udev
Keywords for sys-fs/udev:
           |                           | u   |  
           | a a             p     s   | n   |  
           | l m   h i m m   p s   p   | u s | r
           | p d a p a 6 i p c 3   a x | s l | e
           | h 6 r p 6 8 p p 6 9 s r 8 | e o | p
           | a 4 m a 4 k s c 4 0 h c 6 | d t | o
-----------+---------------------------+-----+-------
   141-r1  | ~ ~ ~ + ~ ~ ~ ~ ~ ~ ~ ~ ~ | # 0 | gentoo
   146-r1  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   149     | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   151-r4  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   164-r2  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
[I]171-r9  | + + + + + + ~ + + + + + + | o   | gentoo
   171-r10 | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o   | gentoo
   195     | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   196-r1  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   197     | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | #   | gentoo
   197-r1  | ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ | o   | gentoo
  9999     | o o o o o o o o o o o o o | o   | gentoo
mingdao@server ~ $ ls -l /lib/udev/rules.d/
total 100
-r--r--r-- 1 root root 6539 Feb 20  2012 10-dm.rules
-r--r--r-- 1 root root 1286 Jul  7  2010 11-dm-lvm.rules
-r--r--r-- 1 root root 1011 Nov 13  2009 13-dm-disk.rules
-rw-r--r-- 1 root root  742 Nov 18 16:46 30-kernel-compat.rules
-rw-r--r-- 1 root root  349 Nov 18 16:46 40-gentoo.rules
-rw-r--r-- 1 root root  764 Nov 18 16:46 42-qemu-usb.rules
-rw-r--r-- 1 root root  219 Nov 18 16:46 50-firmware.rules
-rw-r--r-- 1 root root 3777 Nov 18 16:46 50-udev-default.rules
-rw-r--r-- 1 root root  392 Nov 18 16:46 60-cdrom_id.rules
-rw-r--r-- 1 root root  672 Nov 18 16:46 60-persistent-alsa.rules
-rw-r--r-- 1 root root 2457 Nov 18 16:46 60-persistent-input.rules
-rw-r--r-- 1 root root  889 Nov 18 16:46 60-persistent-serial.rules
-rw-r--r-- 1 root root 1423 Nov 18 16:46 60-persistent-storage-tape.rules
-rw-r--r-- 1 root root 5565 Nov 18 16:46 60-persistent-storage.rules
-rw-r--r-- 1 root root  785 Nov 18 16:46 60-persistent-v4l.rules
-rw-r--r-- 1 root root 1973 Feb 20  2012 64-md-raid.rules
-rw-r--r-- 1 root root  254 Nov 18 16:46 75-probe_mtd.rules
-rw-r--r-- 1 root root  657 Nov 18 16:46 80-drivers.rules
-rw-r--r-- 1 root root  280 Nov 18 16:46 90-network.rules
-r--r--r-- 1 root root  492 Nov  1  2009 95-dm-notify.rules
-rw-r--r-- 1 root root  155 Nov 18 16:46 95-udev-late.rules
-rw-r--r-- 1 root root   28 Oct 14 20:42 99-fuse.rules
-rw-r--r-- 1 root root   51 Dec 30 10:32 99-ntfs3g.rules
mingdao@server ~ $ ls -l /usr/lib/udev/
ls: cannot access /usr/lib/udev/: No such file or directory



Hmm ... maybe someone can replace Kay and Lennart and Do It Right (TM).
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Helmut Jarausch]

On 01/11/2013 03:04:01 PM, walt wrote:
> This seems to me like very happy news indeed, but I'm interested in  
> contrary
> opinions.  There's a recent thread discussing how udev-197 breaks  
> lvm2, but
> that's a trivial fix once you know about it.
> 
> The problem is caused because many apps including lvm2 install their  
> udev
> config scripts in /usr/lib/udev/rules.d/ (where they never belonged  
> in the
> first place IMO) and they should instead now go in /lib/udev/rules.d/.
> All you need to do is to re-emerge all of those packages *after*  
> installing
> udev-197 and the config scripts will go in the correct place.
> 
> You should do this before rebooting the machine because lvm2 won't  
> work until
> its udev scripts are in the correct directory.
> 
> Doesn't this seem to fix the problem with booting a separate /usr  
> partition?

Hi, does anybody know if files in /etc/udev/rules.d  like 10-local.rules
have to be moved to a different place?

Many thanks,
Helmut.

[gentoo-user] Re: udev-197 moves from /usr/lib to /lib

[walt]

On 01/12/2013 03:00 AM, Helmut Jarausch wrote:
> On 01/11/2013 03:04:01 PM, walt wrote:
>>
>> The problem is caused because many apps including lvm2 install their udev
>> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
>> first place IMO) and they should instead now go in /lib/udev/rules.d/.
 
> Hi, does anybody know if files in /etc/udev/rules.d  like 10-local.rules
> have to be moved to a different place?

No, they stay where they are.

Re: [gentoo-user] udev-197 moves from /usr/lib to /lib

[Canek Peláez Valdés]

On Sat, Jan 12, 2013 at 5:00 AM, Helmut Jarausch
<jarausch@igpm.rwth-aachen.de> wrote:
> On 01/11/2013 03:04:01 PM, walt wrote:
>>
>> This seems to me like very happy news indeed, but I'm interested in
>> contrary
>> opinions.  There's a recent thread discussing how udev-197 breaks lvm2,
>> but
>> that's a trivial fix once you know about it.
>>
>> The problem is caused because many apps including lvm2 install their udev
>> config scripts in /usr/lib/udev/rules.d/ (where they never belonged in the
>> first place IMO) and they should instead now go in /lib/udev/rules.d/.
>> All you need to do is to re-emerge all of those packages *after*
>> installing
>> udev-197 and the config scripts will go in the correct place.
>>
>> You should do this before rebooting the machine because lvm2 won't work
>> until
>> its udev scripts are in the correct directory.
>>
>> Doesn't this seem to fix the problem with booting a separate /usr
>> partition?
>
>
> Hi, does anybody know if files in /etc/udev/rules.d  like 10-local.rules
> have to be moved to a different place?

No; check src/udev/udev-rules.c, udev_rules_new(), which starts at 1578:

        rules->dirs = strv_new("/etc/udev/rules.d",
                               "/run/udev/rules.d",
                               "/usr/lib/rules.d",
                               "/lib/rules.d",
                               UDEVLIBEXECDIR "/rules.d",
                               NULL);

/etc/udev/rules.d has always been the first dir scanned for rules
(which means the rules in /etc will override any other rule), and as
far as I know nobody has ever suggested to move or change that.

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