Bug 2414589 - Settings > Power > Battery Charging: "Preserve Battery Health" can't be set persistently when BIOS Admin Password (a.k.a Setup Password) is set.
Summary: Settings > Power > Battery Charging: "Preserve Battery Health" can't be set p...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: upower
Version: 43
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kate Hsuan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-11-12 16:42 UTC by 15184+1854+2025-11-12
Modified: 2026-07-12 00:59 UTC (History)
3 users (show)

Fixed In Version: upower-1.91.3-1.fc45 upower-1.91.3-1.fc44 upower-1.91.3-2.fc43
Clone Of:
Environment:
Last Closed: 2026-07-07 10:45:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description 15184+1854+2025-11-12 2025-11-12 16:42:57 UTC
The following was observed on Dell Laptops (with 2025 BIOS) either with Fedora Workstation 43, as well as in Atomic distributions downstream (specifically Fedora Silverblue 43 and Fedora Secureblue 42). Isolating the error through own investigation yielded that the only change from OOtB-State that was deemed significant was whether a BIOS Admin Password (a.k.a. Setup Password) had been set or not. This will become relevant for reproducing the error as well (see below in STR section).

Short description of the symptoms. 
When user attempts to use (OOtB) Fedora Workstation 43's GUI Settings dialog to set the battery charging mode to "Preserve Battery Health"
(Settings > Power > Battery Charging > Preserve Battery Health) this can't be done (persistently) on systems where a BIOS Admin Password has been set. The menu dialog resets itself against the users wishes and the Battery Level charges to 100 % or stays there, respectively, too. It can be concluded that the preserve battery health setting is not applied; battery is not allowed to reach lower charging levels.

What makes the behaviour particularly annoying and confusing: There is no visible or even user-friendly error message about what is (not) happening and why. The radio button simply switches back to the original (out-of-the-box) position, i.e. "Maximize Charge", in an almost ghostly manner: Either it does so while you leave the power menu dialog and return, or - when we waited some time after the attempt to set "Preserve Battery Health" - it does so in plain sight, spontaneously.

IMHO, it is also unclear to most laymen users that the configuration fails because of a locked BIOS or even that the setting apparently relies on BIOS changes at all.


Reproducible: Always

Steps to Reproduce:
0. Setup HW and Software. 

    0.1 Demo Hardware used to reproduce the Problem: 
        Dell Precision 7520 with BIOS updated to V 1.40.0 (IIRC provided by Dell at 2025 Q2). 
        Please specify if further hardware diagnostic outputs are required. I'll provide these, then.) 
        
    0.2 In BIOS restore BIOS V 1.40.0 default settings. For initial demonstration: Make sure that no Security Passwords are set. 
    
    0.3 Install Fedora Workstation 43. 
       (Image was obtained via Fedora Media Writer as of ca. 2025-11-09).
       During Installation tried to keep most settings as default, except for localisation (Timezone, Keyboard: German no dead keys)
    
    0.4 Using Fedora built-in Software Store to download and install latest fedora updates (in our case: Until 2025-11-12). 

Initial demonstration on feature still working apparently (w/ unlocked BIOS)

1. Click on Title bar (battery Symbol) and then on the Cogwheel icon to enter the Settings Menu.

2. In Settings > Power > Battery Charging: Set the Radio Button, which should default to "Maximize Charge", to "Preserve Battery Health". 
    Wait a few seconds, access a different Settings menu, return back to Power settings. 
--> Radio Button should still be in your desired position. 
--> This apparently works. 

3. Reset Radio Button Back to default "Maximize Charge" for next demonstration.

Second demonstration of feature buggy (w/ locked BIOS): 

3. Reboot into BIOS 

4. FYI: Note that depending on configurations in Fedora's Power menu, some BIOS settings (e.g. in [BIOS] Settings > Power Management > Primary Battery Charge Configuration) may have already been changed compared to BIOS 1.40.0 defaults. 

5. To ensure same conditions as in Step 1, restore settings again to BIOS Defaults via: 
    5.1 In BIOS, bottom right corner, click Button: Restore Settings 
    5.2 Ensure Available Configuration is set to: BIOS Defaults 
    5.3 OK

6. Lock BIOS via: 
    6.1 [BIOS] Settings > Security > Admin Password
    6.2 Enter the new Password: (***your secret***)
    6.3 Confirm new Password: (***your secret***)
    6.4 OK
    6.5 Apply, Exit BIOS
    
7. Reboot into Fedora. (Note: It could be that UEFI Updates lost through restoration are offered again. We assume that these are not relevant for the bug at hand, but they generally can and should be downloaded and updated. To not expand this report further, we'll omit the repeated OS steps here.) 

8. Repeat Step 1 to enter [Fedora] Settings Menu

9. Repeat Step 2 to set Battery Charging to "Preserve Battery Health"
--> Note how system behaves differently.
Actual Results:
--> Now Radio button does ghostly return to "Maximize Charge". Consistently with the "bad button" the device's charging level is now again charged to 100% or kept there once reached. No explanation or information of any kind is given to the user - who very plausibly might not be the device's (BIOS) administrator and not understand what is happening here. 
--> This is problematic. 

Expected Results:
Naive, theoretical ideal (IMHO):
--> "Preserve Battery Health" just works no matter if BIOS is locked or not. If BIOS settings should stay untouched - which can be assumed if a BIOS Admin (a.k.a Setup) PW is set -- one could think of a solution that might work independently from BIOS while Fedora is running and/or prompt the User (or his Admin) for a BIOS change with a user-friendly dialog. 
Depending on BIOS and Fedora this might however be impossible. 

Next best result: 
--> The Battery Charging dialog should clearly and precisely tell the user what can be configured and what not - and why. 
If BIOS lock would prevent a certain setting, it should probably be greyed out + a explanatory text shown to the user. Maybe something like ("Your system's firmware prevents changing this setting (e.g. because of a BIOS Admin Password). Please consult your system's administrator regarding potential reconfiguration.") 

The minimum solution would be that Fedora attempts the (futile) configuration change but immediately gives the user an error message, that the changes could not be applied and how to interpret this. 

Additional Information:
* As said there is no apparent error messages. Depending on whether BIOS PW was set or unset, some changes might even be pushed into BIOS. I'd say that the typical user however does absolutely not notice this apart from that the Preserve Battery setting is faulty. 

* Issue was reproduced on multiple demo laptops of model Dell Precision 7520. (Mostly manufactured in mid 2018, Firmware update from 2025). 

* Output of upower -d: 
~~~~~~~~~~
Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          BAT0
  vendor:               Samsung SDI
  model:                DELL GR5D379
  serial:               47729
  power supply:         yes
  updated:              Wed 12 Nov 2025 15:44:32 CET (4 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    warning-level:       none
    energy:              66.3114 Wh
    energy-empty:        0 Wh
    energy-full:         66.3114 Wh
    energy-full-design:  71.9946 Wh
    voltage-min-design:  11.1 V
    capacity-level:      Full
    energy-rate:         0.0111 W
    voltage:             12.921 V
    charge-cycles:       N/A
    time to empty:       248.9 days
    percentage:          100%
    temperature:         24.7 degrees C
    capacity:            92.1061%
    technology:          lithium-polymer
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-supported:    yes
    icon-name:          'battery-full-charged-symbolic'

Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          AC
  power supply:         yes
  updated:              Wed 12 Nov 2025 15:20:29 CET (1447 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:              Wed 12 Nov 2025 15:20:59 CET (1417 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             yes
    state:               fully-charged
    warning-level:       none
    energy:              66.3114 Wh
    energy-full:         66.3114 Wh
    energy-rate:         0.0111 W
    charge-cycles:       N/A
    time to empty:       248.9 days
    percentage:          100%
    icon-name:          'battery-full-charged-symbolic'

Daemon:
  daemon-version:  1.90.10
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  yes
  critical-action: PowerOff
~~~~~~~~~~

* While upower -d shows above alleged charging thresholds between 75% and 80%, on the faulty system the BIOS (i.e. [BIOS] "Settings > Power Management > Primary Battery Charge Configuration") settings remain unchanged. Mode stayed on (BIOS default) adaptive, with tresholds staying at default values between 50% and 90%, while BIOS lock is present. 
This is notably in contrast to another Dell Precision 7520 that was tested without ever locking the BIOS. In the latter case, [BIOS] "Settings > Power Management > Primary Battery Charge Configuration" were changed -- presumably by fedora. Notably, mode was set to custom and charging thresholds were set to between 75% and 80%, which matched the upower -d output.

* Please specify if more hardware diagnostics or other diagnostics information is desired. 

* NOTE: If there are other Fedora Settings (maybe even in other modules) that rely on underlying BIOS changes, I imagine these might be similarly at risk of showing behaviour like the one described at hand. Should you or your fellow developers suspect this, I kindly suggest to handle the matter appropriately and care that these potential places are double-checked and (if necessary) fixed analogously.

Comment 1 15184+1854+2025-11-12 2025-11-12 16:45:47 UTC
NOTE: I wasn't familiar with the fedora component categorization and spent some time to (maybe not correctly) figuring out what might be applicable. If a different component was actually more accurate, please just tell me and feel free to update the record accordingly.

Comment 2 Kate Hsuan 2025-11-14 04:37:41 UTC
Hi,

Thank you for reporting the issue.
Power panel invokes upower to set up the battery configuration, so the component you selected is correct.

Upower set the values through the sysfs (the kernel driver) and the driver writes the configs to the system firmware and the firmware starts working on the feature that we requested.
At the first normal demo, upower and firmware worked as expected.

However, at the second demo, upower asked the kernel to write the config to the firmware but the firmware didn't react. Upower works as expected since it writes values to the sysfs successfully.
It looks like a firmware issue.
The best way is to file a service ticket to the laptop vendor. They are able to resolve the firmware issues.

Note, the charge threshold feature (Preserve battery health) is done by the system firmware. The upper-layer app only configures the firmware through the kernel and its driver. After sending the value to the firmware, the firmware should work as the system datasheet mentioned.


> * While upower -d shows above alleged charging thresholds between 75% and 80%, on the faulty system the BIOS (i.e. [BIOS] "Settings > Power Management > Primary Battery Charge Configuration") settings remain unchanged.

These values are from udev hwdb and are fixed values that can be set by the vendor.

Comment 3 Fedora Update System 2026-07-07 09:02:59 UTC
FEDORA-2026-ae37eea468 (upower-1.91.3-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-ae37eea468

Comment 4 Fedora Update System 2026-07-07 09:15:25 UTC
FEDORA-2026-e5305cffc2 (upower-1.91.3-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-e5305cffc2

Comment 5 Fedora Update System 2026-07-07 09:15:28 UTC
FEDORA-2026-ce80ea7afe (upower-1.91.3-2.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-ce80ea7afe

Comment 6 Fedora Update System 2026-07-07 10:45:37 UTC
FEDORA-2026-ae37eea468 (upower-1.91.3-1.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 Fedora Update System 2026-07-08 01:40:25 UTC
FEDORA-2026-ce80ea7afe has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-ce80ea7afe`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-ce80ea7afe

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 8 Fedora Update System 2026-07-08 01:51:44 UTC
FEDORA-2026-e5305cffc2 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e5305cffc2`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e5305cffc2

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 9 Fedora Update System 2026-07-09 00:56:50 UTC
FEDORA-2026-e5305cffc2 (upower-1.91.3-1.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 10 Fedora Update System 2026-07-12 00:59:22 UTC
FEDORA-2026-ce80ea7afe (upower-1.91.3-2.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.