@gpatel-fr No, I haven't. The UBPorts code definitely has some stuff related with that (dating from the ubuntu era...), but I have not spent time looking into it. I looked into geoclue2 as reported in this other thread, and realized that what is described there only uses wifi or cell; Geoclue2 does not switch to gps afterwards because it connects to gps chips through modemmanager while UBPorts manages the modem with ofono instead... I believe it would be easy to make a geoclue2 plugin for lomitri-location-service to first get a quick inaccurate location from local networks through geoclue2, with lomitri-location-service later automatically switching to gps when a fix becomes available. Of course, a working native AGPS lomiry-location-service implementation would be cleaner and preferable (geoclue2 is essentially duplicating the functionality of lomiry-location-service).
What I'd also like is to have gps apps continuing to receive fixes when the screen is off. I would very much like activitytracker to be able to record tracks, or PureMaps continuing to give routing voice indications while cycling, without the present unnecessary screen-on battery drain.

Sorry for the previous noise... I continued working on that issue and I believe I now have a truly working fix : Gps positions continuously obtained for over 24h, twice. For that, I had to patch two repos, touching both the android side (hybris) and the linux side. While examining the code I realized I also could upgrade it so that the fp5 can now use more than than 32 (gps-only) satellites and provides more data (notably altitude uncertainty which was blank in sensor status so far). When the weather is clear my phone sees ~80 sats outdoors, but the android-side code clips at 64, and I'm not going to fight that... With the 64 sats clip the fp5 now still gets fixes indoors at my place while before it would stop when getting inside.
I'll post the corresponding merge requests in the two repos in the next days.

A related fix was merged yesterday, So, it should land on our phones sometime when we update the OS.

Just as @applee, I suspect that this thread possibly discusses several different bugs. Notably, I believe the problem described in reply #3, and maybe by @kristatos are the same as the one I described in this other topic. The issue in that other topic is related to how UBports interfaces with the android gps drivers and it affects all apps using gps on all ported android phones released since around 2020, but possibly with app-dependent symptoms : freezing, crashing, or just going on with a frozen location.

The good news is that the other topic's bug has a working fix which should hopefully land in an upcoming OTA.

I finally nailed it! After a simple change and recompiling a package, I could have gps working continuously for over 3 hours, which had never happened previously on my FP5.

The problem was indeed in ubuntu_application_gps_hidl_for_hybris.cpp part of the package libubuntu-platform-hardware-api3 whose repo is at https://gitlab.com/ubports/development/core/platform-api, and lomiri-location-services calls this library to access the android drivers (through hybris). The problem was that the code continued to use a chunk of memory that had been supposedly freed (use-after-free) and the memory corruption only became visible when the allocator reused that freed memory chunk for a new allocation. At that point two pieces of code competed for the same memory, leading to crashing. The issue is more likely to happen quickly when many applications are running, explaining the somewhat random duration before the crash.

On my Xperia X, a different piece of code was used (ubuntu_application_gps_for_hybris.cpp, not ubuntu_application_gps_hidl_for_hybris.cpp) which explains why it never had this problem.

That gps_hidl piece of code has not been touched since 2020 and I believe UBports uses it in all phones running running Android 10+ vendor blobs, meaning that the problem should not be specific to the FP5. Yet, I find it really strange that no one reported the issue previously and that only @WillemHexspoor confirmed it here. Does that mean that UBports users either never use their gps for extended periods (e.g. routing with PureMaps or uNav) or that they only do so under waydroid, or that other phones access the gps through a different scheme (another library)?

I have filed a merge request to that package.

EDIT: I take back all what I said yesterday, it eventually crashed all the same after (except after a very long time (~10h), and then this morning again after only 3h... So the root cause is not yet found... I'm digging further.

@gpatel-fr Hey, you were right! By merely restarting the service, positioning becomes available again (no need to reboot!), and adding Restart=on-failure in the service file does the job automatically.
Alas, it's not really a fix for the problem : all the applications that were using the gps at the time of the service failure/restart quit as soon as you try to get back to them. Restarting PureMaps is much faster than rebooting, but you still need to acquire a new gps fix...

I've seen other errors than segfaults in the same piece of code :

Mar 03 15:01:50 ubuntu-phablet lomiri-location-serviced-wrapper[6592]: malloc(): unaligned fastbin chunk detected
Mar 03 15:01:50 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=6/ABRT
Mar 03 15:01:50 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.

Mar 03 15:08:19 ubuntu-phablet lomiri-location-serviced-wrapper[7546]: malloc_consolidate(): unaligned fastbin chunk detected
Mar 03 15:08:19 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=6/ABRT
Mar 03 15:08:19 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.

It seems this daemon's code did not evolve much lately. It was working well on my Xperia X which was armhf while now I have random alignment errors or segfaults on the FP5 which is arm64. But if the architecture is the reason, it should likely affect all arm64 phones running UBports, unless compilations options/checks are set differently on the FP5...

I guess I'll try to rebuild this piece of code with debug symbols, but then guidance for running it with gdb would be welcome.

@gpatel-fr Except for the bug I report here, I find that GPS on the FP5 works reliably outdoors, although it may take up to a few minutes to get the first fix ( hence maybe the hit-or-miss impression if one is not patient enough). The problem I report here is that, once you get a fix, you can't use the GPS for an arbitrarily long period: at some point (it can be after 5 minutes, 20 minutes or 2 hours) you'll hit this bug and you'll need to reboot to recover usage of the gps (the phone still works well besides that).

I've also been monitoring what goes on on the android side when the bug occurs:
LocSvc_GnssAPIClient tries to deliver an NMEA sentence via gnssNmeaCb callback to the UBports hybris layer
The binder call fails with DEAD_OBJECT because the ubuntu_application_gps_hidl_for_hybris process on the UBports side has died
LocSvc_GnssInterface detects serviceDied and calls cleanup
It sends QMI_LOC_STOP_REQ_V02 to the modem — actively stopping GPS at the hardware level
Then QMI_LOC_SET_ENGINE_LOCK_REQ_V02 — locking the engine
From this point isGpsEnabled:0 — the session is permanently dead until reboot

It seems rather clear that the root cause is the UBports process ubuntu_application_gps_hidl_for_hybris that bridges the Android GNSS HAL to the Linux side dying, at which point the Android HAL correctly detects the dead binder and shuts everything down. The GPS hardware itself is fine — it's the UBports bridge process that's crashing due to the segfault.

If the termination of the lomiri-location-serviced-cli that you observed was due to the same issue, then GPS would seem disabled afterwards, until reboot. And AFAIU having the service auto-restarting would not resucitate the GPS, but I'll give it a try.

@gpatel-fr @FlavioMala, indeed the newer Bluetooth stack had the side effect of breaking usb_tethering.
I could fix it by applying a small patch and recompiling the kernel. The patch is attached to the issue.

@gpatel-fr I also have a Radicale server and UBPorts agenda syncs well with it (both ways) as long as I do not reboot the phone after connecting to the caldav server (i.e. creating the remote caldav account). On subsequent boots, calendars no longer sync; I need to delete the remote caldav account on the phone and recreate it for syncing to work again. It could just be a problem with storing the password (I find it somewhat surprising that once it's created, it's not possible to change the remote account password, AFAICT), but I have not investigated it more than that. And, yes, it's a pain...

When an app actively uses gps (e.g. PureMaps, SensorStatus ...), I find that the location is no longer updated after a random duration ranging from a couple of minutes to well over one hour.

When that happens
-the app no longer receives position updates, as if you were not moving anymore (the app itself is fine, it's not frozen),
-the white location icon is no longer visible in the top toolbar, and if you open the positioning setting panel, positioning is "on" but no longer green and you can't toggle it.
-SensorStatus reports "AccessError"

The only way to recover gps positioning is to reboot the phone. Needless to say this bug is particularly annoying when you are depending on your phone for routing while driving. It's also quite frustrating since PureMaps would route me for hours without any problem on my previous phone (Xperia X under 20.04).

When the loss of positioning occurs, the journal shows :
Mar 01 17:02:39 ubuntu-phablet systemd[1]: lomiri-location-service.service: Main process exited, code=killed, status=11/SEGV
Mar 01 17:02:39 ubuntu-phablet systemd[1]: lomiri-location-service.service: Failed with result 'signal'.
Mar 01 17:02:39 ubuntu-phablet systemd[1]: lomiri-location-service.service: Consumed 1.165s CPU time.

and the service invokes ExecStart=/usr/bin/lomiri-location-serviced --bus system --provider gps::Provider --provider remote::Provider

so it's lomiri-location-serviced which segfaults after a random duration, requiring reboot.

I did not worry too much about the issue earlier because I do not use the GPS heavily, but I believe this issues was already present when got my FP5 back in October. I'm presently on daily channel, running 24.04-1.x (2026-02-13/2), and lomiri-location-service is 3.3.0+0~20250628184827.14+ubports~dev~1.gbp8c98a8

Am I the only one having this issue?

@gpatel-fr thanks for digging into this. So, right, it's supposed to use ncm and not rndis, but usb-moded should handle tethering with that .
The file you tried to cat is restricted to root access, but even with sudo, it's not accessible, and that probably explains why the configuration script fails, falling back to charging only.
Maybe the fp5 is missing the corresponding kernel module now, while it had it back in August?
I created a ticket.

@Moem of course, that's what triggers the messages in the journal. In French it's called "partage de connexion USB" and
I've tried both from the system settings and UT tweaks.

I'm on daily channel, up-to-date. Testing usb tethering today for the first time, I find it does not work.
In the journal I can see related errors:

usb_moded[1957]: /etc/usb-moded/usb-moded.ini: can't remove stale config file: Read-only file system
usb_moded[1957]: /sys/kernel/config/usb_gadget/g1//functions/rndis.usb0: mkdir failed: No such file or directory
usb_moded[1957]: function rndis.usb0 is not registered
usb_moded[1957]: /sys/kernel/config/usb_gadget/g1//UDC: write failure: Invalid argument
usb_moded[1957]: mode setting failed, try charging_only

Yet, it was reported earlier to be working . Is it a regression? Does it work for you?

I still don't know how to make the sdcard appear directly on my desktop computer when I connect my phone, but I have a workaround : symlink the sdcard mount point in the /home/phablet directory ( = "internal storage" on the desktop computer).

This is easily done using the terminal (or adb shell). Find the exact mount point of the sdcard using the command mount; it is something like /media/phablet/XXXX-YYYY. Then enter ln -s /media/phablet/XXXX-YYYY ~/sdcard

Hello,
I have configured the camera to store images on the sdcard, but when I connect the phone to my computer, only "internal storage" is visible. As a result, I cannot browse or transfer my photos through the GUI (I have to use adb pull from a terminal, which is a pain). On my previous UT device (sony xperiax, running 20.04), the sdcard was accessible through mtp, alongside "internal storage".

I'm currently running 24.04-1.x daily, dated 2025-10-14. Am I alone to experience this problem? Is there an easy fix?

Thanks in advance.

@sixwheeledbeast said in Fairphone 5 - 24.04-1.0:

an issue with is OSM server

Indeed, it's broken, there is a bug report for it.

I upgraded my Xperia X to the latest RC 2024-W30/2 on August 17, and since then, the GPS is no longer getting a fix (even waiting for hours). Previously I was running RC 2024-W03, and GPS worked fine (I used it on August 13).
I wish to reinstall that previous version, but I have not found detailed steps explaining how to do that. I guess I should run

sudo system-image-cli ...

in an adb shell but I don't know how to specify the image I want. Does anyone has experience doing such downgrade?

@TakoR see a fix in the Xperia X sub-forum

@los-tioz said in Sony Xperia X loses Wifi Connection:

Has anyone updated Ubuntu Touch from version 16.04 to 20.04? Is the problem with the Wlan also present there?

Wifi reconnects much more reliably in 20.04.

@TakoR I only recently made the move to focal (RC 2024-W03) and saw the same problem of hotspot only working with no password.
Some research revealed that Volla devices also had a similar problem that has been solved by adding a file in Networkmanager configuration.

The same fix (detailed below) works also for the Xperia X. You will need to reapply it at each upgrade of the OS until it is merged in the device tree, if ever.

1-From a computer open a terminal session on your phone using either "adb shell" or ssh. Alternatively you can do it in terminal app on the phone itself, but it is very cumbersome.

2-make the image writable (until reboot) :

sudo mount -o remount,rw /

3-create the new file with appropriate content:

cat << EOF > /etc/NetworkManager/conf.d/fix-ap-with-password.conf
[main]
wifi-wpa-psk-pmf-no-optional-ap=yes
EOF

4-reboot the phone

5- my (linux) laptop could still not pair with the hotspot at that point. So I deleted the failed wifi hotspot config on the laptop and also edited the hoptspot config on the phone, changing the password and rebooted the phone again. After that, the laptop could connect the hotspot with password. I guess that not all of these last steps are needed.

Besides that issue and other minor quirks, I am very pleased with the OS upgrade. I just changed the channel, and upgraded as I had done before for the xenial upgrade. After that, I upgraded all apps. The new version has about a doubled battery life (for my rather lite use case, at least) compared to xenial and it solved the bug which made the camera app record half-green pictures about 1/3 of the time.