Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 330651 - lvm2 udev scripts do not properly set up /dev: udev permissions rules on my LVM don't run
Summary: lvm2 udev scripts do not properly set up /dev: udev permissions rules on my L...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-31 19:30 UTC by Joe Harvell
Modified: 2024-03-03 22:06 UTC (History)
22 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
udev debug log without any workaround (udev.bad.log,705.67 KB, text/plain)
2010-07-31 19:34 UTC, Joe Harvell
Details
udev debug log when I have the rule in 10-dm.rules commented out (udev.workaround.log,755.47 KB, text/plain)
2010-07-31 19:36 UTC, Joe Harvell
Details
output of udevadm monitor as requested by Comment #13 (udevmonitor.txt,6.88 KB, text/plain)
2010-08-04 17:01 UTC, Joe Harvell
Details
bziped debug output of udev while executing command requested in Comment #13 (udev.log.bz2,69.96 KB, application/octet-stream)
2010-08-04 17:09 UTC, Joe Harvell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Harvell 2010-07-31 19:30:50 UTC
I have the following rule in /etc/udev/rules.d/99-local.rules:
ENV{DM_NAME}=="firenza-idb_ts0", OWNER="mysql", GROUP="mysql", MODE="660"

However, this rule never matches at boot time, so my LVM database partition can't be read by mysql.

Here's the sysfs node for the LVM VG in question:
joey@cujo ~ $ cat /sys/devices/virtual/block/dm-4/dm/name
firenza-idb_ts0

The behavior I expect is that the following entries be present in dev after /etc/init.d/udev runs from sysinit.

joey@cujo ~ $ ls -l /dev/dm-4
brw-rw---- 1 mysql mysql 254, 4 Jul 31 12:31 /dev/dm-4
joey@cujo ~ $ ls -l /dev/mapper/firenza-idb_ts0
lrwxrwxrwx 1 root root 7 Jul 31 12:30 /dev/mapper/firenza-idb_ts0 -> ../dm-4
joey@cujo ~ $ ls -l /dev/firenza/idb_ts0
lrwxrwxrwx 1 root root 7 Jul 31 12:30 /dev/firenza/idb_ts0 -> ../dm-4

The actual behavior is that /etc/init.d/udev in sysinit fails to create the /dev/mapper/* and /dev/firenza/* devices as it should.  So instead /etc/init.d/lvm (from boot runlevel) creates the devices itself as individual block devices.  The result after boot is as follows:

joey@cujo ~ $ ls -l /dev/dm-4
brw-rw---- 1 root disk 254, 4 Jul 31 12:36 /dev/dm-4
joey@cujo ~ $ ls -l /dev/mapper/firenza-idb_ts0
brw------- 1 root root 254, 4 Jul 31 12:37 /dev/mapper/firenza-idb_ts0
joey@cujo ~ $ ls -l /dev/firenza/idb_ts0
lrwxrwxrwx 1 root root 27 Jul 31 12:37 /dev/firenza/idb_ts0 -> /dev/mapper/firenza-idb_ts0


Reproducible: Always

Steps to Reproduce:
1. boot the system
Actual Results:  
The actual behavior is that /etc/init.d/udev in sysinit fails to create the /dev/mapper/* and /dev/firenza/* devices as it should.  So instead /etc/init.d/lvm (from boot runlevel) creates the devices itself as individual block devices.  The result after boot is as follows:

joey@cujo ~ $ ls -l /dev/dm-4
brw-rw---- 1 root disk 254, 4 Jul 31 12:36 /dev/dm-4
joey@cujo ~ $ ls -l /dev/mapper/firenza-idb_ts0
brw------- 1 root root 254, 4 Jul 31 12:37 /dev/mapper/firenza-idb_ts0
joey@cujo ~ $ ls -l /dev/firenza/idb_ts0
lrwxrwxrwx 1 root root 27 Jul 31 12:37 /dev/firenza/idb_ts0 -> /dev/mapper/firenza-idb_ts0


Expected Results:  
The behavior I expect is that the following entries be present in dev after /etc/init.d/udev runs from sysinit.

joey@cujo ~ $ ls -l /dev/dm-4
brw-rw---- 1 mysql mysql 254, 4 Jul 31 12:31 /dev/dm-4
joey@cujo ~ $ ls -l /dev/mapper/firenza-idb_ts0
lrwxrwxrwx 1 root root 7 Jul 31 12:30 /dev/mapper/firenza-idb_ts0 -> ../dm-4
joey@cujo ~ $ ls -l /dev/firenza/idb_ts0
lrwxrwxrwx 1 root root 7 Jul 31 12:30 /dev/firenza/idb_ts0 -> ../dm-4


Additionaly, I see the following in /var/log/rc.log:

 * Setting up the Logical Volume Manager ...
[snip]
  The link /dev/firenza/idb_ts0 should had been created by udev but it was not found. Falling back to direct link creation.
[snip]

Here's what the udev db shows for this sysfs device:
joey@cujo ~ $ cat /dev/.udev/db/block\:dm-4
N:dm-4
S:block/254:4
E:DM_SBIN_PATH=/sbin
E:DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E:DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E:DM_UDEV_DISABLE_OTHER_RULES_FLAG=1

I have udev_debug="YES" in /etc/conf.d/udev, so I will also be attaching /dev/.udev/udev.log.

I can work around this problem and get the exepcted behavior if I comment out one rule in /lib64/udev/rules.d/10-dm.rules as follows:

# "add" event present. We have to recognize this and do our actions in this
# particular situation, too. Also, we don't want the nodes to be created
# prematurely on "add" events while not coldplugging. We check
# DM_UDEV_PRIMARY_SOURCE_FLAG to see if the device was activated correctly
# before and if not, we ignore the "add" event totally. This way we can support
# udev triggers generating "add" events (e.g. "udevadm trigger --action=add" or
# "echo add > /sys/block/<dm_device>/uevent"). The trigger with "add" event is
# also used at boot to reevaluate udev rules for all existing devices activated
# before (e.g. in initrd). If udev is used in initrd, we require the udev init
# script to not remove the existing udev database so we can reuse the information
# stored at the time of device activation in the initrd.
#
#
#Disabling this check. On this system the result of this rule is that LVM
#adds the nodes itself, but the udev rules I have that match on DM_NAME
#never get run.
#ACTION=="add", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"

I don't understand what's going on from the description above.  I just know commenting out the above rule gives the desired result.

I have my own custom initrd based on buysbox.  The init script below shows what it is doing:

#!/bin/busybox sh

rescue_shell()
{
        modprobe ehci_hcd
        modprobe uhci_hcd
        modprobe usbhid
        busybox --install -s
        exec busybox sh
}

export PATH=/bin:/sbin
mount -n -t proc none /proc
mount -n -t sysfs none /sys
modprobe ahci
modprobe sd_mod
modprobe dm-mod
modprobe ext4
lvm vgscan
lvm vgchange -ay firenza
mount -o ro /dev/firenza/root /mnt || rescue_shell
umount /proc
umount /sys
exec switch_root /mnt /sbin/init

lvm is a static executable, every other command referenced here is part of busybox


joey@cujo /opt/kernel/initramfs/v1 $ emerge --info
Portage 2.2_rc67 (default/linux/amd64/10.0, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-gentoo-r2-cujo x86_64)
=================================================================
System uname: Linux-2.6.34-gentoo-r2-cujo-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-gentoo-2.0.1
Timestamp of tree: Mon, 26 Jul 2010 05:15:03 +0000
app-shells/bash:     4.1_p7
dev-lang/python:     2.6.5-r3, 3.1.2-r4
dev-util/cmake:      2.8.1-r2
sys-apps/baselayout: 2.0.1
sys-apps/openrc:     0.6.1-r1
sys-apps/sandbox:    2.2
sys-devel/autoconf:  2.65-r1
sys-devel/automake:  1.11.1
sys-devel/binutils:  2.20.1-r1
sys-devel/gcc:       4.4.4-r1
sys-devel/gcc-config: 1.4.1
sys-devel/libtool:   2.2.10
virtual/os-headers:  2.6.34
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA dlj-1.1 sun-bcla-java-vm AdobeFlash-10.1"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe -ggdb"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe -ggdb"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms splitdebug strict unmerge-logs unmerge-orphans userfetch userpriv"
GENTOO_MIRRORS="http://gentoo.mirrors.tds.net/gentoo http://mirror.espri.arizona.edu/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/"
LDFLAGS="-Wl,-O1"
LINGUAS="en_US fr"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/opt/portage"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="X Xaw3d a52 aac accessibility acl acpi adns alsa amd64 ao apache2 audiofile bash-completion bidi bs2b bzip2 cairo caps cdda cddb cdparanoia cdr cli consolekit crypt curl cxx dbus dga dio dirac directfb doc dri dts dv dvb dvd dvdr dvdread dxr3 enca encode exif fbcon ffmpeg fftw firefox flac freetds gd geoip gif gnutls gpm hardened ieee1394 innodb ipod ipv6 java javascript jpeg jpeg2k kde kdexdeltas lastfm lirc lm_sensors logrotate lua mad memlimit mmap mmx modules mp3 mpeg mplayer mtp mudflap multilib mysql mysqli nis nls nptl nptlonly nsplugin odbc offensive ogg opengl openmp pam pcntl png policykit posix pppd python python3 qt3 qt3support qt4 quicktime readline reflection samba sasl semantic-desktop sharedmem sndfile sockets sox sqlite sqlite3 sse sse2 ssl svg sysfs sysvipc theora threads tiff truetype udev unicode usb v4l vdpau vorbis wxwindows x264 xine xinerama xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul 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 cgi cgid 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="en_US fr" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="dummy fbdev nv nvidia vga vmware" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Joe Harvell 2010-07-31 19:34:48 UTC
Created attachment 240871 [details]
udev debug log without any workaround
Comment 2 Joe Harvell 2010-07-31 19:36:01 UTC
Created attachment 240873 [details]
udev debug log when I have the rule in 10-dm.rules commented out
Comment 3 Joe Harvell 2010-07-31 19:39:15 UTC
Additional info:

joey@cujo /opt/kernel/initramfs/v1 $ equery list -i lvm2
 * Searching for lvm2 ...
[IP-] [  ] sys-fs/lvm2-2.02.70:0
joey@cujo /opt/kernel/initramfs/v1 $ equery list -i udev
 * Searching for udev ...
[IP-] [  ] sys-fs/udev-160:0
joey@cujo /opt/kernel/initramfs/v1 $ uname -a
Linux cujo 2.6.34-gentoo-r2-cujo #10 SMP PREEMPT Tue Jul 27 23:29:50 CDT 2010 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
Comment 4 Alasdair Kergon 2010-07-31 20:18:35 UTC
The supported upstream method is to install this template: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/udev/12-dm-permissions.rules?rev=1.6&content-type=text/x-cvsweb-markup&cvsroot=lvm2  and uncomment/duplicate/lines in it as required.

Comment 5 Joe Harvell 2010-08-01 00:46:53 UTC
(In reply to comment #4)
problem is that none of the attributes referenced in those rules is being defined. It's because 10-dm.rules has a rule that is skipping all the rules in that file if DM_UDEV_PRIMARY_SOURCE_FLAG is not 1. 
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2010-08-03 18:09:05 UTC
agk:
1. Just wondering, why isn't 12-dm-permissions.rules listed in the Makefile.in (as of 2.02.72 at least)? All the other .rules files are.
2. See the users's comment about DM_UDEV_PRIMARY_SOURCE_FLAG not being set.
Comment 7 Alasdair Kergon 2010-08-03 18:58:54 UTC
Because upstream udev decided editable files should be installed in a different place from the non-editable files.  Looks like we're installing them as 'documentation' in Fedora!  Yes, we should fix that and provide a Makefile target to install them to a configuration location.  Peter - agree?
Comment 8 Peter Rajnoha 2010-08-04 07:10:38 UTC
(In reply to comment #6)
> 1. Just wondering, why isn't 12-dm-permissions.rules listed in the Makefile.in
> (as of 2.02.72 at least)? All the other .rules files are.

Well, 12-dm-permissions.rules are supposed to be installed in /etc/udev/rules.d/ (user defined/customized rules) instead of /lib/udev/rules.d/ (firm rules that the user never touches directly).

If we add this into the Makefile/package install - yes, we could, probably. But then we need to detect whether there is any existing 12-dm-permissions.rules and if yes, we shouldn't overwrite it so those user settings are not lost with each make install/update.

I think this was the only reason we didn't do that at first. Instead, we gave each distro the freedom to choose the right action here (as Alasdair pointed out in previous comment, in Fedora, we put that simply in the "doc" for the user so he can manually use that if needed and do his own editings).

> 2. See the users's comment about DM_UDEV_PRIMARY_SOURCE_FLAG not being set.
> 

The DM_UDEV_PRIMARY_SOURCE_FLAG is something we've introduced recently to support all the synthesized uevents such as those that are generated while running "udevadm trigger" or "echo add/change > /sys/block/dm-X/uevent".

The problem here was that DM devices should react only on CHANGE event, because it's the event after which the device is properly resumed (with previous "device create" and "table load" ioctl). The device is usable only after this "device resume". So we can't actually react on pure ADD events like most of other devices do (the skeleton of a DM device is created at this time only - major/minor number assigned, but there's no table loaded yet and so it's unusable and we really don't want to create any content in /dev for such devices).

Furthermore, in normal operation, the DM_UDEV_PRIMARY_SOURCE_FLAG is always set when the source of the uevent is the action triggered by libdevmapper (and so the LVM which uses it).

On the other hand, udev init script uses "udevadm trigger" to repopulate the /dev content for devices which were already activated before (...during initrd stage). This trigger generates synthesized events. These ones do not have DM_UDEV_PRIMARY_SOURCE_FLAG set. That's how we can make a difference:

  - for all original DM uevents (having DM_UDEV_PRIMARY_SOURCE_FLAG set), we know we have all the information needed to create the /dev content correctly. We always pass this information in DM_COOKIE variable which is decoded in our udev rules. This information is here to direct the rule application, e.g. telling other udev rules to avoid touching this device...

  - for all synthesized uevent (where DM_UDEV_PRIMARY_SOURCE_FLAG is *not set*), we make use of the new IMPORT{db} udev rule and we try to reuse the existing information from udev database that was stored before while processing the original uevent.

(...but udevadm trigger can be run anytime later - there's no restriction in using it)

This is a solution we came up with after a few discussions with upstream udev - they provided us the IMPORT{db} udev rule and they also acknowledged the change in udev init script...

So actually there are dependencies:

  - we need recent udev version with IMPORT{db} udev rule support (that should be udev v152)
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=5539f624e18e948e4e3a1f0d9f5d25de9c8fd8b8

  - we require the udev database to be kept even from initrd stage and this is about a change in udev init script. Unfortunately, each distro has its own so we can't make it "udev upstream" change. For example, Fedora udev init script removed the udev database from initrd - that had to be changed. We just need to pass over the database from initrd to normal root fs when it's activated and usable.

IF udev is not used in initrd (but most distros use that now), the udev init script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise, device-mapper devices can't react on ADD event properly without using that IMPORT{db} and udev database magic described above (and ADD event is used at boot with that udevadm trigger in udev's init script!).

Note: udev's "udevadm trigger" has changed recently too. It genereated ADD events before, but it's generating CHANGE events now - that's also a change triggered by our discussion with udev team :) But still, "udevadm trigger --action=ADD" is used at boot because of some problems with network interfaces. This is a really painful change - it needed compromises on both sides - udev and device-mapper... Udev did some assumptions here about device activation, not taking into account all possibilities and we have a kind of different activation scheme :) But finally, this should work now with all these changes we did.

If you have any further questions, please, feel free to ask. This is somehow painful change, but it needs to be done once... Maybe Gentoo's udev maintainer should be CCed here as well.

(Hmm, I should write a doc about these things and put it in upstream's doc dir - some form of QA/HOWTO...)
Comment 9 Peter Rajnoha 2010-08-04 07:19:34 UTC
(In reply to comment #8)
> IF udev is not used in initrd (but most distros use that now), the udev init
> script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise,
> device-mapper devices can't react on ADD event properly without using that
> IMPORT{db} and udev database magic described above (and ADD event is used at
> boot with that udevadm trigger in udev's init script!).

...we used another trick for this before - detecting the use of ENV{STARTUP} environment variable that could be set with that initial "udevadm trigger". But that was deprecated after a discussion with udev team. The solution was not complete nevertheless...

We came up with this IMPORT{db} udev rule + keep the udev database solution instead.
Comment 10 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2010-08-04 07:47:53 UTC
udev-bugs team: please read comments 7-10.

(In reply to comment #8)
> (In reply to comment #6)
> > 1. Just wondering, why isn't 12-dm-permissions.rules listed in the Makefile.in
...
> I think this was the only reason we didn't do that at first. Instead, we gave
> each distro the freedom to choose the right action here (as Alasdair pointed
> out in previous comment, in Fedora, we put that simply in the "doc" for the
> user so he can manually use that if needed and do his own editings).
The package just needs to install to the DESTDIR location, and we as the distro handle merging. If it hasn't changed since the last version, our config management tools will take the default of ignoring it. If it has changed, user is presented with replace/discard/merge choices.

Just install to DESTDIR, and let the package manager handle the fact that the config file might already exist.

> > 2. See the users's comment about DM_UDEV_PRIMARY_SOURCE_FLAG not being set.
> > 
> 
> The DM_UDEV_PRIMARY_SOURCE_FLAG is something we've introduced recently to
> support all the synthesized uevents such as those that are generated while
> running "udevadm trigger" or "echo add/change > /sys/block/dm-X/uevent".
Yes, agk and I discussed it (and DM_COOKIE) in person during FOSDEM.

> Furthermore, in normal operation, the DM_UDEV_PRIMARY_SOURCE_FLAG is always set
> when the source of the uevent is the action triggered by libdevmapper (and so
> the LVM which uses it).
It does NOT appear to be set for this user, so we need to figure out why.

>   - we need recent udev version with IMPORT{db} udev rule support (that should
> be udev v152)
jharvell: what version of udev on your system?

>   - we require the udev database to be kept even from initrd stage and this is
> about a change in udev init script. Unfortunately, each distro has its own so
> we can't make it "udev upstream" change. For example, Fedora udev init script
> removed the udev database from initrd - that had to be changed. We just need to
> pass over the database from initrd to normal root fs when it's activated and
> usable.
We cannot guarantee any of the following in Gentoo:
- that an initrd was used
- what tool generated the initrd if any
- that the initrd if any contained udev (our stock tool, genkernel actually uses busybox mdev)

> IF udev is not used in initrd (but most distros use that now), the udev init
> script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise,
> device-mapper devices can't react on ADD event properly without using that
> IMPORT{db} and udev database magic described above (and ADD event is used at
> boot with that udevadm trigger in udev's init script!).
So we should probably add this to our udev init script?

> If you have any further questions, please, feel free to ask. This is somehow
> painful change, but it needs to be done once... Maybe Gentoo's udev maintainer
> should be CCed here as well.
Done, but we need to make sure any changes don't break Gentoo users with older udev. We give them a lot more rope to hang themselves than Redhat/Fedora.
Comment 11 Peter Rajnoha 2010-08-04 09:23:02 UTC
(In reply to comment #10)
> > IF udev is not used in initrd (but most distros use that now), the udev init
> > script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise,
> > device-mapper devices can't react on ADD event properly without using that
> > IMPORT{db} and udev database magic described above (and ADD event is used at
> > boot with that udevadm trigger in udev's init script!).
> So we should probably add this to our udev init script?

...maybe we could narrow it down to dm devices only then:

  udevadm trigger --sysname-match=dm-*

or

  udevadm trigger --attr-match=dm/name
Comment 12 Peter Rajnoha 2010-08-04 09:24:15 UTC
(In reply to comment #11)
>   udevadm trigger --sysname-match=dm-*
> 
> or
> 
>   udevadm trigger --attr-match=dm/name

"udevadm trigger --action=change ..." I mean.
Comment 13 Peter Rajnoha 2010-08-04 09:29:05 UTC
(In reply to comment #0)
> Additionaly, I see the following in /var/log/rc.log:
> 
>  * Setting up the Logical Volume Manager ...
> [snip]
>   The link /dev/firenza/idb_ts0 should had been created by udev but it was not
> found. Falling back to direct link creation.
> [snip]

Just to make sure, can you, please, attach the output of "udevadm monitor --kernel --property" while calling "vgchange --refresh <vg_name>". Thanks.
Comment 14 Joe Harvell 2010-08-04 16:48:35 UTC
(In reply to comment #10)
> jharvell: what version of udev on your system?

The version info is in Comment #3.
Comment 15 Joe Harvell 2010-08-04 17:01:55 UTC
Created attachment 241419 [details]
output of udevadm monitor as requested by Comment #13

output from 'udevadm monitor --kernel --property' while executing 'vgchange --refresh firenza' just after boot
Comment 16 Joe Harvell 2010-08-04 17:09:11 UTC
Created attachment 241421 [details]
bziped debug output of udev while executing command requested in Comment #13
Comment 17 Joe Harvell 2010-08-04 17:18:08 UTC
(In reply to comment #8)
> (In reply to comment #6)
> IF udev is not used in initrd (but most distros use that now), the udev init
> script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise,
> device-mapper devices can't react on ADD event properly without using that
> IMPORT{db} and udev database magic described above (and ADD event is used at
> boot with that udevadm trigger in udev's init script!).

Hopefully lvm2's udev rules will not make it difficult or impossible for Gentoo's init scripts to support a non udev initrd.  I plan on keeping my custom (non-udev) initrd if I can.
Comment 18 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2010-08-04 19:20:31 UTC
(In reply to comment #14)
> (In reply to comment #10)
> > jharvell: what version of udev on your system?
> The version info is in Comment #3.
Sorry, missed it while searching. udev-160 so there really shouldn't be any problem.

Can you please try this one-line change and see if it handles Peter's udevadm request suitably for Gentoo?

--- /lib64/rcscripts/addons/dm-start.sh.orig	2010-08-04 12:17:31.000000000 -0700
+++ /lib64/rcscripts/addons/dm-start.sh	2010-08-04 12:19:01.000000000 -0700
@@ -59,6 +59,8 @@
 
 local x volume
 
+udevadm trigger --attr-match=dm/name
+
 if [ -x /sbin/dmsetup -a -c /dev/mapper/control -a -f /etc/dmtab ] ; then
 	[ -n "$(get_new_dm_volumes)" ] && \
 		einfo " Setting up device-mapper volumes:"
Comment 19 Peter Rajnoha 2010-08-05 13:50:36 UTC
(In reply to comment #15)
> output from 'udevadm monitor --kernel --property' while executing 'vgchange
> --refresh firenza' just after boot

Well, looking at the logs, all DM devices have DM_UDEV_PRIMARY_SOURCE_FLAG encoded in DM_COOKIE variable while being resumed. So now I'm wondering why there appears:

 * Setting up the Logical Volume Manager ...
 [snip]
   The link /dev/firenza/idb_ts0 should had been created by udev but it was not
 found. Falling back to direct link creation.
 [snip]

..at boot. If the uevent is primary sourced, the rules should be evaluated normally and all the symlinks should be created by udev without any problem. Hmm. I suppose you don't see these messages about fallback action when running the vgchange --refresh later. There shouldn't be any difference.

Anyway, if the "firenza" vg is activated in the initrd, any "vgchange -ay" shouldn't try to recreate the dev nodes/symlinks and it should not generate any uevents since the LVs in that VG are activated already. So I'm confused a little about it...
Comment 20 Peter Rajnoha 2010-08-05 14:06:50 UTC
(In reply to comment #17)
> Hopefully lvm2's udev rules will not make it difficult or impossible for
> Gentoo's init scripts to support a non udev initrd.  I plan on keeping my
> custom (non-udev) initrd if I can.

You can have a system without udev-enabled initrd, but you have to make an extra care of that one udevadm trigger call to be present:

  udevadm trigger --action=change --attr-match=dm/name

That should be all - so all the symlinks/nodes for dm devices activated in the initrd are recreated in /dev/.

The rules try to mimic the functionality of the udev flags we set. BUT not completetely for certain reasons (the flags are set dynamically based on the state of the device while being processed in userspace libdevmapper/LVM/any other subsystem and I just can't do that decision sometimes based only on what I can get in pure uevent, neither is this information easily exportable on demand from within udev rules by calling some utility to get the info).

So the drawback is that you could, for example, end up with *_mimage symlinks to be created in /dev/<vgname> or a snapshot cow device being touched by other udev rules, scanning it (like blkid) and things like that. All this udev flagging was done to minimise any errors/problems and to miminise useless accesses to inappropriate devices. So it's always better if we can fully rely on those udev flags directly set in libdevmapper and passed through the kernel back to udev rules when processing the uevent.

If you have initrd without udev and activate a few dm devices there (e.g. a device where root fs is only) then the risk of problems is low.

So yes, sure, you can have a system without udev-enabled initrd, but there are some drawbacks when combining it with udev-enabled system later...
Comment 21 Peter Rajnoha 2010-08-05 14:14:21 UTC
(In reply to comment #19)
>  found. Falling back to direct link creation.
>  [snip]
> 
...
> Anyway, if the "firenza" vg is activated in the initrd, any "vgchange -ay"

I mean, any "vgchange -ay" run later on the same VG as run in the initrd before.
Comment 22 Joe Harvell 2010-08-05 19:08:38 UTC
(In reply to comment #19)
> (In reply to comment #15)
> > output from 'udevadm monitor --kernel --property' while executing 'vgchange
> > --refresh firenza' just after boot
> 
> Well, looking at the logs, all DM devices have DM_UDEV_PRIMARY_SOURCE_FLAG
> encoded in DM_COOKIE variable while being resumed. So now I'm wondering why
> there appears:
> 
>  * Setting up the Logical Volume Manager ...
>  [snip]
>    The link /dev/firenza/idb_ts0 should had been created by udev but it was not
>  found. Falling back to direct link creation.
>  [snip]
> 
> ..at boot. If the uevent is primary sourced, the rules should be evaluated
> normally and all the symlinks should be created by udev without any problem.
> Hmm. I suppose you don't see these messages about fallback action when running
> the vgchange --refresh later. There shouldn't be any difference.
> 

You should look at attachment #1 [details] and attachment #2 [details].  It has full debug of udev at system boot.
Comment 23 Joe Harvell 2010-08-06 03:11:00 UTC
(In reply to comment #18)
> (In reply to comment #14)
> > (In reply to comment #10)
> > > jharvell: what version of udev on your system?
> > The version info is in Comment #3.
> Sorry, missed it while searching. udev-160 so there really shouldn't be any
> problem.
> 
> Can you please try this one-line change and see if it handles Peter's udevadm
> request suitably for Gentoo?
Shouldn't this also have the --change option?
> 
> --- /lib64/rcscripts/addons/dm-start.sh.orig    2010-08-04 12:17:31.000000000
> -0700
> +++ /lib64/rcscripts/addons/dm-start.sh 2010-08-04 12:19:01.000000000 -0700
> @@ -59,6 +59,8 @@
> 
>  local x volume
> 
> +udevadm trigger --attr-match=dm/name
> +
>  if [ -x /sbin/dmsetup -a -c /dev/mapper/control -a -f /etc/dmtab ] ; then
>         [ -n "$(get_new_dm_volumes)" ] && \
>                 einfo " Setting up device-mapper volumes:"
> 

Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2010-08-06 09:01:17 UTC
(In reply to comment #23)
> Shouldn't this also have the --change option?
Oops, yes. please add that to test.
Comment 25 Peter Rajnoha 2010-08-06 09:30:49 UTC
(In reply to comment #24)
> (In reply to comment #23)
> > Shouldn't this also have the --change option?
> Oops, yes. please add that to test.
> 

Also add the DM_UDEV_PRIMARY_SOURCE_FLAG there, please (we need to get this one into udev db), so finally it should be:

  udevadm control --property=DM_UDEV_PRIMARY_SOURCE_FLAG=1
  udevadm trigger --action=change --attr-match=dm/name
  udevadm control --property=DM_UDEV_PRIMARY_SOURCE_FLAG=

(We need to mimic that flag like it was original event! I forgot to mention this one, sorry. This is needed, so any furhter synthesized event, like that one originating in the use of the "watch" rule can be handled correctly as well... Hmm, I'll probably add a comment in the rules directly about this. It's quite important for non-udev initrds.)
Comment 26 Peter Rajnoha 2010-08-06 09:50:26 UTC
(In reply to comment #22)
> (In reply to comment #19)
> > (In reply to comment #15)
> >  * Setting up the Logical Volume Manager ...
> >  [snip]
> >    The link /dev/firenza/idb_ts0 should had been created by udev but it was not
> >  found. Falling back to direct link creation.
> >  [snip]
> > 
> > ..at boot. If the uevent is primary sourced, the rules should be evaluated
> > normally and all the symlinks should be created by udev without any problem.
> > Hmm. I suppose you don't see these messages about fallback action when running
> > the vgchange --refresh later. There shouldn't be any difference.
> > 
> 
> You should look at attachment #1 [details] and attachment #2 [details].  It has full debug of udev
> at system boot.
> 

Well, what I mean exactly is the sequence:

1) "vgchange -a y firenza" called in initrd - activates the firenza VG there

2) pivot root

3) start udevd (including the initial "udevadm trigger" to repopulate the /dev and udev databse)

4) calling *another* "vgchange -a y" (that's the "Setting up the Logical Volume Manager ..." in the log, I presume).

And that 4) is what makes me wondering - how it's possible that the error message is issued:

"The link /dev/firenza/idb_ts0 should had been created by udev but it was not
found. Falling back to direct link creation."

Because running "vgchange -a y" on *already activated VG* should not try to handle any nodes/symlinks anymore, since they were already created before (and the VG here should be activated in initrd). So that's strange...
Comment 27 Peter Rajnoha 2010-08-06 10:03:54 UTC
(In reply to comment #25)
>   udevadm control --property=DM_UDEV_PRIMARY_SOURCE_FLAG=1

..oh, it seems that properties defined this way are not stored in udev db(?) :( OK, I think I need to consult this with Kay then... (so as you can see, the topic is very lively still :) I'm sorry for the inconvenience.)
Comment 28 Joe Harvell 2010-08-06 12:36:25 UTC
(In reply to comment #26)
> (In reply to comment #22)
> > (In reply to comment #19)
> > > (In reply to comment #15)
> > >  * Setting up the Logical Volume Manager ...
> > >  [snip]
> > >    The link /dev/firenza/idb_ts0 should had been created by udev but it was not
> > >  found. Falling back to direct link creation.
> > >  [snip]
> > > 
It's because the dev being populated in the initrd is the initramfs. The switch_root switches to the /dev created by the gentoo stage3 during initial install.
> > > ..at boot. If the uevent is primary sourced, the rules should be evaluated
> > > normally and all the symlinks should be created by udev without any problem.
> > > Hmm. I suppose you don't see these messages about fallback action when running
> > > the vgchange --refresh later. There shouldn't be any difference.
> > > 
> > 
> > You should look at attachment #1 [details] [details] and attachment #2 [details] [details].  It has full debug of udev
> > at system boot.
> > 
> 
> Well, what I mean exactly is the sequence:
> 
> 1) "vgchange -a y firenza" called in initrd - activates the firenza VG there
> 
> 2) pivot root
> 
> 3) start udevd (including the initial "udevadm trigger" to repopulate the /dev
> and udev databse)
> 
> 4) calling *another* "vgchange -a y" (that's the "Setting up the Logical Volume
> Manager ..." in the log, I presume).
> 
> And that 4) is what makes me wondering - how it's possible that the error
> message is issued:
> 
> "The link /dev/firenza/idb_ts0 should had been created by udev but it was not
> found. Falling back to direct link creation."
> 
> Because running "vgchange -a y" on *already activated VG* should not try to
> handle any nodes/symlinks anymore, since they were already created before (and
> the VG here should be activated in initrd). So that's strange...
> 

Comment 29 Joe Harvell 2010-08-06 18:42:36 UTC
(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #22)
> > > (In reply to comment #19)
> > > > (In reply to comment #15)

> > Because running "vgchange -a y" on *already activated VG* should not try to
> > handle any nodes/symlinks anymore, since they were already created before (and
> > the VG here should be activated in initrd). So that's strange...
> > 
> 

Sorry.  Posted from my mobile....My reply was embedded in the middle of what I had copied from the original comment.  Here is it below:

It's because the dev being populated in the initrd is the initramfs. The
switch_root switches to the /dev created by the gentoo stage3 during initial
install.
Comment 30 Matthias Schwarzott gentoo-dev 2010-08-07 16:19:30 UTC
(In reply to comment #27)
> (In reply to comment #25)
> >   udevadm control --property=DM_UDEV_PRIMARY_SOURCE_FLAG=1
> 
> ..oh, it seems that properties defined this way are not stored in udev db(?) :(
> OK, I think I need to consult this with Kay then... (so as you can see, the
> topic is very lively still :) I'm sorry for the inconvenience.)
> 

That can be solved by some two-stage approach:
udev-init-script running
udevadm control --property=UDEV_POPULATE_TRIGGER=1
udevadm trigger --action=add
[...]
udevadm settle
udevadm control --property=UDEV_POPULATE_TRIGGER=

And in lvm2 udev rules use the following rule to catch udev trigger cases where udev database is not yet filled correctly (by using non-udev initrd or udev init-script not copying over initrd udevdb):

ACTION=="add", ENV{UDEV_POPULATE_TRIGGER}=="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", ...

Here action can be either setting DM_UDEV_PRIMARY_SOURCE_FLAG=1 (and this way adding it to udevdb) or anything else needed to fill udevdb.
Comment 31 Peter Rajnoha 2010-08-09 07:46:54 UTC
(In reply to comment #29)
> It's because the dev being populated in the initrd is the initramfs. The
> switch_root switches to the /dev created by the gentoo stage3 during initial
> install.

Still, no matter if these "/dev"s are same or not, no matter what the content is, once the VG/LV is activated, the symlinks/nodes are not touched after that - try removing or editing the /dev/<vgname> content for already activated VG/LV and then try calling "vgchange -a y <vgname>" again and nothing will get corrected (you would need to call "vgchange --refresh <vgname>" to do that).

Anyway, can you post the verbose output (-vvvv) of the command that triggered the error message "Falling back to direct link creation" to appear (the rc init's vgchange). We should see directly what's happening there... Thanks.
Comment 32 Peter Rajnoha 2010-08-09 07:56:49 UTC
(In reply to comment #30)
> That can be solved by some two-stage approach:
> udev-init-script running
> udevadm control --property=UDEV_POPULATE_TRIGGER=1
> udevadm trigger --action=add
> [...]
> udevadm settle
> udevadm control --property=UDEV_POPULATE_TRIGGER=
> 
> And in lvm2 udev rules use the following rule to catch udev trigger cases where
> udev database is not yet filled correctly (by using non-udev initrd or udev
> init-script not copying over initrd udevdb):
> 
> ACTION=="add", ENV{UDEV_POPULATE_TRIGGER}=="1",
> ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", ...
> 
> Here action can be either setting DM_UDEV_PRIMARY_SOURCE_FLAG=1 (and this way
> adding it to udevdb) or anything else needed to fill udevdb.

Yes, exactly - actually, this was the appropach we used before (we just used another name for the ENV var - ENV{STARTUP}). But, unfortunately, this solution was rejected by upstream udev - we had to remove that.

I checked the rules once again and I think we can manage even without that DM_UDEV_PRIMARY_SOURCE_FLAG=1 in the udev db if we can accept the drawback that nobody should run "udevadm trigger --action=add" or "echo ADD > /sys/block/dm-X/uevent" (so without that flag set in udev db, we can't support any following synthesized ADD events). The CHANGE events (even synthesized) should work though.

With that flag in udev db, we have full support for any synthesized events... It's very hard to design rules that will cover all situations and combinations - the one with having udev in initrd and just copying the udev db from there is the most straightforward one. But I understand the need for non-udev initrd as well. It's hard to decide what the best solution is here - making two versions of the rules - one for each case - is not the way to go, I think...
Comment 33 Peter Rajnoha 2010-08-09 07:58:38 UTC
(In reply to comment #32)
> Yes, exactly - actually, this was the appropach we used before (we just used
> another name for the ENV var - ENV{STARTUP}). But, unfortunately, this solution
> was rejected by upstream udev - we had to remove that.

The argument was that there's nothing like "STARTUP" or "INIT" in udev - all events should be handled the same way - whether it is in the middle of system running or booting...
Comment 34 Peter Rajnoha 2010-08-20 12:07:04 UTC
(In reply to comment #0)
> Additionaly, I see the following in /var/log/rc.log:
> 
>  * Setting up the Logical Volume Manager ...
> [snip]
>   The link /dev/firenza/idb_ts0 should had been created by udev but it was not
> found. Falling back to direct link creation.
> [snip]

Well, recently, I've run into a very similar situation reported in Debian:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593625

Sorry, I didn't notice that "vgscan --mknodes" is also used in Gentoo's lvm init script first - I thought you use only plain vgchange without issuing any additional commands. So that explains everything then. See also my comment's in that Debian's bug...
Comment 35 Peter Rajnoha 2010-08-20 12:32:31 UTC
(Maybe we could try to detect that udev is running and provide "udevadm trigger --action=change --attr-match=dm/name" functionality directly within the implementation of lvm's "--mknodes" switch. And if udev is not running, just fallback to the old way.)
Comment 36 parafin 2010-08-20 12:48:54 UTC
No, it should be fixed outside of lvm2, because it's not the only one who uses device-mapper.
I decrypt some partitions with cryptsetup in my initramfs and need them available during boot. I do not use lvm2, but ran into this bug too.
For now I added "udevadm trigger --action=change --attr-match=dm/name" to run after udev init script finishes, it fixed the problem. Probably this command should be included in udev or device-mapper init script.
Comment 37 Peter Rajnoha 2010-08-20 13:15:39 UTC
(In reply to comment #36)
> No, it should be fixed outside of lvm2, because it's not the only one who uses
> device-mapper.

I thought about making it part of libdevmapper, something like "dm_udev_mknodes". This would just be the same as udevadm trigger (basically writing "change" into the /sys/block/dm-X/uevent. And do that for all existing dm-x there (with the "udev settle" functionality included as well probably).

That would be triggered only if udev is running and libdevmapper was compiled with udev support.

Or maybe hide include this functionality somewhere in existing code for managing nodes.

A good thing is that once run, all the device-mapper associated rules would be evaluated - no matter what the subsystem is (if there's any specific subsystem rule, it would be evaluated as well). This was not quite possible in early versions of libdevmapper with udev, but now with the support for synthesized events, it's worth trying.

But these are just my thoughts how to make life easier for any libdevmapper users. I'll try to explore what the possibilities are...

> I decrypt some partitions with cryptsetup in my initramfs and need them
> available during boot. I do not use lvm2, but ran into this bug too.
> For now I added "udevadm trigger --action=change --attr-match=dm/name" to run
> after udev init script finishes, it fixed the problem. Probably this command
> should be included in udev or device-mapper init script.
> 

Yes, it's an alternative. But the thing is that each distro manages its own initrd and system init scheme. We've solved that in Fedora but now people in other distros run into similar problems (we had to solve as well :)) because of these little differences that need fixing/updating. Keeping that responsibility in upstream as much as possible would be fine to avoid such annoying bugs to appear.

But as I said before, I need to explore what the possibilites are here...
Comment 38 Paolo Pedroni 2010-08-25 08:51:33 UTC
(In reply to comment #18)
> (In reply to comment #14)
> > (In reply to comment #10)
> > > jharvell: what version of udev on your system?
> > The version info is in Comment #3.
> Sorry, missed it while searching. udev-160 so there really shouldn't be any
> problem.
> 
> Can you please try this one-line change and see if it handles Peter's udevadm
> request suitably for Gentoo?
> 
> --- /lib64/rcscripts/addons/dm-start.sh.orig    2010-08-04 12:17:31.000000000
> -0700
> +++ /lib64/rcscripts/addons/dm-start.sh 2010-08-04 12:19:01.000000000 -0700
> @@ -59,6 +59,8 @@
> 
>  local x volume
> 
> +udevadm trigger --attr-match=dm/name
> +
>  if [ -x /sbin/dmsetup -a -c /dev/mapper/control -a -f /etc/dmtab ] ; then
>         [ -n "$(get_new_dm_volumes)" ] && \
>                 einfo " Setting up device-mapper volumes:"
> 

I have a similar problem (dmraid instead of lvm2, but symptoms were the same) and this (with --action=change, as for comment #24) solves it.

Thanks a lot.
Comment 39 Xake 2011-01-19 22:39:21 UTC
I have symptoms (mostly cosmetic) of this and I am trying to figure out what you are trying to communicate here as a solution.

Adding "udevadm trigger --action=change" to the /etc/init.d/udev script or dm-start.sh does not seem to help.

My current workaround is to hand-edit genkernel to use devtmpfs instead of mdev, I guess that creates a situation alike using udev in initramfs.

So is there a consensus on what needs to be done coming up here?
Comment 40 Patrick Michaelis 2011-01-26 18:40:03 UTC
I recently encountered the same issue while trying to set up lvm with systemd. I also have an inird (without udev) that activated a VG to mount one of the LVs as root. I used "vgscan --mknodes" and "vgchange -ay" upon boot up, like in the native gentoo lvm_start.sh script, but came into trouble, as systemd couldn't monitor the devices correctly, as they weren't created by udev, but rather through the fallback method of "vgscan --mknodes".

I then found this bug report and tried the "udevadm trigger --action=change --attr-match=dm/name" approach, which indeed created the device nodes. However, as I only noted because I needed the systemd specific rules for udev to be applied, that this does not apply the udev rules the same way, as it would if you really would activate a deactivated VG.

While trying to work around this, this got me thinking: Why calling vgscan /  vgchange twice at all? In fact, as my inird already activated the VG, I only needed to re-create the nodes and re-apply the udev-rules, not actually activate the LV again. So I thought, there should be some way to do this with the LVM tools, rather than triggering synthesised udev events.

I found out, that "vgmknodes --refresh" does exactly what I wanted. I first assumed, it would do only what "vgscan --mknodes" does if udev node creation failes, but actually with the "--refresh" paremeter, the metadata is re-read, and udev is called to apply all rules (including the one's creating the nodes).

I don't know if this is the right approach for a gentoo init script, but this seems a lot less hacky to me than calling vgscan/vgchange a second time, even if vgs are already scanned, and even if that is not to actually activate a VG, rather re-read the data, and then also trigger an udev event manually, because it doesn't do what we want here.

So if mine is a sane approach (I do not know what other issues are involved with udev and other dm-devices), it would maybe a good way to do something like either just call:

vgmknodes --refreash

instead of dmadm trigger ...

Or even better would be to check if any vg has already been activated, call "vgmknodes --refresh" on that, then check for other not activated VGs, and call "vgchange -a ly" on them. This would cover the case: no initrd (no vgmknodes but vgchange in all), all activated by an inird (only vgmknodes, no vgchange), or a mixture of both (initrd activated one VG, but not all of them for example). 

(I haven't tested how this behaves, if you use an inird with udev, though.)


 
Comment 41 Leho Kraav (:macmaN @lkraav) 2011-05-03 17:36:24 UTC
right so bumped into this as well building dracut initramfs. aidecoe took a look at this bug but said the "udevadm trigger" fix didnt do anything for him. what about the rest of you guys CC:d here, has anyone come up with something lately?
Comment 42 Xake 2011-05-03 19:04:14 UTC
(In reply to comment #41)
> right so bumped into this as well building dracut initramfs. aidecoe took a
> look at this bug but said the "udevadm trigger" fix didnt do anything for him.
> what about the rest of you guys CC:d here, has anyone come up with something
> lately?

udevadm trigger with --action=add or action=change?
Different versions of udev has different defaults, and having udevadm trigger --action=change instead for --action=add at the right place in /etc/init.d/udev fixed loads of problems wrt lvm and device-mapper for me...
Comment 43 Samuli Suominen (RETIRED) gentoo-dev 2013-04-15 14:40:04 UTC
Is this bug relavent anymore with every version of udev in Portage, including stable, using /dev with the DEVTMPFS filesystem?
Comment 44 Matija "hook" Šuklje 2013-04-16 09:42:11 UTC
(In reply to comment #43)
> Is this bug relavent anymore with every version of udev in Portage,
> including stable, using /dev with the DEVTMPFS filesystem?

I just updgraded udev to 200 and removed the /dev entry from /etc/fstab and the bug still replicates.
Comment 45 Paolo Pedroni 2013-04-17 07:32:23 UTC
(In reply to comment #43)
> Is this bug relavent anymore with every version of udev in Portage,
> including stable, using /dev with the DEVTMPFS filesystem?

I will check as soon as I'm able to pass some time with that PC at home (it may take a few days, though).
Comment 46 Joe Harvell 2013-04-17 16:43:30 UTC

 * Setting up the Logical Volume Manager ...
  The link /dev/rouen/root should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/var_log should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/var_tmp should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/home should had been created by udev but it was not found. Falling back to direct link creation.
(In reply to comment #43)
> Is this bug relavent anymore with every version of udev in Portage,
> including stable, using /dev with the DEVTMPFS filesystem?

If you're asking if this problem still exists, then yes it does.  I abandoned original work around of commenting out the rule in /lib64/udev/rules.d/10-dm.rules because it would frequently be overwritten by udev updates.  I now just live with / work around the problem.  Here are logs from /var/log/rc.log from April 10th 2013:

 * Setting up the Logical Volume Manager ...
  The link /dev/rouen/root should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/var_log should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/var_tmp should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/rouen/home should had been created by udev but it was not found. Falling back to direct link creation.
Comment 47 Paolo Pedroni 2013-04-17 16:45:15 UTC
(In reply to comment #43)
> Is this bug relavent anymore with every version of udev in Portage,
> including stable, using /dev with the DEVTMPFS filesystem?

I checked on my system, removing 'udevadm trigger --action=change --attr-match=dm/name' from /etc/init.d/device-mapper, and the system now works fine. I guess this means that this bug is no longer valid (at least in my case).

I have:

CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y

in my kernel configuration.
Comment 48 Joe Harvell 2013-04-17 20:42:15 UTC
(In reply to comment #43)
> Is this bug relavent anymore with every version of udev in Portage,
> including stable, using /dev with the DEVTMPFS filesystem?

I don't quite follow.  Sounds like you're saying I have some requirements on my kernel configuraition or custom initrd behavior to avoid this problem.  Could you clarify what they are?
Comment 49 Samuli Suominen (RETIRED) gentoo-dev 2013-04-18 02:01:29 UTC
(In reply to comment #47)
> (In reply to comment #43)
> > Is this bug relavent anymore with every version of udev in Portage,
> > including stable, using /dev with the DEVTMPFS filesystem?
> 
> I checked on my system, removing 'udevadm trigger --action=change
> --attr-match=dm/name' from /etc/init.d/device-mapper, and the system now
> works fine. I guess this means that this bug is no longer valid (at least in
> my case).
> 
> I have:
> 
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> 
> in my kernel configuration.

Let me get verification for a half-guess I can't shake. Glad to hear it's working for you now.
I suppose you have never modified rc_coldplug= value in /etc/udev/rules.d/ ?
Have any of you with the problem still existing set it to NO? If so, does setting it to YES and booting make a difference?
Comment 50 Samuli Suominen (RETIRED) gentoo-dev 2013-04-18 02:02:22 UTC
(In reply to comment #49)
> I suppose you have never modified rc_coldplug= value in /etc/udev/rules.d/ ?

Typing error! Sorry. *I meant in /etc/conf.d/udev
Comment 51 Paolo Pedroni 2013-04-18 08:26:04 UTC
(In reply to comment #49)
> Let me get verification for a half-guess I can't shake. Glad to hear it's
> working for you now.
> I suppose you have never modified rc_coldplug= value in /etc/conf.d/udev ?

Never changed it. It's still commented out (it should default to yes, AFAIK).
Comment 52 Samuli Suominen (RETIRED) gentoo-dev 2013-08-02 05:48:36 UTC
(In reply to Joe Harvell from comment #17)
> (In reply to comment #8)
> > (In reply to comment #6)
> > IF udev is not used in initrd (but most distros use that now), the udev init
> > script *HAS TO CALL* an extra "udevadm trigger --action=change". Otherwise,
> > device-mapper devices can't react on ADD event properly without using that
> > IMPORT{db} and udev database magic described above (and ADD event is used at
> > boot with that udevadm trigger in udev's init script!).
> 
> Hopefully lvm2's udev rules will not make it difficult or impossible for
> Gentoo's init scripts to support a non udev initrd.  I plan on keeping my
> custom (non-udev) initrd if I can.

You can't. There is work in progress to make genkernel use udev as well. Otherwise /dev doesn't populate correctly with cryptsetup/lvm2.
As in, udev is mandatory in the initramfs.
Comment 53 Samuli Suominen (RETIRED) gentoo-dev 2013-08-02 05:57:53 UTC
Use at least >=virtual/udev-200. Make sure CONFIG_DEVTMPFS=y is enabled in kernel.

Use at least sys-fs/lvm2-2.02.97-r1, preferably 2.02.99.

If you use initramfs, make sure it's udev based. Like one generated with sys-kernel/dracut because sys-kernel/genkernel is broken and can't work since it uses mdev instead of udev.

(In reply to Joe Harvell from comment #46)
> If you're asking if this problem still exists, then yes it does.  I
> abandoned original work around of commenting out the rule in
> /lib64/udev/rules.d/10-dm.rules because it would frequently be overwritten
> by udev updates.

You copy 10-dm.rules to /etc/udev/rules.d/ and modify them there, instead of modifying anything directly in /lib/udev/rules.d/


Otherwise I'm lost. This is working for me. What exactly there is to do here?
Comment 54 Fabio Erculiani (RETIRED) gentoo-dev 2013-08-02 06:10:25 UTC
Or switch to genkernel-next, which I plan to maintain, clean up and improve