Cleaner solution for gdm+dkms upstart integration?
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| dkms (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: dkms
(Split off from https:/
http://
I’m a little worried that this has race conditions:
• If build-successful fires before the graphics device is ready, gdm startup may be triggered too early (is this a problem?).
• If build-successful fires between the time X fails to module and the time gdm finishes failing to start, the event will be lost entirely.
Maybe one way this could be solved is to leave gdm the way it was and add a dummy task to the nvidia and fglrx packages to block gdm from starting up before the module is available. This avoids any race conditions that involve trying to start the gdm job multiple times, and also seems more neatly modular:
start on starting gdm and (build-successful MODULE=nvidia or build-failed MODULE=nvidia)
task
exec /bin/true
(Given that use case, perhaps build-failed should not actually be a separate event? It might be nicer to emit events like
dkms-build MODULE=nvidia RESULT=successful
dkms-build MODULE=nvidia RESULT=failed
so that one can wait for dkms-build MODULE=nvidia without needing to indicate which.)
| Anders Kaseorg (andersk) wrote | #1 |
| Mario Limonciello (superm1) wrote | #2 |
| Changed in dkms (Ubuntu): | |
| status: | New → Won't Fix |
Hmm, that gdm commit was later reverted, so maybe bug 453365 should just be reopened, and this closed as a duplicate.
http://