r7874 - in trunk/bootscripts: . lfs/init.d
bryan at kadzban.is-a-geek.net
Sun Nov 26 05:48:10 PST 2006
Alexander E. Patrakov wrote:
> This is a bug in udev, and should be fixed there.
And I was trying to decide before this commit whether I should have
posted it to -dev and gotten comments, or just committed it. That's
what I get. ;-)
> This has already been discussed on linux-hotplug-devel, and he
> (according to your message, falsely) assures that his scripts work
> with both methods: retry-uevents (recommended) and copy-rules
Hmm. Well, I know it doesn't work with retry-uevents, because the
original uevent doesn't fail. When the rule_generator scripts write to
/dev/.udev instead of /etc/udev/rules.d, they don't exit with a failed
status. So there's nothing in the failed directory. And "udevtrigger
--retry-failed" won't rerun these events.
We could just rerun "udevtrigger" and wait for everything again, but
that's a *horrible* hack; much worse than what this does.
> I propose to drop installation of the persistent helpers until this
> (and the wish about serial-based CDROM persistence and path_id-based
> network card persistence) is properly fixed upstream.
Yes, it should be fixed upstream. (And I don't remember hearing about
issues, or claims that it works, before. But maybe I hadn't subscribed
yet, or maybe I'm just forgetful.) OTOH, if what we have works for the
moment, my first inclination is to just wait until they can get it fixed
upstream, and then yank out the workarounds we have in place.
But what's the reason behind your statement that we should drop this
until it works? IMO the workarounds aren't *that* bad (even if they are
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev