[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

No valid power management backend plugins are available

when i open whonix workstation 10 , a flash message (quickly show up and go) saying:-

[code]KDE Power Management System

KDE Power Management System Could not be initialized. The backend reported the following error: no valid power management backend plugins are available. A new installation might solve this problem.
please check your system configuration.[/code]

image:-

i have no idea what does it mean or which system conf i should check.

It’s a minor issue. One that should be fixed to prevent confusion.

I would speculate kde powerdevil does not work with virtual hardware. But it’s in my opinion not useful to have power saving tools inside a VM anyhow. It’s just confusing for users to look into their VM and see that the “screen” is back. Power saving something that, if desired, should be done on the host.

Can you reliably reproduce this?

If so, to get rid of this message, please test the following command. That should prevent kde powerdevil from starting up.

Perhaps that’s a solution suitable for further releases of Whonix. (Technically speaking, using config-package-dev’s hide operation to move /usr/share/kde4/services/kded/powerdevil.desktop out of the way.)

[hr]

But then under System Settings --> Power Management, we would get this:

Power Management configuration module could not be loaded. 
The Power Management Service appears not to be running. 
This can be solved by starting or scheduling it inside "Startup and Shutdown"

And therefore another bug report. Damn.

[hr]

Another option. It will be “fixed” in Whonix 11, because in Whonix 11 the upower package gets installed by default. Then power management in a VM would be functional. Without any error messages. But useless and confusing in VMs as I think as said above.

So another solution for you, for now, would be to “sudo apt-get install upower”.

Maybe a package that gets only installed in VMs that disables kde power saving functions would be the way to go.

Adding upower is a bandaid solution and introduces a different set of problems. I think the better solution is to disable power devil instead of hiding it. That’s done by adding a line to a KDE services configuration file as in the last post of this thread:

http://ubuntuforums.org/showthread.php?t=2006971

Which ones? The ones I mentioned above, having useless power management in a VM?

This was how it was done in Whonix 9 by the way.

[quote=“HulaHoop, post:3, topic:1074”]I think the better solution is to disable power devil instead of hiding it. That’s done by adding a line to a KDE services configuration file as in the last post of this thread:

http://ubuntuforums.org/showthread.php?t=2006971[/quote]
I see.

I thought my ‘sudo mv /usr/share/kde4/services/kded/powerdevil.desktop’ ~/" “solution” is technically simpler and essentially does the same. But I was wrong. It does not.

The ’ X-KDE-Kded-phase=0’ “solution”:

  • good: is technically also doable by using config-package-dev’s displace operation -> could implement a kde-power-devil-disable package that only gets installed inside VMs?*
  • good in VMs: removes the battery monitor (kde power devil) from the task bar’s tray area which is useless and confusing in VMs
  • good: does not introduce the ‘System Settings --> Power Management’ ‘Power Management configuration module could not be loaded.’ issue
  • neutral(?) in VMs: leaves KDE’s power management enabled by default -> is a separate issue, a missing feature in the power-savings-disable-in-vms package?

[hr]

*Ideally rather implemented in the power-savings-disable-in-vms package, but doing config-package-dev’s displace operation conditionally only inside virtual machines could be difficult.

[hr]

Related:

Which ones? The ones I mentioned above, having useless power management in a VM?

Yes the fact that its useless and confusing.

*Ideally rather implemented in the power-savings-disable-in-vms package, but doing config-package-dev's displace operation conditionally only inside virtual machines could be difficult.

I don’t know how difficult but here’s how I think it can be done:
The displace operation would go through only if virt-what detects a virtual environment, on Whonix/whonixcheck first run.

Then the distribution agnostic power-savings-disable-in-vms package would have a weird dependency on Whonix specific package whonixcheck. And by that time, it would be too late.

config-package-dev’s displace operation is a debhelper maintainer script feature.

The right place would be the postinst maintainer script.

Conditions:

  • When building with --target virtualbox, qcow2, qubes(TODO) an environment variable could be set (during build).
  • Or from within a booted installation, virt-what could be used.

When either condition is true, the postinst script would run normally, otherwise exit before the debhelper (that includes the config-package-dev) part.

Turned all of this into tickets.

disable kde power devil in VMs:
https://phabricator.whonix.org/T296

disable KDE’s power management in VMs:
https://phabricator.whonix.org/T297

add --target qubes:
https://phabricator.whonix.org/T298

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]