From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Hubbs Date: Tue, 06 Dec 2011 22:10:13 +0000 Subject: Re: advice needed for gentoo bug involving lvm2/udev Message-Id: <20111206221013.GA19750@linux1> MIME-Version: 1 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" List-Id: References: <20111003164149.GA13439@linux1> In-Reply-To: <20111003164149.GA13439@linux1> To: linux-hotplug@vger.kernel.org --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 04, 2011 at 03:09:34AM +0200, Kay Sievers wrote: > On Mon, Oct 3, 2011 at 18:41, William Hubbs wrote: > > we have the following bug posted in gentoo's bugzilla: > > > > http://bugs.gentoo.org/show_bug.cgi?id=3D365227. > > > > The reporter is telling me that we should use --action=3Dchange instead= of > > --action=3Dadd in the cold boot sequence when dev is devtmpfs. However, > > this doesn't seem to be the correct fix based on earlier discussions on > > this list. > > > > Does anyone else have any suggestions for fixing this? My thought is > > that the rules for lvm2 should be fixed. What does everyone else think? >=20 > --action=3Dadd is still the recommended and default way of doing coldplug. >=20 > It should only be done once after udevd is started though, and never > again. All later triggers should be change only. The reporter is now saying that --action=3Dadd does not touch nodes that are already in the file system, so, for example, if you mount devtmpfs on /dev then call udevadm trigger --action=3Dadd, the permissions, ownership, etc, of nodes that already exist are not touched. So, he is suggesting that we add another udevadm trigger call with --action=3Dchange to the cold boot sequence. Is this a bug in udev, or should we add this extra udevadm trigger call? William --zhXaljGHf11kAtnf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk7eksUACgkQblQW9DDEZTgUUQCfWaXu3CXHFUYiMopj3zcq2hC2 KtIAn24wyeh2k91YDvKq3hrJt7i/C01d =gOvP -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--