Please check if you have anything in “/sys/fs/pstore/” folder after such crash if it happens again, or if you already have something there. If you have a crash log there please send the log to me in private message, preferably compressed with gzip or some other simple packaging method.
4 Likes
Easy way is using terminal app (which you get when you enable developer mode) and there using devel-su to get root access using the password set in developer mode settings.
2 Likes
Send via email, couldn’t figure out how to gzip it and couldn’t directly attach the file here for DM
1 Like
You can rename the file ending to whatever you want and then just mention to me which format it really contains.
I already tried that, then you get the error in the second screenshot (image corrupt).
Any update on a fix here? This is super annoying and inconvenient 
@mal any update on this? You never replied to my email?
I’m not sure if I should create a new bug report or give my information here. It seems I hit this bug when the phone was connected to my suspended laptop with “USB ports powered when off” setting in BIOS. It only happened once.
Hardware: Jolla Phone 2026, 1.0.0.17
OS: 5.2.0.17
Patchmanager: no
Chum: no
OpenRepos: File Manager installed, but was not in use
Description: Phone was only connected for 10-20 minutes and didn’t turn on screen when pressing the button or tapping. It didn’t happen immediately. After pressing the power button for 5? seconds it vibrated and did not turn on (so it turned off). A second long press until the phone vibrated turned it on again. My charging cable displays power draw and it showed 0 before it happened. The USB icon on the phone showed power is connected.
Laptop is a Lenovo IdeaPad 5 Slim, 10ARP13
Update: It may have happened a second time - without USB being connected to the Laptop, but with a USB hub attached that sometimes has a flaky connection that unmounts storage if the USB cable is bent a little bit. Not sure if USB has anything to do with it. This time I had the time to try and see if it is fully dead or just had an unresponsive UI. A UI restart via systemctl from SSH restored functionality - so in my case it was not a full crash - but it may feel like it for users who don’t have SSH enabled.
3 Likes
@mal, I sent you the information you asked for, including a fresh capture 31/8, and asked you to let me know if you found anything or whether you needed any more information. You (again) didn’t respond, so I’m assuming you have all the information you need for a fix, and I was wondering when we might expect to have it?
Unfortunately the logs you sent didn’t contain any useful information, no crash was seen in the logs at all.
Maybe the issue is something else then and we should enable persistent journal logs if there would be anything useful. That can be done by replacing the line “Storage=volatile” with “Storage=persistent” in file /etc/systemd/journald.conf (you need to use devel-su to get root access to edit the file) and then rebooting the device.
A small additional question, do you have any bluetooth devices connected to your phone or had been connected earlier before the issue happened?
Matti is this bug report useful?
No, bluetooth isn’t even turned on.
I’ve set the configuration option to persistent, please clarify -
- whether there’s anything I should be aware of like increased disk usage/wear-and-tear or other,
- does this change the log file you want or is it still the pstore,
- would you still like me to keep clearing the partition before plugging the charger or is this no longer needed with the persistent log
Enabling persistent logs will increase writing to disk somewhat and should be disabled once we have done enough debugging. It might still be useful to get pstore in case if it happens to contain something useful. The journal log from previous boot can be obtained after device reboots using “journalctl -b -1 --no-pager”.
1 Like
@mal I’ve sent you the two log files from a fresh crash by email. I’ll turn off the persistent log again for now. Reply here with your findings and next steps.
1 Like
@mal My last post asked for your findings and next steps. I’d still like those.
I understand you may be busy and that things have to be prioritised. But this isn’t working for me. I have to keep asking for a response, and replies only seem to come when I ask directly. That’s not a workable process, and it leaves me unsure whether to keep testing or wait.
I want this to work the other way: you post updates here, instead of me having to chase them. So please provide:
- A timeline. Even rough. If a fix is weeks or months away, say so. If it’s been deprioritised, say that too.
- Updates in this thread. Post findings, status, and next steps here so those of us affected can follow.
- A clear next step. What you need from us, if anything, and what you’re doing next.
I’m not asking for a fix tomorrow. I’m asking for a commitment to communicate progress here, so we aren’t left guessing whether this is being worked on or has fallen off the radar.
1 Like
Sorry for not answering earlier. Unfortunately none of the logs you have provided contained any errors that I could find. The journal log was quite limited for some reason and didn’t contain anything related to charging. Some additional information might be useful. What chargers do you use? Are those fast or slower chargers? How empty is the battery when you start charging? Does the issue only happen if charge is very low when you start charging?