Fedora Account System
Red Hat Associate
Red Hat Customer
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.
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.
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.
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
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
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
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.
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.
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.
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.
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.