After upgrading from sys-fs/device-mapper-1.02.19-r1 to sys-fs/device-mapper-1.02.22-r5, I no longer had LVM working. Error message: * Setting up the Logical Volume Manager... /dev/mapper/control: stat failed: Too many levels of symbolic links /dev/mapper/control: mknod failed: File exists Failure to communicate with kernel device-mapper driver. The problem seems to be that /dev/mapper/control is a symlink pointing to itself. My /dev is managed by udev, I have RC_DEVICE_TARBALL="no" in /etc/conf.d/rc. Workaround to get the system up: rm /dev/mapper/control vgchange -a y mount -a After a downgrade to 1.02.19-r1, all was fine again. There must be something special about my setup, because by searching existing bugs and googling I only found one posting of someone having the same problem, in the german gentoo forum: http://forums.gentoo.org/viewtopic-p-4546208.html?sid=ee84c1c6c3f066cc00a3b78d99af2f2c But as this is critical, I thought I'd better report it. Portage 2.1.3.19 (default-linux/x86/2006.1, gcc-4.1.2, glibc-2.6.1-r0, 2.6.18-suspend2-r1-knork i686) ================================================================= System uname: 2.6.18-suspend2-r1-knork i686 Pentium III (Coppermine) Timestamp of tree: Sun, 02 Dec 2007 15:45:04 +0000 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.3.5-r3, 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 dev-util/confcache: 0.4.2 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=pentium3 -O2 -pipe" DISTDIR="/data/stuff/portage/distfiles" FEATURES="autoaddcvs candy ccache distcc distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/data/stuff/portage/tmp" PORTDIR="/usr/portage/tree" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aac aalib acl acpi alsa artswrappersuid avi bash-completion berkdb bitmap-fonts bzlib cdr cli cracklib crypt cups curl dbus dri dvd encode fam fbcon ffmpeg firefox fortran ftp gdbm gif gpm gs gstreamer hal iconv imagemagick imlib ipv6 isdnlog jabber java jbig jpeg jpeg2k kde lzw mad mhash midi mikmod mmx mp3 mpeg mudflap musicbrainz ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre pdf perl php png ppds pppd python quicktime readline real recode reflection rtc ruby samba session slp spl ssl startup-notification svga tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb vidix vorbis win32codecs wmf x86 xine xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="mga vga vesa fbdev nv" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
udev version, please...
It's 115-r1. Oh, I forgot to mention I also downgraded lvm2 to 2.02.10 because I first thought that was the problem.
/dev/mapper/control should be a symlink pointing to /dev/device-mapper, and is on all of my machines. If you reboot, does the problem re-occur? Could you please trace what is creating the bad symlink?
Well, it occurs on every boot when the new device-mapper 1.02.22-r5 is installed. With the old 1.02.19-r1 version (and the old lvm2 2.02.10, because with masked device-mapper I also have to mask the new lvm2), all is fine again. Do you have a suggestion how I should trace this? I do not really have an idea where this happens. I thought it was /etc/init.d/device-mapper, but that tells me it is for baselayout-2 only which is masked for me. There are two udev rules (KERNEL=="device-mapper", NAME="mapper/control") that should do it I guess. Maybe I could insert a 'ls -l /dev/mapper' into the loop of /etc/init.d/modules? I will try this tomorrow.
The baselayout2 /etc/init.d/device-mapper only exists to call the dm-start.sh addon file, which was called directly by baselayout1. Upgrade back to udev-117 and device-mapper-1.02.22-r5.ebuild The udev rule you mention: KERNEL=="device-mapper", NAME="mapper/control" Where are you getting that? That's not part of udev-115-r1 or newer, nor device-mapper-1.02.22-r5. Here's my box: # grep -r mapper/control /etc/udev/ /etc/udev/rules.d/64-device-mapper.rules:KERNEL=="device-mapper", SYMLINK+="mapper/control"
*** Bug 201140 has been marked as a duplicate of this bug. ***
After looking at Bug 201140, I replaced the SYMLINK+= with NAME= in 64-device-mapper, and all is fine again. This is how it looks now: # grep mapper/control * 10-udev.rules:KERNEL=="device-mapper", NAME="mapper/control" 64-device-mapper.rules:#KERNEL=="device-mapper", SYMLINK+="mapper/control" 64-device-mapper.rules:KERNEL=="device-mapper", NAME="mapper/control" Yesterday, I misread the output and did not notice the 2nd one was a SYMLINK statement, sorry for that. I still wonder why this affects so few people. Does 10-udev.rules with the correct statement work for them, so the 2nd rule on 64-device-mapper.rules does not apply?
it looks like you didn't do etc-update properly at some point, because: 10-udev.rules:KERNEL=="device-mapper", NAME="mapper/control" from your output, is NOT in what is installed by udev-115-r1, but was in older versions. Please try to get rid of all of the rules except the SYMLINK one, and see if it's still created. If that still fails, try udev-117 like I requested.
It seems to me that the resolution of this bug is to either change udev to overwrite its rules automatically (without etc-update) or change device-mapper to use etc-update for its udev rules. As it stands, if someone updates from the udev included in the current stage3 tarball to the current x86 or x86_64 and uses the current device-mapper and forgets to etc-update before rebooting then they will have problems with lvm. This is very likely on a new install. An update that bricks someone's box just isn't good. I vote for making device-mapper use etc-update for its udev rules. This will make it consistant with most other udev rule supplying packages.
> I vote for making device-mapper use etc-update for its udev rules. This will > make it consistant with most other udev rule supplying packages. You imply that it was responsible for not using etc-update presently. /etc/udev/rules.d/ is excluded from etc-update by >=udev-115-r1, and that effects anything installed in the directory - the problem in this bug seems to be that wonko's system did not get the updated udev rules that shipped with 115-r1 - I suspect because of having an older version of udev that didn't apply the CONFIG_PROTECT_MASK ahead of time.
I didn't realize that udev was preventing the etc-update thing. I also just noticed that x86_64 is still using udev 115-r1. The more I look at it, the more I think that this is the real problem (thus I rescind my original proposal). udev-115-r1 has rules that are incompatible with device-mapper-1.02.22-r5. Upgrading udev to 117 fixes the whole thing. Staying at udev-115-r1 and device-mapper-1.02.19-r1 also fixes the problem. Maybe a block would be simpler. Or keywording device-mapper-1.02.22-* or unkeywording udev-117.
We should finally take some action here. It's not funny to find a server not working because of missing LVM mounts. This should be fixed in Portage without further delay.
Can someone mask this package?
no, that is not an acceptable "fix"
Excuse me? And leaving it in the current state is better? This bug is marked as critical for quite some time now and it would be really nice to get a broken package that is marked as stable back into a usable state.
fix the real problem instead of ignoring it
(In reply to comment #12) > We should finally take some action here. It's not funny to find a server not > working because of missing LVM mounts. This should be fixed in Portage without > further delay. > So what should be fixed in Portage? Having 10-udev.rules? I maintain udev, and do not remember we ever had this file. So where from is it? And why do you have this in it: KERNEL=="device-mapper", NAME="mapper/control" Nevertheless there was a bug in udev-115 (and I guess also in our 115-r1 ebuild), that got fixed in udev-116 that made udev behave strange in case SYMLINK pointed to the same name as NAME. So the only possible action I can think of is: request a newer udev stable.
(In reply to comment #17) > Nevertheless there was a bug in udev-115 (and I guess also in our 115-r1 > ebuild), that got fixed in udev-116 that made udev behave strange in case > SYMLINK pointed to the same name as NAME. > > So the only possible action I can think of is: request a newer udev stable. > I'm fine with that. In fact that is how I fixed the issue on the server that is running LVM. I have sys-fs/udev-118-r3 running there.
119 is stable on all archs that lvm2 is available on (with the exception of mips), so I think we can close this bug now, since it wanted 118 or newer stable.
