@pparent

thanks for the explanation, it's indeed faster than the more convoluted process I was following. So I did about 6 messages each having 5 photos, lomiri-messaging memory footprint increased steadily by about 100 K for each message (that I never actually sent, it was a dummy number). When I closed lomiri-messaging all this memory was reclaimed by the system, and if I open it again I don't get back the high memory use even if I open the same contact.

So there may be a leak but it hardly seems a blocker on my phone - that is, my current use of the phone is that as soon as I have finished using an app, I close it, and each evening I shutdown the phone for the night. You may use your device very differently of course.

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

importing a picture with contentHub directly from camera app to Whatsweb (probably works with another app than whatsweb), does reduce progressively the amount of available swap, when done several times,

I tried to repro on my FP5 without success, but of course there are many differences: other phone, more Ram (I have 8 Gb hence a swap of 4Gb) , I don't use Whatsapp or Signal so all the apps available to share in contentHub are files and messages. After a dozen of shared photos, zero swap, available memory in top goes down by one or two hundred of megabytes, then back up.

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

I've never seen in a top any processes consuming outrageous amount of RAM.

That's very strange. I had kept a copy of top when the dialer had crashed my phone and it was clear that there was a culprit:

top - 21:30:13 up 12:42,  2 users,  load average: 34,25, 47,73, 35,64
Tasks: 618 total,  16 running, 601 sleeping,   0 stopped,   1 zombie
%Cpu(s):  0,5 us, 92,4 sy,  0,0 ni,  1,3 id,  1,7 wa,  2,3 hi,  1,8 si,  0,0 st
MiB Mem :   7294,9 total,     62,8 free,   7216,6 used,     64,6 buff/cache
MiB Swap:   4096,0 total,      0,0 free,   4096,0 used.     78,3 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   4265 phablet   20   0  396220   1340      0 R  60,9   0,0   3:03.44 mission-control
    130 root      20   0       0      0      0 R  44,0   0,0   6:10.27 kswapd-1:0
   3334 root      20   0       0      0      0 R  38,5   0,0   6:10.26 kswapd0:1
   4396 phablet   20   0 4640104  29844  17684 R  34,6   0,4   9:03.45 lomiri
   2055 root      20   0   17868    616      0 R  34,3   0,0   1:35.34 wpa_supplicant
   4212 phablet   20   0 2043428   1404      0 S  34,3   0,0   3:20.83 nuntium
   4888 phablet   20   0  407480   1544      0 R  34,3   0,0   2:04.60 lomiri-indicato
      1 root      20   0   25684   3884      0 R  33,0   0,1   2:36.44 systemd
   1399 root      20   0   28280    804      0 R  32,4   0,0   1:09.57 systemd-udevd
   4914 phablet   20   0 1869152   3080      0 S  31,9   0,0   2:53.33 ciborium
  23599 phablet   20   0 9934948   5,0g   1936 R  30,5  70,4   3:16.95 lomiri-dialer-a
   4429 phablet   20   0  957680    612      0 R  29,1   0,0   0:48.45 evolution-addre
  24185 root      20   0  155816  29852     84 R  28,8   0,4   0:46.14 lomiri-system-c

Also do you see kswapd taking a lot of Cpu like in my top ?

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

the swap itself could be buggy?

It's probably the same software and setup for all ports since it's not linked to Android.

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

It can be done more or less reproducibility by playing with the camera, and importing pictures to Whatsweb directly from the camera app in contentHub

could you play a little more with 'top' using 'f' and 's' to sort by VIRT or RES to see what is growing exactly, the default sort (Cpu) not being of much use here. If signal-desktop is not the culprit in this case, it may be whatsweb for example.

Note that camerahalserver (that I don't seem to have on my FP5) is part of the Android container so it's not very instructive by itself: on my FP5 all the Android processes have also high level of VIRT (10-12Gb) without causing any swap use.

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

196.4g

oh, the Ram eater !
Holmes, the game is afoot

@killclique

well, 24.04.1.1 is not there for ever, there will be at some point a 24.04.1.2 and it should get the fix.
For me, the problem is way too fleeting for me to take action, but you can try to fix it yourself by applying the change - I think that you'll need to turn the rootfs read/write for that.

Maybe a workaround could be to disable the screen saver in Waydroid ? I have no idea if this could help (@fredldotme could you have a word on this ?)

@killclique said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

when my system black screens

See my reply in your dedicated thread, I think that your problem may be specific to the Fairphone 5 and so be different from the problem as explained by @pparent (who said that the problem occurred without any use of Waydroid).

@killclique said in Black screen of death w/ waydroid:

The problem i think we are having is waydroid not releasing the screen and keeping the screen off

It looks like that. I think now that it is a known problem and the 24.04.1 stable version still misses this fix.

said in Black screen of death w/ waydroid:

I just stopped Waydroid,

Or so I believed at the time. However, when I start the phone and I run

ps fauxww | grep way

I get nothing. When I start waydroid and after running the so-called 'waydroid stop' app, when I run the same command line I see a line with the waydroid container still present. So the 'waydroid stop' app does not in fact stop waydroid, and while I was naively believing it was removed from memory it was still running.
And while repeating the test this morning I still got to the unlock screen and could use the phone, I noticed that the screen was darker than normal, as if the phone was remembering it was half asleep still

@alexanderzhirov said in Problem with updating and working with the app store:

The page opened, although everything loaded very slowly

I remember that at some point I had an extremely low performance cellular link and trying to open the store led to exactly your problem - it never succeeded to open. After switching to wifi where I got at least > 5 Mb/s, the store opened normally. There may be a software problem in the store app when the link is abnormally slow.

@alexanderzhirov

could you try to navigate to

https://open-store.io/api/v4/discover

using your browser ?

FTR using a recent Firefox it displays a nice formatted structure that one can browse and explore, while on default UT browser it should display a huge wall of Json text beginning with '{"success": true'

For fun I tried it on the more recent Qt6 browser (that you can't access if you can't use the store obviously) and it's the same as with the current (old) Morph.

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

if some important system processes may have been killed in the process.

Well, the OOM killer is legendary for it's lack of discrimination. If the system recovered somehow, there should be some trace in the system log.
I know from experience that when the system has to be rebooted after an OOM, there is no trace at all in the sytem log (and that is by itself a very major problem as it makes diagnostic impossible)

@pparent said in VP22 Upgrade from 24.04-1.0 to 24.04-1.1 failed:

I can see it in top

When using top, did you have enough time to notice if one particular application's Ram use was growing without limit ?

To elaborate, here is the grand total of my experience with OOM.

First generally with Linux (desktop and servers): it has always happened in the context of a 'rogue' application, never because I loaded too much the system. If I was loading too many apps on a given Linux system, I could always unload one of them and get back to a more normal behaviour; when a rogue application was running, I could see this application eating more and more Ram and if I could not kill it fast enough (before I lost control of the console to use kill -9) the system was all but dead, only a hard reset could get it back. Needless to say (it's a pretty well known fact of using Linux) the system OOM handler was never of any help.

Then with UT

First I have found a 'rogue' app that can reliably hang my phone. This was the first experience of it, and I could see the very same behaviour using top (it is hanging progressively, it takes a few minutes to eat all my 4 GB of swap)

Then with the dialer: this has happened very recently, while I was trying to experiment with some advanced particularities of it and suddenly the system became sluggish and the UI unusable, connecting with ssh I could see with top that lomiri-dialer-app was growing more and more and the swap was eaten. The ssh session got soon unresponsive (the phone UI itself was already gone so it was another hard reboot. I am sure that at this point the dialer was the only application active, so it's the dialer or more probably one of its libraries that is the culprit. As the dialer use quite a lot of libraries, it's not helping much, but it's possible that one of the apps you were using has triggered the same bad code path. Unfortunately I could not repro it with the dialer.

I don't know if you have noticed it, but in the system there is something of a special OOM handling, application can submit a specific OOM profile when starting. Unfortunately I have not seen it any more useful than the pretty useless kernel default handling, the rogue applications can do their evil deeds without being bothered by it.

A last detail: on my FP5 (I'd suprised if your Volla was different because it's using half of your Ram like for my FP5, it's a giveaway), the swap handling is not the 'classical' sort, it's the more advanced type of 'compressed Ram'. I don't think it's a novelty of 24.04.1.1.

@pparent

maybe this problem could be related ?

@killclique

I may have to eat my words here. After doing the test as described in my previous post, I just stopped Waydroid, stuck the phone in my pocket and got out.

Several hours later, I wanted to use my phone and had an experience that looks like what you said, but a bit different: I could vaguely see the lock screen but as seen behind a very dark screen, and I did not succeed in unlock the screen. After fiddling for about a minute trying to bring the phone to life, it did go darker still, I could not even see anything. I restarted the phone and it worked as normal, so it was not a case of battery gone to nothing.

I did not relate immediately this problem to your post because it was slightly different - I had Waydroid stopped. But now that I think of it, maybe it was. If it's true, starting Waydroid and letting the phone go to sleep could have unexpected, long delayed consequences. If I had not seen it before, maybe it's because I almost never use Waydroid.

@killclique said in Guide to charge limiting your Fairphone 5:

point me in the direction to make systemd unit file without changing the system from read-only?

I gave some directions here for another hack and it's enabled on my phone since several weeks already.

I don't know if it could really work (as you'll realize surely if you copy it as it is it will randomize your wifi Mac address, a different concern) since I have no real urge to do this at the moment. I'm unsure if it's really useful in fact, I'll have to ask a question on the Fairphone forum (and get an informed reply...) and I'm not even registered on their site.

@killclique

I tried to follow this way this morning: started the phone, launched Waydroid, waiting on the Waydroid home screen for 15' for the FP5 to go black, then wait 15' more and pressing the power button: the phone was back to the lock screen and after that Waydroid was operational. I have 24.04.1 stable installed over Android 13 like you.

@killclique

Hello,

don't seem to be a general problem since with my config I can't repro it; after my phone goes to sleep, when I press the power button the screen lights on and I get the lock screen and after unlocking, waydroid is exactly where it was before (I tested with the android camera app)

You may need to give more specific steps for others to see the problem.

@RapidRotator

while I'm no expert, I am taking a fleeting interest in these questions currently, and I can point you to an ooooold doc emerging from the mist of times:

https://manpages.ubuntu.com/manpages/questing/man2/lomiri-location-service.2.html

you'll notice that at some pre-historical point, the lomiri location service was written to allow to inject geoclue data into location info provided to applications. Is it still the case now, I have no idea. Looking at the service daemon command line (using ps) it's clear that it is not configured to do so currently.
I don't have the energy to try to hack the service to change the startup parameters accordingly - my hopes that it would just work are very low (if it was so easy, why would the UT devs not have done it already ?)

@GerhardF said in Lock The Boot Loader:

put all my Data on it?

you can try to use the built-in encryption feature. I can't say much about it because I've never tried it, but know that it exists, and it's supposed to protect the user's data (photos, docs, mails, contacts...) if the phone gets in the hands of an unfriendly person.