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@×××××.com> wrote:
> On Fri, Jan 11, 2013 at 4:03 PM, Canek Peláez Valdés <caneko@×××××.com> wrote:
>> On Fri, Jan 11, 2013 at 3:39 PM, Sascha Cunz <sascha-ml@×××××××××.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@g.o>
> 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