> Can repowerd simply hold a lock until the screen dbus service is connected?
(I am assuming you are referring to a display-on lock, which also disallows suspends). repowerd could hold a lock, but, IMO: 1. repowerd is the wrong place to put this logic. repowerd shouldn't have to know, even implicitly, about the boot time dependencies. As an example of why this is fragile, if we decide to move USC before or in parallel with apparmor reprofiling (which I suggest we do), this logic will stop having the desired effect. It would be much better to use a suspend block during the whole boot process (repowerd started -> unity8 started) using the init system facilities, as described in comment #31. 2. this lock by itself would only improve the user experience very slightly, since it would brighten the backlight but the screen would still remain black and unresponsive to power keys for some time until USC starts. I think the best solution from a UX and cleanliness perspective would be: 1. Start USC before or in parallel with apparmor reprofiling, so the user gets some visual indication that the system is working and can at least turn the screen on/off. This is optional, but I think improves UX a lot. 2. Acquire a suspend blocker (using an init job) when repowerd starts, release when unity8 (not USC) has started or failed to start. I'll try to find a way to recreate the "profiles need recompilation" scenario without flashing a new image, so we can test easily. I will provide a prototype for the proposed solution for people to try out. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1623853 Title: Device appears to be off after updating to 15Sept2016's rc-proposed image To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1623853/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
