# /dev/mapper is empty

## weiypan_us

after bootup(normal boot), KDE not running. found it is because may file system under lvm not mounted. 

run vgchange -ay and still can't find anything in /dev/mapper except control.

Need help on how to solve this problem.

----------

## weiypan_us

udevadm trigger

got error "udevadm: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory.

 *weiypan_us wrote:*   

> after bootup(normal boot), KDE not running. found it is because may file system under lvm not mounted. 
> 
> run vgchange -ay and still can't find anything in /dev/mapper except control.
> 
> Need help on how to solve this problem.

 

----------

## krinn

```
equery b libidn.so.11

net-dns/libidn-1.33 (/usr/lib64/libidn.so.11 -> libidn.so.11.6.16)

net-dns/libidn-1.33 (/usr/lib32/libidn.so.11 -> libidn.so.11.6.16)

```

If you don't have the library: emerge -1 net-dns/libidn

If you have the lib but not .11 : revdep-rebuild -L /usr/lib64/libidn.so.11

----------

## weiypan_us

except net-dns/libidn-1.33-r2, I have all the same as you listed.

 *krinn wrote:*   

> 
> 
> ```
> equery b libidn.so.11
> 
> ...

 

----------

## weiypan_us

after revdep-rebuild -L /usr/lib64/libidn.so.11, It remain the same. 

 *krinn wrote:*   

> 
> 
> ```
> equery b libidn.so.11
> 
> ...

 

----------

## weiypan_us

the libidn.so.11 resides on /usr/lib64 which is not root file system. 

In order for udev trigger files under /dev/mapper/, the libidn.so.11 should be available before /usr/lib64 mounted. that become a loop dependent. 

Does any one know how to solve it?

----------

## krinn

There's no solve to your problem, use non broken programs with /usr mount or don't use /usr mount.

If you want fix it (assuming udevadm only breaks because of libidn), you can rebuild libdn and make it install its files in /lib instead of /usr/lib or build a static-libs udevadm.

But looking at my own udevadm list, i don't see why yours complain for something it have no use.

```
   linux-vdso.so.1 (0x00007ffcc49e2000)

   libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fea925fa000)

   libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fea923e0000)

   libc.so.6 => /lib64/libc.so.6 (0x00007fea92047000)

   /lib64/ld-linux-x86-64.so.2 (0x00007fea92854000)

   libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fea91e41000)

   libz.so.1 => /lib64/libz.so.1 (0x00007fea91c23000)

```

Nothing from /usr for my udevadm, dunno why yours have that dep.

----------

## weiypan_us

My problem has been worked around by down grade udev back to udev-233 from udev-236. 

Still wonder why udev-236 not work on my machine.

----------

## krinn

Try eudev, it sucks less.

----------

## weiypan_us

Thanks krinn for advice, my box has migrated to eudev.

----------

## krinn

Your problem is fix with eudev?

----------

## weiypan_us

Hi Krinn, unlike udev-236, I didn't encounter any problem afrer move onto eudev  3.2.5.

----------

## krinn

You could mark title solve.

But you should also knows that eudev is base on udev, and follow it. What i mean by that is eudev version X is udev version X-? code, and newer version of eudev will at a time reach the udev version that break /usr.

So you should:

* prepare and plan to migrate your configuration, because you have win delays, but the problem will be back.

* as part of "prepare", you may try ring a bell to eudev's devs about the issue to warn them against it, and have a future versions of eudev not doing the same shit as udev.

* do nothing and hope eudev's devs may see the problem and fix it.

* do nothing and eudev's devs may see the problem but won't fix it (if nobody complains, there's nothing to fix).

So it's important that you do that "prepare" step, you should ring eudev's devs bell about it and see what they have to say ; if they tell you they won't fix that, you will be in trouble again, portage personal overlay may gives you a few more time, but your setup is in a dead end and either you should look at changing it or use another dev manager.

Note that because of the stupid decision from council eudev's devs have no need to fix it and it's only up to them to do it or not.

----------

