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

2 May 2011

      ----- Forwarded message from Dave Reisner  -----
...
Date: Mon, 2 May 2011 12:09:54 -0400
From: Dave Reisner 
To: Gerardo Exequiel Pozzi 
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:
...
...
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
Am 02.05.2011 16:00, schrieb Gerardo Exequiel Pozzi:
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