[IT'S A BUG] Can't launch partitionmanager, kdesu hangs

[Wheelerof4te]

I have encountered this bug:
https://bugs.debian.org/cgi-bin/bugrepo ... bug=892601
This is on Buster KDE Plasma, obviously.
How can I use this application on Buster? Shouldn't the bug severity be higher than "normal", as this basically prevents the application from being used as intended?
EDIT: su -c partitionmanager worked, but that's not intuitive, is it?

[Head_on_a_Stick]

su -c partitionmanager worked

Don't do that.

The gksu{,do} packages are now considered obsolete, use pkexec instead.

You will have to configure polkit to allow the program to launch, something like

Code: Select all

# /usr/share/polkit-1/actions/partitionmanager.policy
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
   <icon_name>partitionmanager</icon_name>
   <action id="partitionmanager">
      <description>Run partitionmanager as root</description>
      <message>Authentication is required to run partitionmanager as root</message>
      <defaults>
         <allow_any>auth_admin</allow_any>
         <allow_inactive>auth_admin<allow_inactive>
         <allow_active>auth_admin<allow_active>
      </defaults>
      <annotate key="partitionmanager.exec.path">/usr/bin/partitionmanager</annotate>
      <annotate key="partitionmanager.exec.allow_gui">true</annotate>
   </action>
</policyconfig>

Then use

Code: Select all

pkexec partitionmanager

No idea why KDE don't supply this file though

[sunrat]

I ran into the same problem a couple of days ago, exactly as described at
https://unix.stackexchange.com/question ... ssword-set

A couple of answerers suggested using sudo or kdesu but I didn't try that after reading this post:

Don't run partitionmanager like this. Things might break if you use sudo (note, I am the maintainer of KDE Partition Manager). – Andrius Štikonas Aug 27 '18 at 11:47

I just wanted to do some partitioning, not track down bugs, so I installed Gparted and it worked straight away. Next time I'm on that computer I will apply the above solution as it's a brand new Buster/KDE Plasma install and I'd like to keep it using KDE programs where possible and ditch Gparted.
Thanks Head_on_a_Stick! It certainly is curious why it's not set up for pkexec and the bug appears to have existed for some time.

[sunrat]

I just tried your suggestion @Head_On _A_Stick. I changed the filename to org.kde.partitionmanager.policy and removed the comment at the top as otherwise it didn't seem to be recognised as an xml file. Seemed to get past the permissions issue but now I get a different error:

Code: Select all

$ pkexec partitionmanager
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

This is a Buster netinstall with only kde-plasma-desktop added so is fairly minimal. I'm wondering if there's a package I'm missing or just config. Or maybe a dead end?

[Wheelerof4te]

^I also just installed the kde.plasma-desktop metapackage, by I don't think it's missing anything. Else, there wouldn't be a bug report.

[Head_on_a_Stick]

removed the comment at the top

Ahem yes, good catch — that's not a comment in xml

Code: Select all

$ pkexec partitionmanager
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.

How about if you specify the display?

Code: Select all

DISPLAY=:0 pkexec partitionmanager

Check if the DISPLAY value is correct by running

Code: Select all

echo $DISPLAY

But I think the package may actually need internel support for this to work; I just copied the policykit file from gparted and modified it.

[sunrat]

I also tried to do this on my other Sid computer which has kde-standard, same problem. Authentication seems to work but still

Code: Select all

$ DISPLAY=:0 pkexec partitionmanager
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.


I had tried xhost + previously anyway on the other system.

I tried running it with su -c as a test. It opened but displayed a message:

No support tools were found for file systems currently present on hard disks in this computer:
Partition
File System
Support Tools
URL
/dev/sda3
linuxswap
util-linux
http://www.kernel.org/pub/linux/utils/util-linux-ng/
/dev/sda6
ext4
e2fsprogs
http://e2fsprogs.sf.net
...

As long as the support tools for these file systems are not installed you will not be able to modify them.
You should find packages with these support tools in your distribution's package manager.

These packages are installed, of course.

At least Gparted works! And installs its own policykit file.

[Wheelerof4te]

^

I tried running it with su -c as a test. It opened but displayed a message:

Same message, same situation. I think I'll just unistall it.

[OskarW85]

I encountered the same bug. It also happens with Zenmap. For me pkexec just doesn't work in Buster.

[Deb-fan]

Know pkexec(polkit and policy files) are the wave of the future. Also sure there's valid reason for these changes. However I don't particularly like it, so will continue working around them for now. Haven't gotten around to switching to Buster yet either though. Been leaning towards continued use of gksu/do, obsolete (sec concerns) or not even if would have to snatch the packages from archives and forego Wayland too. Might opt for using lxqt-sudo instead. Have dorked with it in Stretch and has worked well enough. Though if kdesu isn't working on your system, it could very well not either.

Being lazy and haven't invested the effort in learning about these new fangled pkexec-etc things yet. Know the people who implement and develop all these changes know more about tech than I do/will. Still don't like it, so personally will keep working around them till I'm ready to switch. Overall seems silly to me all this rigamarole about not launching graphical apps with privs or only with strictly defined limits set out in a policy file. If someone has access to a system and the login/password credentials, they can do whatever they want anyway. Including creating policy files or disabling polkit. Though atm this is still just my preference and am willing to take any risks involved.