----- 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