Phosh: Message "Oh no! Something has gone wrong." after upgrade

I've had the exact same issue on the PinePhone PostmarketOS CE. The system logs showed

$ logread | grep -i gnome
...
Jul  2 07:57:36 XXX daemon.warn gnome-session-binary[3367]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.XSettings'
...

Removing org.gnome.SettingsDaemon.XSettings from the RequiredComponents in /usr/share/gnome-session/sessions/phosh.session solved it for me.

By Yannick Uhlmann on 2021-07-02T06:16:04

Removing org.gnome.SettingsDaemon.XSettings from the RequiredComponents in /usr/share/gnome-session/sessions/phosh.session solved it for me.

Don't do that :)

Can you try:

$ sudo apk fix -r gnome-settings-daemon
$ sudo rc-service tinydm restart

By clayton craft on 2021-07-02T06:16:04

@augustunderground and @jakko, do those thumbs up mean the issue has been resolved for you guys using the workaround @craftyguy mentioned?

By Bart Ribbers on 2021-07-02T08:52:00

Yes, this has solved it, at least for me. Thank you and sorry for not being clearer.

By Yannick Uhlmann on 2021-07-02T08:53:57

Yes, it solved the issue for me as well.

Current version of gnome-settings-daemon is 40.0.1-r0.

By Jakko on 2021-07-02T08:56:16

Thanks @craftyguy the workaround worked. I encountered this issue after updating pmOS

By Bobby The Builder on 2021-07-02T22:17:24

added ui-phosh + 1 deleted label

Not sure if it's related but, anyone else is experiencing a freeze of phosh for like 20/30 seconds 5 seconds after it get started ?

The lock screen is completely unresponsive and, apart from the usual apk-polkit-server, nothing seems to be eating CPU resources...

By Bobby The Builder on 2021-07-02T22:26:20

Same here. This should go into a separate issue report. I can set one up...

By Jakko on 2021-07-02T22:26:19

Yeah I did notice that but haven't looked into it yet. Let's move this to a new issue: #1142 (closed)

By clayton craft on 2021-07-02T22:26:51

Closing issue since a workaround has been posted on the edge blog.

By clayton craft on 2021-07-02T22:58:05

I don't know if this is sufficient. I could imagine people running into this not being aware about the edge blog. Also if one has no ssh access for some reason and it's installed on internal memory, it gets difficult.

By Jakko on 2021-07-02T22:58:05

if you run edge, you should be subscribed to the edge blog posts. also, I didn't delete this issue, I just closed it. folks can still search for the error message and find it.

By clayton craft on 2021-07-02T23:00:08

OK for me.

By Jakko on 2021-07-02T23:02:52

closed

Think we have to re-open this one. Was busy on other things and just took the upgrade on the 9th. Got the "You Lose" screen, came to the blog and did the recommended fix. Then I got the lock screen, followed by the "You Lose." Had to follow the advice above to remove org.gnome.SettingsDaemon.XSettings to get back in again. Since that is not something that is going to be stable, there is still some life in this 'lil bug, needs a mite more squishing.

By John Morris on 2021-07-10T21:40:11

Please make sure you use apk upgrade -a to upgrade your device running edge.

You should not need to remove org.gnome.SettingsDaemon.XSettings. Attach your full ~/.local/state/tinydm.log

By clayton craft on 2021-07-10T21:40:10

reopened

Have done apk upgrade -a, then downgraded portfolio because it always breaks. :) Have done apk audit and apk audit --system and didn't see anything obvious. Attaching tinydm's logtinydm.log

By John Morris on 2021-07-12T06:53:34

that log seems.. fine as far as I can tell. I compared it to the tinydm.log on my device, and all the failures/errors are "expected", or at least not fatal enough to give me the "oh no" screen on phosh. This tinydm.log is definitely from when you see the "oh no" message, right?

By clayton craft on 2021-07-12T06:53:34

Assuming there wasn't some nonsense in gnome vfs it should be right. Had the "Oh No" on the phone's screen when uploading it and used sshfs to get to it from Firefox on Fedora/Mate's upload dialog.

How about this for crazy. While reverifying the report above, while the "Oh No" was displayed so I could look at the log and compare to what I uploaded.... a call came in. I answered it and talked for a few minutes. The Oh No returned after the call BUT there was a normal bar at the top of the display and an arrow on the bottom. Touched the arrow. "Oh No" collapsed into an app window and the launcher is up. Wifi is up, firefox runs.

Yeeted the "Oh No window" away and the session closed, back to no joy. It isn't as dead as it wants us to believe. So to clean things up just did service stop tinydm and then start.

Ok, the file I uploaded in one window and less on the pinephone in another. Nope, they aren't exactly the same. Some items are in a different order and the one I uploaded has more lines, looks like chatty even started up then. Just did a manual scp to put the tinydm.log file on my desktop PC and uploading that direct from /tmp/. tinydm.log

By John Morris on 2021-07-12T17:34:28

How about this for crazy. While reverifying the report above, while the "Oh No" was displayed so I could look at the log and compare to what I uploaded.... a call came in. I answered it and talked for a few minutes.

Ya, the "oh no" isn't fatal. I mean, phosh thinks it is, but other apps can/will still run though launching some is tricky if you can't get at the phosh "desktop".

Well, I'm really confused by this problem you are having. You don't seem to be hitting the original issue here, where gsd-xsettings was crashing and causing phosh to crash. Nor do you seem to be hitting the most recent issue with GTK3 missing some patches. The failures for both of those show up in the log.

Probaby the next thing to try is enabling verbose debug out put for phosh, in the hopes that the log will include some more info about what's going on. The most straight forward way to do that is to edit /usr/bin/phosh like this:

--- a/usr/bin/phosh
+++ b/usr/bin/phosh
@@ -48,4 +48,5 @@
 # variables from /etc/profile.d (XDG_*)
 [ -n "$WLR_BACKENDS" ] || WLR_BACKENDS=drm,libinput
 export WLR_BACKENDS
+export G_MESSAGES_DEBUG=all
 exec "${COMPOSITOR}" -C "${PHOC_INI}" -E "bash -lc '${GNOME_SESSION} --disable-acceleration-check --session=phosh --builtin'"

Then, when you restart tinydm, the tinydm.log should have a LOT more information in it.

By clayton craft on 2021-07-12T17:34:28

That did indeed produce much more output. Also killed the screen lock. It appeared but was unresponsive even after a couple of minutes. Observing it changed it.

tinydm.log

By John Morris on 2021-07-13T15:29:15

Just noting that this bug still persists for me. Keep having to edit phosh.session every time it gets updated.

By John Morris on 2021-09-26T14:24:49

Hello John, Have you tried the following:

Backup /usr/share/gnome-session/sessions/phosh.session
Delete /usr/share/gnome-session/sessions/phosh.session
Execute :

$ sudo apk fix -r gnome-settings-daemon
$ sudo rc-service tinydm restart

If this doesn't solve the issue I suggest to reinstall a fresh pmOS image

By Bobby The Builder on 2021-09-26T14:24:49

An update. Tried debug again and it didn't act differently this time. But it isn't helpful either.

These are the only lines that look like they relate:

Note this: nome-session-binary[2385]: WARNING: App 'org.gnome.SettingsDaemon.XSettings.desktop' exited with code 1

Then this happens with multiple services:

(gsd-power:2514): dconf-DEBUG: 11:15:17.620: watch_established: "/org/gnome/settings-daemon/plugins/xsettings/" (establishing: 1)

Whut? How do they establish a connection after it exits?

Finally this happens:

gnome-session-binary[2385]: WARNING: App 'org.gnome.SettingsDaemon.XSettings.desktop' exited with code 1 gnome-session-binary[2385]: WARNING: App 'org.gnome.SettingsDaemon.XSettings.desktop' respawning too quickly gnome-session-binary[2385]: CODE_FILE=../gnome-session/gsm-manager.c:CODE_LINE=287:on_required_app_failure:Unrecoverable failure in required component org.gnome.SettingsDaemon.XSettings.desktop

So is there an environment variable to force XSettings to be more verbose? Figuring this has to be a case of having picked up an obscure package or being missing something that the dependencies aren't flagging as an error. But what?

Is there a stock world file I can easily grab to compare to, even purge my install down to in an attempt to nail this down? Reinstalling doesn't get to the root of a problem like this.

By John Morris on 2021-09-27T21:21:17

I assume you did the steps here? #1140 (comment 687146713)

I've also seen XSettings fail if Xwayland failed for some reason...

Is there a stock world file I can easily grab to compare to, even purge my install down to in an attempt to nail this down? Reinstalling doesn't get to the root of a problem like this.

If you have pmboostrap installed, you can easily build a chroot with a 'pure' pmOS install of phosh in it, then compare/contrast to your install

By clayton craft on 2021-09-27T21:21:16

Ok, think I have a fairly important clue.

Lack of debug messages was frustrating so went looking for ways to get it to say more. Moved /usr/libexec/gsd-xsettings to /usr/libexec/gsd-xsettings-real and replaced the original location with a small shell script. Eventually managed to not only make it say something useful, I have patched it to load and run. They key is setting GDK_BACKEND="x11"

Attaching the working script and the log output.gsd-xsettings

log.xsettings

By John Morris on 2021-10-07T06:11:58

what's in /etc/tinydm.d/env/wayland.d/50-firefox-wayland.sh ?

By clayton craft on 2021-10-07T06:11:58

That one just sets MOZ_ENABLE_WAYLAND=1

But that idea got me to digging and found /etc/profile.d/gtk-app-wayland.sh hanging around although no current package owns it. And it was doing GDK_BACKEND=wayland and killing gsd-xsettings.

Fixed that, removed all debug code and workarounds. restarting tinydm and no crash. Now this one can finally be closed!

By John Morris on 2021-10-07T17:46:21

That one just sets MOZ_ENABLE_WAYLAND=1

Yeah, the reason I asked is because it sounded like you either didn't have the latest tinydm or maybe that file was overriding something.

Fixed that, removed all debug code and workarounds. restarting tinydm and no crash. Now this one can finally be closed!

\o/

By clayton craft on 2021-10-07T17:46:21

@jakko can we close this?

By Alexey Min on 2021-10-07T17:52:44

Yes, we can close this. I'll do that.

I think there were two different issues here. The initial issue was solved quite a while ago. Concerning the second issue: Checking https://pkgs.postmarketos.org/packages -> Contents -> File: gtk-app-wayland.sh; this one is currently provided by postmarketos-ui-asteroid and postmarketos-ui-plasma-mobile. I guess the file was a leftover from the past or something. Glad it's solved.

By Jakko on 2021-10-07T17:52:44

closed

Phosh: Message "Oh no! Something has gone wrong." after upgrade

Describe your issue

What's the expected behaviour?

How to reproduce your issue?

What device are you using?

On what postmarketOS version did you encounter the issue?

On what environment did you encounter the issue?

Phone environments

Other

How did you get postmarketOS image?

What's the build date of the image? (in yyyy-mm-dd format)

Additional information

Child items ...

Activity