After upgrading util-linux to version 2.13 I get the following error message during boot: * Failed to find mount point for tmp, skipping This message is displayed by /lib/rcscripts/addons/dm-crypt-start.sh because it can't find the dm-crypt mapping in /proc/mounts. Before util-linux-2.13 this mapping was shown in /proc/mounts as: /dev/mapper/tmp /tmp ext2 rw,noatime 0 0 After upgrading and rebooting the mapping is now shown as: /dev/dm-1 /tmp ext2 rw,noatime 0 0 After downgrading to util-linux-2.12r-r7 and rebooting things work again as they used to. Reproducible: Always Steps to Reproduce: My entry in /etc/conf.d/cryptfs: target=tmp source='/dev/sda3' options='-c aes-cbc-essiv:sha256 -s 256 -d /dev/urandom' pre_mount='/sbin/mke2fs ${dev}' post_mount='chown root:root ${mount_point}; chmod 1777 ${mount_point}' My entry in /etc/fstab: /dev/mapper/tmp /tmp ext2 noatime 0 0
*** Bug 190853 has been marked as a duplicate of this bug. ***
*** Bug 191178 has been marked as a duplicate of this bug. ***
*** Bug 191316 has been marked as a duplicate of this bug. ***
This is not a bug in util-linux (or device-mapper) but in gentoo itself. It is triggered by merging >=device-mapper-1.02.22 and >=util-linux-2.13. It looks like someone got creative with the udev rules http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-fs/device-mapper/files/64-device-mapper.rules-1.02.22?rev=1.1&view=log while bumping the package and fixing another bug, bug 189404. The bug only happens with the new util-linux since it now mounts the target rather than the symlink itself, as per this unit test: http://git.kernel.org/?p=utils/util-linux-ng/util-linux-ng.git;a=commit;h=d20b54c4bbd757f0f2604a2f3ac295961100fedd It's going to bite anyone that relies on the dm-* scripts to boot (ie, encrypted /var or the like). Solution is to revert to =device-mapper-1.02.19-r1 (udev won't ley you go lower) beacuse portage installs the old, sane udev rules with that version.
We have three possible solutions: 1. Change dmcrypt script to not rely on /dev/mapper/* be listed in mount output. 2. Change udev rules to no longer touch /dev/mapper in any way. This requires us to re-add "dmsetup mknodes" to boot scripts. 3. Change udev rules the easy way: Set NAME to /dev/mapper/* and change dm-* to be a symlink on it. Among these, 2 is nearest to upstream. 3 is easiest to implement.
(In reply to comment #5) > We have three possible solutions: > 1. Change dmcrypt script to not rely on /dev/mapper/* be listed in mount > output. > 2. Change udev rules to no longer touch /dev/mapper in any way. This requires > us to re-add "dmsetup mknodes" to boot scripts. This seems to me to be the best one, as this bug is not just about dmcrypt. It's also about, that df now produces useless results on LVM systems.
(In reply to comment #6) > (In reply to comment #5) > > We have three possible solutions: > > 1. Change dmcrypt script to not rely on /dev/mapper/* be listed in mount > > output. > > 2. Change udev rules to no longer touch /dev/mapper in any way. This requires > > us to re-add "dmsetup mknodes" to boot scripts. > > 3. Change udev rules the easy way: Set NAME to /dev/mapper/* and change dm-* to > >be a symlink on it. > > This seems to me to be the best one, as this bug is not just about dmcrypt. > It's also about, that df now produces useless results on LVM systems. > If this is the only thing the decision should be based on, then 3 also solves the problem and additionally is easier to implement.
zzam: please get one of these fixes into the tree very soon. I would like to have device-mapper-1.02.22-r3 and lvm2-2.02.28-r2 in the 2007.1 stable release, and this is a holdup.
Implemented Point 3 from Comment #5 in device-mapper-1.02.22-r5. For now this should fix this issue. Maybe we can implement point 2 some time later if it is more time to test changes.
That solved the problem for me, thank you!
thanks, closing this, then we can see about starting stabilization.
