In order to emerge udev-145-r1 I had to unmerge lvm2, cryptsetup and device-mapper. Now when booting I get an error message "ERROR: device-mapper failed to start". Reproducible: Always Steps to Reproduce: 1. unmerge blocking packages (e.g. lvm2, cryptsetup, device-mapper) 2. emerge =sys-fs/udev-145-r1 3. emerge --pretend --update --verbose --deep --newuse world Actual Results: Errors after emerging udev-145-r1, include: ('installed', '/', 'sys-fs/udev-145-r1', 'nomerge') pulled in by >=sys-fs/udev-117 required by ('installed', '/', 'sys-apps/hal-0.5.13-r2', 'nomerge') sys-fs/udev required by ('installed', '/', 'app-emulation/xen-tools-3.4.1-r1', 'nomerge') sys-fs/udev required by ('installed', '/', 'sys-kernel/gentoo-sources-2.6.24-r8', 'nomerge') (and 7 more) ('ebuild', '/', 'sys-fs/device-mapper-1.02.24-r1', 'merge') pulled in by >=sys-fs/device-mapper-1.00.07-r1 required by ('ebuild', '/', 'sys-fs/cryptsetup-1.0.6-r2', 'merge') (even though cryptsetup *has* been unmerged (twice -- with no errors) And then of course the init "device-mapper failed to start" error, presumably because unmerging device-mapper failed to remove /etc/rc.d/*/device-mapper. Expected Results: I should be able to upgrade to the most recent udev, and it should support encrypted file systems (e.g. cryptsetup), logical volumes (lvm2 or some equivalent), and device-mapper.
Created attachment 203550 [details] emerge --info for problematic udev / device-mapper Yes, I know this is an "almost released" 2.6.31-rc9 kernel, but I really doubt that is the source of the problem -- and it would need to be fixed anyway before Gentoo can release the 2.6.31 kernel sources.
I'm sure you shouldn't uninstall all these packages. device-mapper is included in lvm2 since 2.02.45?. So get a rid of device-mapper, install lvm2 >= 2.02.45 and everything should be ok.
Yeah, just installing lvm2 and unmerging device-mapper should be fine.
I'm not using lvm. I switched off by sys-apps/hal "crypt" flag and then unmerged device-mapper. Blocking package is resolved but I'm not shure is this really gut solution ? Now I do full system update, we will see.
AFAICT, this "bug" is a documentary on "how I mishandled udev upgrade". Yes, udev, cryptsetup and device-mapper/lvm2 do have all those blocks, but during a world upgrade, portage does handle all of these properly, in most of the cases (well, perhaps except device-mapper -> lvm2 move, but that one is not so trivial). That's because during 'emerge -1pv udev' only some of the deps were calculated. I suspect that if that was 'emerge -1pv udev cryptsetup lvm2' the upgrade would be smooth. IIRC, before udev got that block on all of device-mapper versions, 'emerge -1pv udev cryptsetup device-mapper' did solve the problem for me. Only complication now is having to know about device-mapper -> lvm2 move.
WAD, not a bug.
Probably no one is listening any more, since this has been closed invalid. And I'll get around it, temporarily anyway, by forcing <=udev-145 instead of >=udev-145-r1 in my package.mask file. Done it before, will do it again :^) However... - One desires to have both udev and hal installed, no? (Is this my error? If it is, I can hardly understand how this is possible) - lotsa stuff depends on hal - hal (among other stuff) depends/RDEPENDs on udev - hal-0.5.13-r2 (latest version in portage) depends on cryptsetup - cryptsetup-1.0.6-r2 (latest version in portage) depends on >=sys-fs/device-mapper-1.00.07-r1 - udev-145-r1 and higher RDEPENDs on !sys-fs/device-mapper - Ergo, it's impossible to have both udev-145-r1 and higher and hal-0.5.13-r2 simultaneously installed without a portage conflict. Does one of these ebuilds need rewriting? I'm guessing the newer udev ebuilds provide functionality previously provided by device-mapper, hence the block??? Please correct me if my logic is wrong. And please let me know if I should open a new bugzilla report repeating this info chain. TIA. Clemmitt
Posting again for clarity in case anyone else stumbles on this closed bug. Apologies for added verbiage. Additional research via Google led me to find bug report Gentoo Bug 283727. That report indicates that sys-fs/lvm2 (presently unstable versions, which block sys-fs/device-mapper) needs to be installed to provide functionality previously provided by device-mapper. I've never used lvm2 before because I don't use logical volume management on my laptop. HTH. Clemmitt
sys-fs/udev-146-r1, unmasked on x86, got released some time around Nov 7-8, 2009. This means the problem is now visible to everyone. In essence the latest device-mapper does not work with the latest udev, so has to be unmerged. This is not possible by default because hal (required by pretty much everything in a desktop environment) supports disk-level encryption via cryptsetup by default and this, in turn, pulls in device-mapper. This fix worked for me. If *no disk level encryption is in use* add to package.use: sys-fs/hal -crypt then: emerge --newuser --deep --update world # removes sys-fs/device-mapper emerge --unmerge sys-fs/cryptsetup revdep-rebuild # should do nothing This will remove support for disk level encryption though - on systems with encrypted disks the only obvious option is to mask sys-fs/udev-146-r1.
@comment #9 and for users having 'cryptsetup' emerged: It is not needed to mask the new versions of udev. Simply unmerge device-mapper and then emerge lvm2. (I also re-emerged cryptsetup but that might not be necessary.) Works here.
Same here with almost all stable packages. Resolved adding -crypt to my USE flags. I think the problem is on how the crypt flag is used by default. IMHO it should not be active by default, since 98% of users are not using cryptsetup's functionalities. At least, as far as I know..... Thanks!
(In reply to comment #10) > @comment #9 and for users having 'cryptsetup' emerged: > > It is not needed to mask the new versions of udev. > Simply unmerge device-mapper and then emerge lvm2. > (I also re-emerged cryptsetup but that might not be necessary.) > > Works here. > Unfortunately, I can't seem to emerge lvm2-2.02.51-r1. It keeps trying to pull in -ldevmapper which causes an error because I unmerged the device mapper. This is really annoying, as I can't figure out how to upgrade my machine. i686-pc-linux-gnu-gcc -O2 -pipe -O2 -pipe -fPIC -Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wmissing-noreturn -Wformat-security -O2 -O2 -pipe -fPIC -Wall -Wundef -Wshadow -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wmissing-noreturn -Wformat-security -O2 -Wl,-O1 -Wl,-O1 -Wl,--export-dynamic -L./libdm -L./lib -L./daemons/dmeventd -Wl,-O1 -Wl,--export-dynamic -L../libdm -L../lib -L../daemons/dmeventd \ -L../libdm \ -o dmsetup dmsetup.o \ -ldevmapper -lreadline -lrt -ldl -lncurses -llvm-internal -ldevmapper-event -lpthread -ldevmapper /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld: cannot find -ldevmapper-event collect2: ld returned 1 exit status make[1]: *** [dmsetup] Error 1 make[1]: Leaving directory `/var/tmp/portage/sys-fs/lvm2-2.02.51-r1/work/LVM2.2.02.51/tools' make: *** [tools.device-mapper] Error 2 * * ERROR: sys-fs/lvm2-2.02.51-r1 failed.
> If *no disk level encryption is in use* add to package.use: > > sys-fs/hal -crypt > Actually, it is sys-apps/hal -crypt or even more to the point, for the lazy copypasters : echo "sys-apps/hal -crypt" >> /etc/portage/package.use This definitely worked for me. But it needs to be fixed. I'm happy not to rely on LVM2 (waiting for ZFS, someday), but this seems to break a lot of systems.
