OS-issues issueshttps://source.puri.sm/Librem5/OS-issues/-/issues2024-03-17T14:16:17Zhttps://source.puri.sm/Librem5/OS-issues/-/issues/352Mozilla Location Service is being retired2024-03-17T14:16:17ZGuido GüntherMozilla Location Service is being retiredSee https://github.com/mozilla/ichnaea/issues/2065 .
Without this geolocation for Purism devices will become rather suboptimal so a replacement service is needed.See https://github.com/mozilla/ichnaea/issues/2065 .
Without this geolocation for Purism devices will become rather suboptimal so a replacement service is needed.https://source.puri.sm/Librem5/OS-issues/-/issues/351network problems2024-02-15T08:23:08ZChris Vogelnetwork problemsNetworking stops working.
## Observations so far:
* happened around docking
* gcc/Network gives a message: _Oops, something has gone wrong. Please contact your software vendor._ followed by _NetworkManager needs to be running._
* In `T...Networking stops working.
## Observations so far:
* happened around docking
* gcc/Network gives a message: _Oops, something has gone wrong. Please contact your software vendor._ followed by _NetworkManager needs to be running._
* In `Terminal` as `purism@pureos` `ip ad li` returns with _Segmentation fault_ …
* …and `sudo -i` makes the session hang. `sudo` can't be stopped by `CTRL`-`c` nor backgrounded by `CTRL`-`z`
* After rebooting there is no problem disabling the wireguard vpn connection through phosh and then logging in via the local ethernet connection through the hoyoki dock.
## How to reproduce
**Don't know, yet**
# What hardware are you running on?
Librem5 R4
# Relevant OS information
## Which kernel are you using?
Linux pureos 6.6.0-1-librem5 (Jan 10 09:42:16 UTC 2024)
## Which OS are you using?
PureOS Byzantium - last update around 2024-02-12
Update: [journal starting with connect of hoyoki dock and ending with next boot](https://fileshare.link-goe.de/c92ac956ef8a) (btw: why couldn't I upload it here?)https://source.puri.sm/Librem5/OS-issues/-/issues/350Consider adding a small swapfile to rootfs to avoid excessive zram pagefile n...2024-02-15T13:11:23ZJC StaudtConsider adding a small swapfile to rootfs to avoid excessive zram pagefile negotiationsAs described in [this forum thread](https://forums.puri.sm/t/improve-your-librem-5s-performance-with-this-one-weird-trick/22598), a small swapfile in rootfs has been observed to aid system responsiveness and stability by alleviating exce...As described in [this forum thread](https://forums.puri.sm/t/improve-your-librem-5s-performance-with-this-one-weird-trick/22598), a small swapfile in rootfs has been observed to aid system responsiveness and stability by alleviating excessive pagefile negotiations in zram. My personal anecdote it that even a swapfile of 512MiB was shown to be helpful but, of course, a larger swapfile is beneficial as disk space requirements allow.
This ticket serves as an argument in favor of the default L5 PureOS configuration mitigating performance/stability issues derived from the relatively limited disk space in the 32GB L5.https://source.puri.sm/Librem5/OS-issues/-/issues/349Return from suspend locks the OS2024-02-01T17:33:29ZMatthias ApitzReturn from suspend locks the OSPackage: phosh
Version: 0.32.0-1pureos1~byz1
vmlinuz-6.6.0-1-librem5
I do use my L5 as daily driver with enabled suspend to 2 minutes idle time on battery and 2 hours on AC. From “time to time” (say once a day) I face the problem that ...Package: phosh
Version: 0.32.0-1pureos1~byz1
vmlinuz-6.6.0-1-librem5
I do use my L5 as daily driver with enabled suspend to 2 minutes idle time on battery and 2 hours on AC. From “time to time” (say once a day) I face the problem that the L5 does not work correctly after coming back from suspend, mostly when the AC is plugged into the suspended phone, or when it is disconnected from AC and it was in suspend after 2h.
does not work correctly means:
1. the lock screen comes up
2. phone can be unlocked
3. terminal app echoes chars but no command starts and Ctrl-C has no visible effect
4. upper bar can be pulled down, but changing Wifi has no reaction
5. reboot or power from the menu dims the display, but does not shutdown the phone
Only long press on power button and an additional press bring it fully back to life.
I've done in the forum an exact log when and in which situation this has happened:
https://forums.puri.sm/t/status-of-suspend-for-librem-5/13918/510
and it turns out that these locks only happen when the phone is in suspend (logically) and I plug something in into it's USB-C port, either the AC or a laptop for tethering. Since I always wake it up before with a short press on power button no locks happen anymore.https://source.puri.sm/Librem5/OS-issues/-/issues/348Run chromium Wayland by default2023-12-21T09:26:59ZGuido GuntherRun chromium Wayland by defaultThis help copy / paste but also keyboard input.
```
chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
```This help copy / paste but also keyboard input.
```
chromium --enable-features=UseOzonePlatform --ozone-platform=wayland
```https://source.puri.sm/Librem5/OS-issues/-/issues/347Robust A/B Bootloader&Recovery Installs and Updates (to interoperable, hardwa...2023-11-29T10:00:26ZinxRobust A/B Bootloader&Recovery Installs and Updates (to interoperable, hardware separated eMMC boot partitions)
This is a newly researched issue for implementing an A/B Bootloader&Recovery scheme on the Librem 5.
Filing it as I've put some work into reading the old devkit issue https://source.puri.sm/Librem5/librem5-devkit-tools/-/issues/10 "Pla...
This is a newly researched issue for implementing an A/B Bootloader&Recovery scheme on the Librem 5.
Filing it as I've put some work into reading the old devkit issue https://source.puri.sm/Librem5/librem5-devkit-tools/-/issues/10 "Place u-boot in the boot MMC area" (that one could be closed in favor of this one) and its related work which was never merged, all the while writing down this distilled and overhauled summary.
It's not a completely trivial thing to enable, but still only a small list of rather simple things required to make it all interact properly.
By now, there doesn't seem anything missing anymore in mainline u-boot to go forward with using the hardware partitions for an A/B update scheme (presentation linked below).
[Adding @sebastian.krzyszkowiak here, as author of the most current attempt to start installing the bootloader into a boot1/boot2 hardware partition (https://source.puri.sm/Librem5/librem5-flash-image/-/merge_requests/24)]
[Adding @guido.gunther and @dorota.czaplejewicz which seem the only remaining active accounts from https://source.puri.sm/Librem5/librem5-devkit-tools/-/issues/10]
-------
Goals
Features:
* robustness of u-boot updates (i.e. flashed to currently not-booted hardware boot partition, only activated upon write verification),
* u-boot fallback options (the previously-booting hardware boot partition remains unchanged, only inactivated),
* allows for robust installation of an integrated jumpdrive recovery option (into a hardware boot partition), which in turn
* allows for the most basic security measure, i.e. "production images" that have the uuu access disabled by default (without loosing all fallback/recovery options).
* Allows to use GPT partition table (https://source.puri.sm/Librem5/librem5-devkit-tools/issues/7). And thus, finally:
* Allowing for generic OS installations, i.e. allowing u-boot to boot generic distros (e.g. using /boot partition, and plain rootfs with /vmlinuz + /initrd.img links, possibly (U)EFI etc.) and thus become accessible to more distro users and customers.
-----
Definitions and Findings
"A/B Updates" safely update a currently unused partition before "atomically" switching over to start using the updated one, while retaining the possibility to switch back to the previous version.
The A/B switching scheme is well supported by the established eMMC standard's feature of "hardware partitions" (these exist separately from the usual OS accessible, and software partitionable block device that an eMMC provides).
"A/B System Image Updates" are based on partitions that contain and switch between complete OS images.
For an open device, however, that not only allows to be run by different operating systems, but is also usually updated by package managers that allow fine grained switching between multiple kernel as well as general package versions, the basic eMMC features may rather be used to implement...
"A/B Bootloader&Recovery Updates". These provide robust support for the hardware specific booting parts, and a recovery tool that allows direct access to the regular eMMC block device (OS partitions) for (re)installs, backups, fixing misconfiguration etc. (i.e. "jumpdrive").
Operating systems that use package manager based updates won't need any further A/B partitions. Others may still use the A/B scheme based on the OS managed partition table, which can be created and adjusted while staying interoperable with other distributions, instead of resetting the eMMC with resized hardware partitions.
-----
Implementation
The layout for the hardware boot partition would be to place a partition table and an efficient, no-journal, noatime filesystem for the recovery system on it. Locating the filesystem partition between the area where the u-boot binary gets installed in the beginning of the partition and where the u-boot environment is placed at the end. This likely means using a MBR partition table, as it only uses little space at the start with no copy at the end of the partition.
0. For robust updates [EDIT: ~~one package must provide something like a central flag to switch the active partition only once, e.g. during shutdown. This allows all "flashing" procedures to remove the flag if present before starting to write (invalidating prior verifications) and set this flag after verifying their applied writes. Using a flag instead of directly changing the active partition avoids that subsequent flashing procedures write to the wrong partition due to the active partition having changed before. The flag providing package should also store which partition was active during boot, so it can notice and report if the active partition has already been insecurely changed directly (risk of incomplete or conflicting changes).~~ it is only required for all "flashing" procedures to always copy over the entire active partition to the inactive one before applying their changes, and call (ideally flagging the system) for a reboot. Just because without a reboot, changes made by one procedure (u-boot, u-boot environment, jumpdrive) will be overwritten by any other as long as "unbooted changes" exist in the system (i.e. flagged for reboot). The flag could be implicit by updating a creation date or sequence number when copying over the active boot partition to the inactive one (i.e. reboot flag = seeing a newer inactive partition).
1. The **uuu flash tool** must only write to the inactive hardware boot partition, and activate it afterwards, to prevent all bricking risks when flashing "production" images (which would have uuu access disabled by default) in case flashing gets interrupted. For a "complete factory-reset reflash" the u-boot environment area must be cleared, if not contained in the image.
1. The **u-boot .deb package** must use the inactive hardware partition's linux device to "flash" and verify directly to it, [EDIT: ~~including a copy of the u-boot environment from the active partition~~ *after* copying over the entire currently active boot partition. The eMMC hardware partition write access is described at https://docs.kernel.org/driver-api/mmc/mmc-dev-parts.html, best to have the hardware partitions writable only in single-user mode, and otherwise always set them "write protected until re-boot" during boot. If also applying u-boot *environment* updates, ideally show all "conf-file" additions/removals or conflicts to the user, at least print the diff to syslog to ease fixing potential errors.
1. The `saveenv` command in **u-boot**, and its corresponding `fw_saveenv` build in the **u-boot-tools** package, must copy the entire boot partition to the inactive one, and save the modified environment there, to always allow falling back to a working pre-change u-boot environment.
1. A **jumpdrive package** could "flash" by installing to the mounted filesystem on the inactive hardware partitions (while making it writable during the install), but must consider that versions in the hardware partition may also be installed by other OSes or means.
-----
References
There exists a presentation of the u-boot features for A/B updates, although in the context of complete OS image updates, and not going into using eMMC hardware partitions beyond giving one reference:
https://bootlin.com/pub/conferences/2022/elce/opdenacker-implementing-A-B-system-updates-with-u-boot/opdenacker-implementing-A-B-system-updates-with-u-boot.pdf
u-boot mainline way to access eMMC hardware boot partitions: https://narkive.com/rwJ8voQj.13
u-boot security: https://www.timesys.com/security/securing-u-boot-a-guide-to-mitigating-common-attack-vectors/
general eMMC info:
https://www.embeddedartists.com/wp-content/uploads/2020/04/Working_with_eMMC.pdf
https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/eMMC-RPMB-Enhance-GP-and-use-protection/ta-p/1099818?attachment-id=156785https://source.puri.sm/Librem5/OS-issues/-/issues/346Road to crimson2024-01-26T10:03:24ZGuido GuntherRoad to crimsonAs discussed with @evangelos.tzaras let's have a meta issue (this only lists the things still todo, not all the things that have already been done):
- [ ] Switch image build to debos (https://source.puri.sm/pureos/infra/pureos-image-rec...As discussed with @evangelos.tzaras let's have a meta issue (this only lists the things still todo, not all the things that have already been done):
- [ ] Switch image build to debos (https://source.puri.sm/pureos/infra/pureos-image-recipes/-/merge_requests/2)
- [ ] Continuously build *recent* unencrypted images using debos (replacine [our vmdebootstrap ones for landing](https://arm01.puri.sm/job/Images/job/Image%20Builds%20landing/))
- [ ] complete gtk3 patches (https://source.puri.sm/Librem5/debs/gtk/-/issues/38)
- [ ] Use u-boot via deb (from there on we can deprecate arm01)
- [ ] crimson artwork (https://source.puri.sm/Librem5/OS-issues/-/issues/334)
- [ ] backport core libs
- [ ] [gtk 1.12](https://source.puri.sm/Librem5/debs/gtk4/-/issues/9)
- [ ] [libadwaita 1.4](https://source.puri.sm/Librem5/debs/libadwaita/-/issues/1)
- [ ] wlroots 0.17.0 (no issue yet)
- [ ] Sort out pulseaudio vs pipewire
- [ ] pipewire echo cancellation
- [ ] continuously build encrypted images too
- [ ] here we could release an alpha/beta variant (depending from what's still open from the issues below):
Issues tagged crimson:
- [Librem5 space](https://source.puri.sm/groups/Librem5/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=crimson&first_page_size=100)
- [PureOS core](https://source.puri.sm/groups/pureos/core/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=crimson&first_page_size=100)
- [PureOS packages](https://source.puri.sm/groups/pureos/packages/-/issues/?sort=updated_desc&state=opened&label_name%5B%5D=crimson&first_page_size=100)
Other bits:
- [ ] Test upgrade path from Byzantium
- [ ] [sync issues](https://master.pureos.net/sync/7/issues)https://source.puri.sm/Librem5/OS-issues/-/issues/345No DHCP server on the L52023-11-15T12:29:24ZMatthias ApitzNo DHCP server on the L5The Librem 5 does use Network Manager, but does not run a DHCP server. The consequence is that devices which are tethering with the L5 through an USB-C cable don't get assigned an IP addr. For a full detailed description of the problem s...The Librem 5 does use Network Manager, but does not run a DHCP server. The consequence is that devices which are tethering with the L5 through an USB-C cable don't get assigned an IP addr. For a full detailed description of the problem see also the thread in the forum: https://forums.puri.sm/t/usb-tethering-freebsd-laptop-with-l5/21819https://source.puri.sm/Librem5/OS-issues/-/issues/343Dialog pops up when trying to power off: "Some applications are busy or have ...2023-11-12T15:53:46ZElias RudbergDialog pops up when trying to power off: "Some applications are busy or have unsaved work", "Unknown application"After having closed all applications and then having selected "Power Off..." in the menu, sometimes a dialog pops up saying this:
"Some applications are busy or have unsaved work", "Unknown application"
Photo of what it looks like:
![p...After having closed all applications and then having selected "Power Off..." in the menu, sometimes a dialog pops up saying this:
"Some applications are busy or have unsaved work", "Unknown application"
Photo of what it looks like:
![poweroff2](/uploads/e49ecd2304c603887a2ed15a4e9e1406/poweroff2.jpg)
Two problems:
- There is no application running as far as the user can see, so it is confusing for the user that the dialog is claiming that
- It says "Unknown application" where the application's name was supposed to be, giving the impression that strange unknown things are running
Questions:
- When that happens, is there some way for me as a user to find out which application the "Unknown application" is? (I did check "top" in terminal and saw nothing obvious there)
- How does it check for running applications for the purpose of this dialog? Could I do the same check myself from the command line?
- Could the software handling this be changed to at least show a process id (pid) or something in case the application name is indeed unknown?
The dialog works properly in other cases, for example if I have the text editor open with some unsaved text, then the dialog properly shows that, and the application name "Text Editor" is shown properly in that case.
This is on a Librem 5 running the default PureOS byzantium, current phosh version is 0.32.0-1pureos1~byz1.https://source.puri.sm/Librem5/OS-issues/-/issues/342Timeout when refreshing mobile network2023-11-12T10:13:52ZJan VlugTimeout when refreshing mobile networkWhen I select Gnome Settings > Mobile > Network, and disable Automatic, Choose Network gets a spinner behind it. After a a little while a message appearch: Timeout was reached, or: Error: scanning networks failed: GDBus.Error:org.freedes...When I select Gnome Settings > Mobile > Network, and disable Automatic, Choose Network gets a spinner behind it. After a a little while a message appearch: Timeout was reached, or: Error: scanning networks failed: GDBus.Error:org.freedesktop.libqmi.Error.Protocol.Internal: Couldn't scan networks: QMI protocol error (3): 'Internal'.
However, very seldomly, I do get a list of Networks.
See also: https://forums.puri.sm/t/problems-getting-mobile-data-in-france-with-dutch-provider-simpel/21803
And here some logging while I was trying to get the Network list: [network_scan_timeout.log](/uploads/2f25eab5df87adf152545434cce6fe69/network_scan_timeout.log)https://source.puri.sm/Librem5/OS-issues/-/issues/341play warning sounds before clean battery-low shutdown2023-11-10T19:16:38Zinxplay warning sounds before clean battery-low shutdownAs long as the phone is shutting down silently it's too easy to miss this.
Actually, already the low-battery notifications should make a sound.
If the battery gauge is able to wake the phone from suspend to make a sound and finally shu...As long as the phone is shutting down silently it's too easy to miss this.
Actually, already the low-battery notifications should make a sound.
If the battery gauge is able to wake the phone from suspend to make a sound and finally shutdown properly then that would also need to be considered.https://source.puri.sm/Librem5/OS-issues/-/issues/340ask for SIM-PIN(s) on boot (on lock screen, before unlocking)2023-11-11T12:49:04Zinxask for SIM-PIN(s) on boot (on lock screen, before unlocking)As the battery drains quickly the phone consequently tends to require restarting more often.
And because the phone currently boots to the lockscreen and then suspends, it's easy to forget that logging-in is required just to unlock the S...As the battery drains quickly the phone consequently tends to require restarting more often.
And because the phone currently boots to the lockscreen and then suspends, it's easy to forget that logging-in is required just to unlock the SIM card for mobile connectivity. And thus the phone can easily remain non-functional.
Idealy, the PIN dialog could be (safely?) shown on top of the lock screen, instead of only after logging in, and ~~for some time insert some /sys/power/wake_lock (https://source.puri.sm/Librem5/OS-issues/-/issues/237), to prevent suspending after the screen-off timeout and~~ repeat to schedule wake events to play some informational noise like every minute.https://source.puri.sm/Librem5/OS-issues/-/issues/337[workday endurence enablement] lower the power consumption during modem stand...2023-11-26T19:21:28Zinx[workday endurence enablement] lower the power consumption during modem standby (phone suspended)If we assume, as a generous rough estimate, that the BM818 modem could currently actually remain in standby, i.e. only listening to a single LTE tower (not moving), for 24 hours until the full battery is drained, and that we are getting ...If we assume, as a generous rough estimate, that the BM818 modem could currently actually remain in standby, i.e. only listening to a single LTE tower (not moving), for 24 hours until the full battery is drained, and that we are getting 3800mAh out of the 4500mAh battery, then the ~~modem~~phones's power consumption during standby still seems to clearly exceed 150mA!
3800/24 mAh/h ~ **158.3mA** [ **or 585,7mW** at the nominal 3,7V ]
However:
1. Where does that consumption actually occur? Does the standby consumption maybe still include a component that can be turned off? e.g. some usb hub/charger chips still powered? Has somebody measured the actual current drawn only by the modem?
1. Is that really already the lowest passive network standby state of the BM818 modem? Would it need special commands to let it enter deeper standby modes? e.g. turning off the qmi/serial/usb interfaces also **_on the modem side_** ?
------
Todo items collected from the discussion below:
**"L5 workday endurance enablement"**
(target is lowering the 600mW of power cunsumption during suspend to 320mW)
Hardware
- [ ] Go through the schematics of peripherals and document component's suspended-activity consumption tests [mesure, cut, mesure, re-solder(possibly to switched/unswitched power as appropriate)] on https://developer.puri.sm/Librem5/. Checking the consumption delta of each component one by one, to arrive at sortable list of possible power savings and documented hardware mods (for example, re-routing mods using flying wires before/behind switches, or connecting some sleep/wake signal modem pin to some interrupt capable SoC GPIO.)
SoC infos in
https://community.nxp.com/t5/i-MX-Processors/i-MX8MQ-LPDDR4-deep-sleep-mode/m-p/924828
Software
- [ ] Evaluate disabling unused parts of the RAM during suspend. (Half of the DRAM consumption is estimated to be around 150mW. If the amount of used memory is low enough, it may even become viable to hibernate to eMMC or sdcard and disable the RAM altogether, cutting out its entire 300mW from the suspend consumption.) A first test of the consumption saving could be to enable only parts of the RAM on boot.
https://lwn.net/Articles/446493/ Memory power management
https://www.kernel.org/doc/html/latest/admin-guide/mm/memory-hotplug.html
https://elinux.org/images/f/f3/Lf_elc12_pallardy.pdf PASR Framework Presentation
https://lwn.net/Articles/479886/ PASR: Partial Array Self-Refresh Framework (adds runtime dynamic power saving, does it also allow discarding RAM in suspend?)
- [ ] Evaluate and enable an alternative modem with sleep mode support as reference, e.g. the global, dual-sim EM12-G. (It can reduce the modem consumption during phone suspend by over 130mW.) (Also present a hardware mod to wire up the hidden SIM2 tray of the L5 :-)
- [ ] For modem related diagnostics, consumption comparison, and power saving workarounds on stock BM818 hardware, get the already booting modem distro in a min. usable shape to run on the BM818 (https://github.com/the-modem-distro/pinephone_modem_sdk/issues/175).
If the saving is large enough [or if it is the global usb chip suspend which breaks sdcard write access after resume (https://source.puri.sm/Librem5/linux/-/issues/484)], explore allowing the complete shutdown and re-init of the modem's usb connection, so all usb and sdcard hardware can be turned off completely during suspend. And allowing the modem to also sleep with usb off instead of suspended.
One possibility could be making the modems' serial AT interface TTY devices available to the SoC over usb networking. [While on the modem, starting the service with a telnet server/socat/...?, and starting it through the 'screen' or rather the lighter-weight 'screenie' multiplexer. And on the SoC OS, using socat to create serial TTYs devices (http://www.dest-unreach.org/socat/doc/socat-ttyovertcp.txt) where socat uses telnet and screenie to (re)connect (via its 'EXEC:' destination) to the modem, creating a new or reconnecting to an existing data link. And then using that connection in having the OS freeze/store and re-init the modem connection during resume, in order to succeed in picking up incoming calls or data (without completely resetting the modem during it's re-init).]https://source.puri.sm/Librem5/OS-issues/-/issues/336crimson: Needs newer xdg-desktop-portal2023-10-19T17:01:26ZGuido Gunthercrimson: Needs newer xdg-desktop-portalWe should update to 1.18.0 to support `/usr/share/xdg-desktop-portal/portals` otherwise portal configuration is a complete hit and miss depending on what the user installed
/cc @ChriChriWe should update to 1.18.0 to support `/usr/share/xdg-desktop-portal/portals` otherwise portal configuration is a complete hit and miss depending on what the user installed
/cc @ChriChrihttps://source.puri.sm/Librem5/OS-issues/-/issues/335L5 battery calibration does not work at all2023-10-10T19:45:12ZTomas ÖqvistL5 battery calibration does not work at all# What problem did you encounter
Battery calibration gets increasingly off over time, meaning that measured by upower -d | grep energy-full | head -2 the energy-full value will deviate more and more from the energy-full-design value foll...# What problem did you encounter
Battery calibration gets increasingly off over time, meaning that measured by upower -d | grep energy-full | head -2 the energy-full value will deviate more and more from the energy-full-design value following every charge cycle, long or short.
## What is the actual behaviour?
Since recently, upower will show something like:
energy-full: 18,1782 Wh
energy-full-design: 17,6365 Wh
Before that, something like:
energy-full: 15,1047 Wh
energy-full-design: 13,8572 Wh
The more energy-full deviates from energy-full-design, the sooner it will power off due to low battery, e.g. at perceived battery charge of 15-20%, sometimes even before it drops to that level.
## What is the expected behaviour?
Normally, upower -d | grep energy-full | head -2 is expected to show
energy-full: 13,8572 Wh
energy-full-design: 13,8572 Wh
or the energy-full value being fairly close to the value of energy-full-design
## How to reproduce
1. Reset battery calibration by removing and reinserting the battery, which powers phone back on
2. Check battery with upower -d | grep energy-full | head -2
3. Use phone normally to drain battery partially or completely
4. Plug it into the L5 charger (or similar) and charge it to full or whenever you need to remove from charger
5. Check battery with upower -d | grep energy-full | head -2 again
I have had this problem for over a year now, and it doesn't seem to matter what kind of charging cycles I run (0-100%, 50-80%, 30-100% or just about any charging cycle). The battery calibration gets significantly off in just a few days and the just keeps increasing the deviation. The only way I have found to return to a workable calibration is to reset it according to 1) above and use phone for 4-6 days before the values deviate too much for me to know the actual charge level of the battery and I feel the need to reset calibration again.
# What hardware are you running on?
Librem 5 Evergreen, European version
# Relevant OS information
OS: PureOS 10 (Byzantium) aarch64
Host: Purism Librem 5r4
## Which kernel are you using?
Linux pureos 6.4.0-1-librem5 #1 SMP PREEMPT Mon Sep 25 10:40:19 UTC 2023 aarch64 GNU/Linux
## Which OS are you using?
ID=pureos
NAME=PureOS
PRETTY_NAME="PureOS 10 (Byzantium)"
VERSION_ID="10"
VERSION_CODENAME=byzantium
HOME_URL="https://pureos.net/"
SUPPORT_URL="https://puri.sm/faq/#faq-WherecanIfindoutmoreaboutPureOS"
BUG_REPORT_URL="https://tracker.pureos.net/"
LOGO=pureos-logo-icon
## Any other information that may be helpful?
Full output of upower -d:
Device: /org/freedesktop/UPower/devices/line_power_tps6598x_source_psy_0_003f
native-path: tps6598x-source-psy-0-003f
power supply: yes
updated: tis 10 okt 2023 21:13:26 (946 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: yes
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/battery_max170xx_battery
native-path: max170xx_battery
power supply: yes
updated: tis 10 okt 2023 21:27:20 (112 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: charging
warning-level: none
energy: 14,9406 Wh
energy-empty: 0 Wh
energy-full: 18,1782 Wh
energy-full-design: 17,6365 Wh
energy-rate: 1,32274 W
voltage: 4,05141 V
time to full: 2,4 hours
percentage: 82%
temperature: 43,3 degrees C
capacity: 100%
technology: lithium-ion
icon-name: 'battery-full-charging-symbolic'
History (rate):
1696966040 1,323 charging
Device: /org/freedesktop/UPower/devices/line_power_bq25890_charger_0
native-path: bq25890-charger-0
power supply: yes
updated: tis 10 okt 2023 21:13:27 (945 seconds ago)
has history: no
has statistics: no
line-power
warning-level: none
online: yes
icon-name: 'ac-adapter-symbolic'
Device: /org/freedesktop/UPower/devices/DisplayDevice
power supply: yes
updated: tis 10 okt 2023 21:27:20 (112 seconds ago)
has history: no
has statistics: no
battery
present: yes
state: charging
warning-level: none
energy: 14,9406 Wh
energy-full: 18,1782 Wh
energy-rate: 1,32274 W
time to full: 2,4 hours
percentage: 82%
icon-name: 'battery-full-charging-symbolic'
Daemon:
daemon-version: 0.99.11
on-battery: no
lid-is-closed: no
lid-is-present: no
critical-action: PowerOffhttps://source.puri.sm/Librem5/OS-issues/-/issues/334Desktop Wallpaper for Crimson2023-11-25T11:48:33ZGuido GuntherDesktop Wallpaper for CrimsonWe currently lack a wallpaper for Crimson. Filing it here as it might come in via [librem5-base](https://source.puri.sm/Librem5/librem5-base), [phosh-wallpapers](https://gitlab.gnome.org/guidog/phosh-wallpapers) or other means.
This app...We currently lack a wallpaper for Crimson. Filing it here as it might come in via [librem5-base](https://source.puri.sm/Librem5/librem5-base), [phosh-wallpapers](https://gitlab.gnome.org/guidog/phosh-wallpapers) or other means.
This applies to all sizes/devices.
/cc @francois.techene @jonathon.hallhttps://source.puri.sm/Librem5/OS-issues/-/issues/333missing dependency to wireplumber | pipewire-media-session2023-11-27T07:14:30ZChris Vogelmissing dependency to wireplumber | pipewire-media-sessionAfter upgrading from byzantium with gnome-remote-desktop not installed audio didn't work.
`wireplumber | pipewire-media-session` had not been installed.
Suggested solution: Dependency on `wireplumber | pipewire-media-session` in `pureo...After upgrading from byzantium with gnome-remote-desktop not installed audio didn't work.
`wireplumber | pipewire-media-session` had not been installed.
Suggested solution: Dependency on `wireplumber | pipewire-media-session` in `pureos-gnome`.https://source.puri.sm/Librem5/OS-issues/-/issues/332upgrade to crimson removes gui2023-09-20T06:24:52ZChris Vogelupgrade to crimson removes guiI upgraded from an up-to-date byzantium to crimson and the gui has been removed as part of the `apt full-upgrade`.
After reboot without gui (but with graphical output of a login: prompt) the situation could be fixed by `apt-get install ...I upgraded from an up-to-date byzantium to crimson and the gui has been removed as part of the `apt full-upgrade`.
After reboot without gui (but with graphical output of a login: prompt) the situation could be fixed by `apt-get install librem5-gnome`.https://source.puri.sm/Librem5/OS-issues/-/issues/331Backport xdg-desktop-portal 0.17.12023-08-31T13:30:35ZGuido GuntherBackport xdg-desktop-portal 0.17.1This allows for finer grained selection of which portal to use which phosh can make use of.This allows for finer grained selection of which portal to use which phosh can make use of.https://source.puri.sm/Librem5/OS-issues/-/issues/329Mobile Data automatically enabled (after reboot?)2023-08-16T13:16:23ZJan VlugMobile Data automatically enabled (after reboot?)I disabled the Mobile Data in Settings. After a reboot I noticed that it was enabled again.
Normally, I never disable Mobile Data, but because I'm abroad now, and Mobile Data is expensive, I disabled Mobile Data.
I'm not sure if there re...I disabled the Mobile Data in Settings. After a reboot I noticed that it was enabled again.
Normally, I never disable Mobile Data, but because I'm abroad now, and Mobile Data is expensive, I disabled Mobile Data.
I'm not sure if there really has been traffic over the Mobile Data connection.