Comment 57 for bug 1421009

Revision history for this message
Timo Jyrinki (timo-jyrinki) wrote :

QA has found an app installation problem sometimes happening with the silo 018, fixed at least by removing and re-adding U1 account. I did not see such problem, but I also flashed clean, updated and only then added the U1 account for installing apps so it maybe the reason I was able to install apps without problems.

I did see both with and without the PPA that sometimes adding U1 account in general stalls on vivid, so that's not a regression.

On IRC I got some info about how DBus is used with app installations: "dbus is used to monitor installation progress (for the progress bar in the preview). apps store scope just passes dbus object path to unity8 dash and doesn't interact with dbus directly (at least when it comes to installation); probably unity8/dash logs are first to look at"

I now updated to latest image, added U1 account, installed an app, and then upgraded to silo 018, and I can see the problem now. When I click "Install", dbus.log gets:
---
Activating service name='com.ubuntu.OnlineAccountsUi'
Successfully activated service 'com.ubuntu.OnlineAccountsUi'
---
but unity8-dash.log gets:
---
RequestAccess failed: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/'")
---

Then when I clicked back arrow from the app page, I got a request for U1 credentials, which I canceled. When I go to u-s-s the U1 account is not there anymore. After adding U1 account, it appears that app installation work smoothly.

It seems to me the pattern is that the U1 account gets removed randomly when a reboot is involved. One time I observed the account had survived a reboot, but disappeared at the moment I clicked "Install". But it seems that without a reboot and with account added app installation seems to work for multiple apps without problems.

I did clean QML cache at one point so it does not seem to be related (also, qtdeclarative isn't touched in the PPA).

After ppa-purging the problem doesn't occur anymore. So the problem has to come from the QDBus changes in the silo, even if those provably fix the Unity 8 hanging issue during boot and no issues were seen in any of the autopilot tests.