[arch-projects] Fwd: Re: [RFC3][PATCH] [mkinitcpio] Cleanly stop udev >= 168 as recommended by upstream.
d at falconindy.com
Mon May 2 12:28:54 EDT 2011
----- Forwarded message from Dave Reisner <d at falconindy.com> -----
> Date: Mon, 2 May 2011 12:09:54 -0400
> From: Dave Reisner <d at falconindy.com>
> To: Gerardo Exequiel Pozzi <vmlinuz386 at yahoo.com.ar>
> Subject: Re: [arch-projects] [RFC3][PATCH] [mkinitcpio] Cleanly stop udev >= 168 as
> recommended by upstream.
> On Mon, May 02, 2011 at 12:28:41PM -0300, Gerardo Exequiel Pozzi wrote:
> > On 05/02/2011 11:23 AM, Thomas Bächler wrote:
> > >Am 02.05.2011 16:00, schrieb Gerardo Exequiel Pozzi:
> > >>N0: device-mapper/LVM udev rules must be parsed for initramfs creation
> > >> to add OPTIONS+="db_persist"
> > >Patch looks good now.
> > Great!
> > >I am unsure and confused why we would need this db_persist option. In
> > >the past, we killed udev and the db completely and everything worked out
> > >fine. What kind of state would need to be persistent? Is upstream adding
> > >this option?
> We've never killed the DB on leaving early userspace because the DB
> previously lived in /dev/.udev. We did a mount --move of /dev to
> /new_root/dev and continued on our merry way. Nothing different with the
> DB in /run/udev. We transfer that tmpfs over to the root and everything
> is preserved.
> > Yes, that is what I not understand, If I am not wrong this was
> > before devtmpfs times.
> Not sure where devtmpfs comes into play. This is all created by udevd in
> userland regardless of the filesystem /dev is mounted on.
> > Maybe this is needed in case if rules on initramfs differs from real
> > root. Dave can you ask to Kay on IRC about this? (I am going to my
> > work now) Thanks.
> Seems to me like lvm2 is just a pain in the ass for udev all around. In
> systemd, it's the only reason that a call to udevadm settle is required
> during late bootup. Everything else can be handled as hotplug events as
> they come up.
> Snippets from Kay...
> 11:52 kay » falconindy: only if you use --db-cleanup, and yes lvm
> plays dirty tricks with udev and needs the db preserved
> 11:54 kay » falconindy: they need to catch up with 2011 a bit though
> and stop scanning /dev, or have crazy regexes in their
> config files
> 11:58 kay » falconindy: in the past we used to rm -rf /dev/.udev
> in the real root
> 11:59 falconindy » which i assume is a more of a sledgehammer approach
> to what the cleanup does
> 12:00 kay » falconindy: not that different, the db_persist just
> adds a sticky bit to the db file
> So LVM is just a pain in the butt all around. State can be wiped for all
> other devices and the rebuilt DB in later userspace doesn't contain
> failed/unhandled events from the initramfs.
----- End forwarded message -----
And i replied to Gerardo by mistake instead of the list...
More information about the arch-projects