Shutting down after oem-config runs requires password
Bug #300667 reported by
Evan
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubiquity (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Binary package hint: oem-config
After successfully running oem-config-gtk, ConsoleKit thinks that the oem user still exists and is logged in, requiring password confirmation in order to shut down the system.
Changed in oem-config: | |
importance: | Undecided → High |
status: | New → Confirmed |
affects: | oem-config (Ubuntu) → ubiquity (Ubuntu) |
tags: | added: oem-config |
To post a comment you must log in.
I have certainly reproduced this in the past, but my most recent attempt failed to reproduce it. I wonder if this is a race condition. My speculation would be that the ConsoleKit session doesn't get closed until D-BUS notices that its peer holding the session has gone away, and in some cases oem-config- firstboot manages to get in first and call deluser. That explains why deluser sometimes fails but probably doesn't directly explain why shutdown prompts, since that's probably quite a bit later in wallclock time. Perhaps once deluser has been called (IIRC it typically deletes the actual user but fails to delete its home directory), CK is unable to deregister the session? We'd need to catch it in some semblance of action.
I think this may be easier to reproduce on the server CD; that's certainly where I've seen deluser failing frequently. One could use ck-list-sessions to look at what CK thinks is going on.