Bugzilla Bug 189227

Until yesterday, I had a perfectly working gentoo-amd64 installation on a
nvidia RAID0 disk set, working with dmraid.
Everything worked fine, until the last emerge -uvDN world.

At boot, it now says it can't find "/dev/mapper/nvidia_eeaafdjb7" (my root
partition) any more and prompts me for a recovery shell.

In the recovery shell, I notice that /dev/mapper/nvidia_eeaafdjb7 is mounted
correctly in read-only.
However, ls /dev/mapper* gives zero results.
/dev/sda and /dev/sdb, on which the RAID image sits, are recognized correctly.

My /boot/grub/grub.conf has not been altered and is known to be working.
My gentoo-sources kernels, both the latest stable one and the recovery (older)
one, have not been altered and are known to be working.
The RAID partitions are recognized flawlessly by the 2007.0 livecd (booted with
"gentoo nox dmraid").

This is what I get from the recovery console:

(dmraid requires write access on /var/lock)
# mount -t tmpfs none /var/lock
# dmraid -dddddddvvvvvvvvtay
[...]
DEBUG: set status of set "nvidia_eeaafdjb" to 16
nvidia_eeaafdjb: 0 976794112 striped 2 128 /dev/sdb 0 /dev/sda 0
INFO: Activating stripe RAID set "nvidia_eeaafdjb"
NOTICE: discovering partitions on "nvidia_eeaafdjb"
NOTICE: /dev/mapper/nvidia_eeaafdjb: dos discovering
ERROR: opening "/dev/mapper/nvidia_eeaafdjb"

I didn't upgrade baselayout and I didn't do any changes to my config files. I
already ran etc-update and revdep-rebuild, just-in-case. The only package I can
think of having upgraded is dbus, from the -r1 to the -r2 of the latest
version.

So what exactly did you upgrade? We really cannot guess, emerge genlop and post
the output of if upgraded packages between working and non-working state.

As requested

[0m     Thu Aug 16 19:17:04 2007 >>>[1;32m sys-devel/gettext-0.16.1
[0m     Thu Aug 16 19:28:35 2007 >>>[1;32m sys-apps/dbus-1.0.2-r2
[0m     Thu Aug 16 19:30:14 2007 >>>[1;32m sys-apps/hal-0.5.9-r1
[0m     Thu Aug 16 19:52:26 2007 >>>[1;32m dev-libs/dbus-glib-0.73
[0m     Thu Aug 16 19:53:02 2007 >>>[1;32m dev-libs/apr-util-0.9.12-r1
[0m     Thu Aug 16 19:53:35 2007 >>>[1;32m dev-libs/apr-util-1.2.8
[0m     Thu Aug 16 20:19:19 2007 >>>[1;32m x11-misc/shared-mime-info-0.21-r1
[0m     Thu Aug 16 20:22:01 2007 >>>[1;32m sys-fs/udev-114
[0m     Thu Aug 16 20:31:35 2007 >>>[1;32m dev-libs/nspr-4.6.7

reverting to udev-104-r13 fixes the problem.

I guess this is because you dont have
/etc/udev.d/rules.d/64-device-mapper.rules with udev-114.

The new device-mapper ebuild should install this file instead.
Do you have updated only udev to 114, but not device-mapper ?

yes, my device-mapper is still version 1.02.19.
if this is the problem, device-mapper-1.02.19 and udev-114 should be marked as
mutually blocking.

(In reply to comment #5)
> yes, my device-mapper is still version 1.02.19.
> if this is the problem, device-mapper-1.02.19 and udev-114 should be marked as
> mutually blocking.

This is very similar to bug 188542.  I've added RDEPEND="${DEPEND}
!<sys-fs/udev-114" to device-mapper-1.02.19*.ebuild in my overlay and emerge
correctly adjusts the merge order to avoid the collision:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ] sys-fs/udev-114 [104-r13]
[ebuild     U ] sys-fs/device-mapper-1.02.19-r1 [1.02.10-r1]

I now added the blocker, to stop people updating only udev, but not
device-mapper.
I hope this will let this bug never re-appear.