@naz.R same in uwolf

To answer my own question, yes it still works on Noble as it did on Focal.

As a side note, I feel like I saw GPS (google maps web) working once, but currently it's definitely not working. Do we know what it would take to get it working?

@Ian Thanks, but the command didn't seem to do much. After checking updates again just now, I did get the update though, so all good for me now.

@UBportsNews Huge thanks to everyone involved. I'm not offered the Upgrade on Volla Quintus with OTA-10 yet, is this update also rolled out with delays for random users and if so, is there a way to trigger the update immediately?

@kristatos Got my answer in the 20.04 OTA 10 blog post https://ubports.com/blog/ubports-news-1/ubuntu-touch-20-04-ota-10-release-3972

tl:dr: Held back until some boot failures are solved.

So... has it been released? I haven't seen any news.

@Ida_ Ugh it started working again after restarting the phone. I didn't see any obvious errors in journalct or the output of /opt/click.ubuntu.com/uwolf.chromiumos-guy/current/librewolf.sh, not sure what the problem was, but a reboot fixed it.

Does it still start for anyone after the latest update (on 20.04)?

@ChromiumOS-Guy No rush of course but can you say a few words about noble? I don't see any commits relating to it yet, so I assume a real wayland port is not done yet? Do we know if the current state still works on noble? Thanks.

Not the only one. I was also surprised plugging in my usb-c headphones did nothing.

Generally it should be noted that this is about headphones with an usb dac. There are also adapters and headphones that pass through analog audio over the usb-c connectors, and those apparently work.

These are the open issues that have been reported so far:

https://gitlab.com/ubports/development/core/packaging/usb-moded/-/issues/6

https://gitlab.com/ubports/development/ubuntu-touch/-/issues/1912

https://gitlab.com/ubports/porting/reference-device-ports/halium13/volla-phone-quintus/volla-algiz/-/issues/3

Volla Quintus with 20.04 stable and a blau.de sim card. No alert at all.

My Doogee T10s with phhusson's AOSP GSI and no sim card did get the alert.

@RJDan Well we only know if we can contribute once we know what payment methods will be available..

That reminds me that I wanted to make a MR for this: https://gitlab.com/ubports/docs/docs.ubports.com/-/merge_requests/659

i.e.:

If connecting fails with the message ::

kex_exchange_identification: read: Connection reset by peer

check the log on the UBports device ::

journalctl | grep sshd

If you see a message about missing hostkeys such as ::

sshd: no hostkeys available -- exiting.

You need to generate host keys with the following command ::

sudo ssh-keygen -A

Getting just a bit more into UT, I guess I could get gdb on it, either by just finding a static gdb build and putting it in the user dir, or by making the system writable and installing it, and then attaching to the hanging process, but for the moment I'm just looking around.

uNav is really a QtWebEngineProcess and trivially freezing for me.

Pure Maps seems to be a native Qt application and it has been very rarely freezing (but it has happened) - on the other hand I'm not sure it ever actually stops locating with GPS while running, so it's hard to say if it suffers the same issue or not - What I'm wondering is if this is just a QtWebEngine issue or a general issue.

Looking further I guess that setRadioPower is the actual function returning the error:
https://android.googlesource.com/platform/frameworks/opt/telephony/+/master/src/java/com/android/internal/telephony/PhoneInternalInterface.java#576

    /**
     * Sets the radio power on/off state (off is sometimes
     * called "airplane mode"). Current state can be gotten via
     * {@link #getServiceState()}.{@link
     * android.telephony.ServiceState#getState() getState()}.
     * <strong>Note: </strong>This request is asynchronous.
     * getServiceState().getState() will not change immediately after this call.
     * registerForServiceStateChanged() to find out when the
     * request is complete. This will set the reason for radio power state as {@link
     * android.telephony.TelephonyManager#RADIO_POWER_REASON_USER}. This will not guarantee that the
     * requested radio power state will actually be set.
     * See {@link #setRadioPowerForReason(boolean, boolean, boolean, boolean, int)}
     * for details.
     *
     * @param power true means "on", false means "off".
     */
    default void setRadioPower(boolean power) {
        setRadioPower(power, false, false, false);
    }

So this seems to be just a general on/off toggle and should not have power saving implications.

Disabling the "Cellular data" seems to only disable the data connection, not the telephony connection, and does not affect this message. Enabling "Flight Mode" does seem to make the message stop. Flight Mode also does seem to work because I can't call the mobile number anymore when flight mode is on.

So is this maybe just a bogus error?

About once per second this message is logged to journalctl:
Jul 02 13:12:01 ubuntu-phablet ofonod[4404]: Power request failed: OPERATION_NOT_ALLOWED

The only google result for "ofonod" "Power request failed" "OPERATION_NOT_ALLOWED" is this thread about another Volla phone: https://forum.sailfishos.org/t/the-volla-x23-gx4-thread/15726/88. But it is not specifically about this issue, so I thought I'd create a new thread specifically for it.

As far as I can tell this message is harmless: I can call the mobile number and the phone rings. I can call other numbers from this phone. I only wonder what it takes to get rid of this message - and does it indicate higher than intended power draw?

When I run sudo systemctl stop ofono.service and sudo /usr/sbin/ofonod -P ril --nodetach --debug I see that the full message produced every second is

ofonod[4404]: src/binder_radio.c:binder_radio_power_request_retry_cb() slot2
slot2 < [000002e0] 24 setRadioPower
  0000: 61 6e 64 72 6f 69 64 2e  68 61 72 64 77 61 72 65    android. hardware
  0010: 2e 72 61 64 69 6f 40 31  2e 30 3a 3a 49 52 61 64    .radio@1 .0::IRad
  0020: 69 6f 00 00 e0 02 00 00  01 00 00 00                io...... ....
slot2 > [000002e0] 23 setRadioPowerResponse OPERATION_NOT_ALLOWED
  0000: 61 6e 64 72 6f 69 64 2e  68 61 72 64 77 61 72 65    android. hardware
  0010: 2e 72 61 64 69 6f 40 31  2e 30 3a 3a 49 52 61 64    .radio@1 .0::IRad
  0020: 69 6f 52 65 73 70 6f 6e  73 65 00 00 85 2a 74 70    ioRespon se...*tp
  0030: 00 00 00 00 60 50 19 b1  7f 00 00 00 0c 00 00 00    ....`P.. ........
  0040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00    ........ ........
  0050: 00 00 00 00                                         ....
ofonod[4404]: Power request failed: OPERATION_NOT_ALLOWED
ofonod[4404]: src/binder_radio.c:binder_radio_check_state() slot2 retry scheduled

but likewise the only google result for "setRadioPowerResponse" "OPERATION_NOT_ALLOWED" is the android source code.

What's next? Does this originate somewhere in the android driver stack? Could there be a way to allow this operation or might this be something the android driver generally does not allow and ofonod should be changed to stop retrying when OPERATION_NOT_ALLOWED is returned?

@ChromiumOS-Guy Thanks, extensions are accessible now. Form filling from the browser's saved passwords doesn't work, I guess it's because of copy&paste not working? But the bitwarden extension can fill form fields so it's good enough for me.

For my point 9. I found the privacy settings and that by default it deletes a lot of stuff on exit. Might be good to call these defaults out in the readme.

Not sure if this is for location access https://github.com/ChromiumOS-Guy/uWolf/commit/c27cf41b4b3bd9d1e84519ca0c7abe17637ac19c#diff-9f6e9f7df1d5f0a60e077fa35efd7d122e78595f3852769e59834397b9860c07R3-R5 but still only the browser itself asks for its internal location access permission, it still doesn't ask the OS. I think you should be able to test this far even without the smartphone actually being able to get a fix, right?

@ChromiumOS-Guy I had first installed the old 0.4 stable version from open store, then I tried the click package from the github releases and noticed it didn't read my existing profile. I also downgraded to the open store version again, then installed the latest upgrade from openstore. I guess this was not a good thing to do.

I now uninstalled the app from openstore, deleted ~/.librefox and installed it again. The auto install script ran again and I now have the tabs at the bottom again. Your modifications solve my issue 2.: The main menu hamburger button is now visible and clickable in portrait mode. It also solves 5, a new tab button is always visible now. So disregard these, as these were my own fault I guess.

What I can't seem to find in your modification is a way to access extensions. In portrait mode I see none, in landscape mode I see (unclickable because of 1.) icons for ublock, privacy badger and sponsor block but no overflow for further extensions, in particular I can't see a way to access the bitwarden extension at all. If you could manage to squeeze the extensions container (the puzzle tile) icon somewhere in this UI that would help a lot I think.

"Word suggestions" seems to be the name for auto complete, I disabled that for now, thanks. I know just a little bit about input/completion with virtual keyboards and I guess in x11/xwayland it'll always be a bit broken (I'd think currently it just fails to send an appropriate amount of backspaces before sending the "completed & corrected" word). But even on wayland the protocols aren't great. I remember being in the audience of this fosdem talk: https://archive.fosdem.org/2024/schedule/event/fosdem-2024-2972-wayland-s-input-method-is-broken-and-it-s-my-fault/

@Fuseteam With main menu I mean the hamburger menu with the three lines.

Made some videos for some of the things.

1: Solo USB key, it's supposed to turn blue when an auth request comes to it. Idk if it needs some kind of usb permission: https://youtube.com/shorts/EIjAkhwfOOw
2. Drop down boxes in the settings page, I think this might be related to the on screen keyboard because it starts working after a menu opens: https://youtube.com/shorts/o5OpgXKtTWk
3. Broken auto complete in the url bar: This time it seems to have learned not to auto correct "about:", but backspace still autocompletes quite broken stuff: https://youtube.com/shorts/Uc5UlPfpEXg

Also happens on Volla Quintus with Morph, unav, etc, on latest 20.04 OTA-9. To reproduce in morph you can go to maps.google.com, tap the location thing once, once it got your location, tap it again. The entire UI freezes, including the tab chooser thing. Freezing a whole browser with multiple tabs is kind of annoying.

Since this seems to have been broken for more than 2 years now.

• Is there any phone where it actually works without freezing?
• Any info on how this can be debugged? On desktop linux I'd start by starting the app with strace and see what call it freezes on. Can that be done on ubuntu touch too?