KDE Partition Manager 3.3 and future work

KDE Partition Manager 3.3 is now ready. It includes some improvements for Btrfs, F2FS, NTFS file systems. I even landed the first bits of new LUKS2 on-disk format support, now KDE Partition Manager can display LUKS2 labels. More LUKS2 work will follow in KPM 3.4. There were changes in how LVM devices are detected. So now Calamares installer should be able to see LVM logical volumes. Once my pull request lands, Calamares should also support partitioning operations on LVM logical volumes (although Calamares would need more work before installation and booting from root file system on LVM works. I tested Calamares with KPMcore 3.3 and it successfully installed rootfs in LVM volume and successfully booted). KPMcore library now only depends on Tier 1 Frameworks instead of Tier 3 (although, we will later require Tier 2).

Most of the work is now done in sfdisk branch.  Currently, the only functional KDE Partition Manager backend uses libparted but sfdisk backend is now fully working (I would say RC quality). I would have merged in already but it requires util-linux 2.32 which is not yet released.

Yet another branch on top of sfdisk is KAuth branch which allows KPM to run as unprivileged user and uses Polkit when necessary to gain root rights. Everything except SMART support is working. To get SMART working too we would have to port away from (unmaintained) libatasmart to calling smartctl. Feel free to help! It should be fairly easy task but somebody has to do the work. Other than that you can already perform all partitioning operations using KAuth with one caveat. Right now KPM calls KAuth helper many times while performing partitioning operations. It can happen that KAuth authorization will expire in the meantime (KAuth remembers it for about 5 minutes) and KAuth will request a user to enter root password. If the user enters correct password, operation would finish. However, if authorization is not granted we may end up with half completed operation. And of course we don’t want to leave partition half moved, the data will almost surely be lost (half-resized partition is probably okay…). I suppose we can fix this by refactoring KPM operation runner, so that it calls KAuth helper just once with a list of all commands that have to be run. Unfortunately, this KPM Operation Runner refactoring might be bigger than what I would like, as significant changes would be necessary in partition data copying code. Maybe GSoC project then… Or ar there any better ideas on how to prevent KAuth authorization dialog in the middle of partitioning operations?

You can grab tarballs from standard locations on download.kde.org server.

8 comments on “KDE Partition Manager 3.3 and future work

  • mhogomchungu says:

    Solution for KAuth timeout issue.

    1. Have a component that runs unprivileged, in your case KPM.
    2. Have a separate CLI component that runs privileged, lets call it “KPMM”.
    3. Make KPM start KPMM through KAuth at startup and quit it on exit.
    4. Give the two components an ability to talk to each other through IPC.
    5. When a privileged operation is required by KPM, make it send the command to KPMM and let KPMM carry it out.
    6. ???
    7. Profit!!

    • Well, having this KPMM would be more or less duplicating KAuth mechanism itself. KAuth is IPC mechanism (it uses DBus) to run a small helper applications. And it should require much more work than fixing current KAuth helper, i.e. calling it just once with a list of all commands that need to be executed instead of one by one.

      • David Edmundson says:

        >Well, having this KPMM would be more or less duplicating KAuth mechanism itself.

        Not really. KAuth is a thin layer over Polkit-Qt5, you could still use that. It’d be duplicating 50 lines of DBusHelperProxy.

        The idea above isn’t too bad, just over complicated.

        1) You have KPMM *as* the polkit-helper. That validates itself, copy pasting the 5 lines from kauth

        2) You keep it open with the DBus service available. You don’t auth every time, you just check the sender matches the original sender.

        3) profit???

        /might/ be possible within KAuth if we change isCallerAuthorised and when the app quits (currently 200ms after the last call was processed)

        • Okay. But like you said it would be KPMM split would be more complicated than the split we need to do now.

          Right now I think we need to refactor data copying code, so that it doesn’t transfer all the data from the helper to the main application and back. There is no reason why KAuth helper can’t do all the data copying itself without sending it to the main app. We just need to change some abstractions in KPM. After this is done, I think it will not be difficult to store all required commands and their inputs in KAuth helper, call it once and use KAuth longaction to communicate back to the main application.

  • Solerman says:

    To keep the password popup, while doing the operations, spawn a thread that does ksudo echo 1 > /dev/null every minute or something?

  • Thanks a lot for your work, I’m really happy to find KDE Partition Manager in my toolbox whenever I don’t feel like using fdisk and friends manually (which is often, admittedly 😉 ).


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Time limit is exhausted. Please reload CAPTCHA.