Fwd: Re: film at 11: kernel update breaks udev.
dmc.fedora at filteredperception.org
Mon Jul 23 17:16:17 UTC 2007
Richard Hally wrote:
> Douglas McClendon wrote:
>> Bill Nottingham wrote:
>>> Richard Hughes (hughsient at gmail.com) said:
>>>> On Sat, 2007-07-21 at 00:55 -0400, Dave Jones wrote:
>>>>> Argh. So why _are_ we doing our own special rules instead
>>>>> of using the upstream ones ? This isn't the only time I've
>>>>> run into something like this with udev.
>>>> Our udev is about 100x times slower than upstream...
>>> I find it hard to believe it's 100x slower. I've done testing
>>> of it with most of the not-needed-for-booting rules commented out -
>>> execution time only dropped from ~5 to ~3.5 seconds.
>> This may be something unrelated (qemu bug?), but I feel I should mention-
>> When I boot livecds that I've spun with livecd-creator in qemu, the
>> udev step takes a painfully long time to complete, and even just hangs
>> a fair percentage of the time.
>> Has anyone else noticed anything like this? At some point I'll do a
>> little more research and file a proper bug.
> yes, on my rawhide box ( a P4 3.2Ghz with H/T) when booting I get to the
> "starting udev:" and it sits there for 2:44 (that is 2 minutes and 44
> then continues booting.
I'm glad I'm not the only one. The main reason, until this thread, that I
pegged it for a qemu bug was that I can hit the hang/2:44 scenario, ctrl-c, and
restart with the exact same commandline*, and then it will take a slow, but
reasonable (~15-30s) time to complete.
* I'm almost positive it has happened at times when I'm either only using cdrom,
or using -snapshot. Thus no changed state on the disk file could explain this.
Another reason I suspect qemu, is I see plenty of kernel messages relating to
problems with the cdrom drive spewing by, which are otherwise ignorable. I'm
assuming those have something to do with the new ata driver stuff in f7, and
that I should just wait a little while for other people to iron those things out.
But then, given the topic that started this thread, makes me wonder if tweaking
some udev rules wouldn't perhaps workaround this problem. Anybody have any
ideas for experiments - either with some debug/verbose setting or alternate rules?
More information about the devel