[arch-projects] Fwd: Re: [RFC3][PATCH] [mkinitcpio] Cleanly stop udev >= 168 as recommended by upstream.

Dave Reisner 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.
> 
> dave
> 

----- End forwarded message -----

And i replied to Gerardo by mistake instead of the list...

d


More information about the arch-projects mailing list